What testing taught me about running technology
People are occasionally surprised to find years of testing posts sitting behind a site that calls me a technology director, as though testing were an earlier, separate life I’ve since moved on from. It wasn’t a phase, and I haven’t moved on from it. Most of how I run technology now was shaped by the years I spent testing, and the habits transferred almost intact. These are the ones that mattered.
Ask the awkward question early
Testing teaches you to ask the uncomfortable question while it’s still cheap to answer. What happens if this field is empty? What if two of these run at once? What did we actually decide this was for? A good tester asks early, because the same question asked a week before release costs ten times as much to deal with.
That instinct is most of what I do now. When a client tells me they need to switch cloud providers because the bill is too high, the useful move is not to start planning the migration. It’s to ask the awkward question underneath: does anyone actually own this estate? The habit of asking early, before accepting the premise you’ve been handed, is the same one. The stakes are just larger.
Care about the whole system
A tester who only checks their own small piece isn’t much use. The interesting problems live in the joins: how data moves between systems, what happens at the edges, how the thing behaves when real people use it in ways nobody designed for. You learn to hold the whole system in your head, and to distrust anyone who tells you a part is fine in isolation.
Running technology is that same view, scaled up. The organisation is a system too, with joins and edges and parts that behave differently under load. When I put an ownership model in place for a client, the technical structure and the team structure had to match, because a gap between them is exactly the kind of join where things go wrong. Testing taught me to look there first.
Judge the work by the difference it makes
I wrote years ago about why chasing a number like one hundred per cent test coverage misses the point. Coverage tells you what was exercised, not whether any of it matters. The judgement that counts is whether the testing actually reduces the risk of something going wrong for a real user, and that is not a number you can chase blindly.
The same judgement runs through everything I do now. It’s why I care about outcomes rather than outputs, about the difference a piece of work makes rather than how much of it there is or how cleverly it was built. A lot of technology activity looks productive and changes nothing. Testing trains you to tell the two apart, and to be a little suspicious of anything that measures effort instead of effect.
Trust judgement over dogma
I’ve never valued test certification much, and I’ve said so in public. Not because learning is bad, but because a certificate tells you someone passed an exam, not that they can think when a situation doesn’t match the textbook. Good testing is pragmatic. It’s judgement applied to a specific situation, not a process followed because the process exists.
That belief shapes how I hire and how I lead. I look for people who can reason about the problem in front of them rather than recite the correct-sounding answer, and I’m wary of process that survives because it’s familiar rather than because it helps. The best testers I worked with knew which rules to bend and when. The best engineers and leaders are no different.
Get comfortable judging work you didn’t do
This is the habit that turned out to matter more than I expected. A tester spends their whole career judging work they didn’t produce: reading someone else’s code, someone else’s design, and forming a reliable view of whether it’s any good. For years that was a testing skill. Now, with AI writing most of the code, it’s the skill. Being able to look at output you didn’t create and know whether to trust it is exactly what keeps AI-assisted work honest, and I’d been practising it for years without realising.
So
Testing wasn’t the thing I did before I did technology properly. It was the training. The habits it drilled into me, asking early, thinking in whole systems, judging by effect, trusting judgement over dogma, and sizing up work I didn’t do myself, are the same ones I lean on running technology today. If you’ve come to this site through the old posts, they aren’t a time capsule. They’re where the rest of it came from.