25 years in tech — the things nobody puts on a resume
The resume version is clean. A line of titles, a cascade of technologies, a set of outcomes expressed as percentages. It gives you a shape.
What it doesn't give you is the texture.
The texture is: sitting in a war room at 2am for the fourth consecutive night, when the system is down and customers are angry and everyone is exhausted and somebody still has to hold the thread of rational thinking. Learning that composure under pressure isn't a personality trait — it's a skill, and you build it the way you build any skill: by needing it before you have it, repeatedly.
Or the moment you realise that the most expensive architectural mistakes are never technical. They're social. Someone knew the design was flawed and didn't say so clearly enough. Someone said it clearly and wasn't heard. The code just executes the decision; the decision happened in a meeting, or a hallway conversation, or an email that got three words of attention.
Twenty-five years of this gives you pattern recognition that's hard to articulate. You walk into a system review and something feels off before you can name it. You're in a project kickoff and you can sense the places where the plan is optimistic in ways the team hasn't acknowledged yet. You learn to trust that instinct and also to question it — because sometimes the pattern you're recognising is from a context that doesn't apply here.
The thing I didn't expect: the longer you're in it, the more important communication becomes relative to technical skill. Not because the technical stops mattering — it never stops mattering — but because your leverage is in explaining, convincing, translating between what engineers know and what decision-makers need to decide. The best code I've seen fail wasn't buggy. It was orphaned by people who couldn't get stakeholders to understand what they were building and why.
If I had to compress what I've actually learned into something useful: stay curious, stay honest about what you don't know, and find out as early as possible who in the room isn't saying what they're thinking. Everything else is solvable.
Related
On moving countries — and what you actually pack
You spend weeks deciding what furniture to sell and what to ship. You agonise over boxes, cubic feet, insurance riders.
On reading — and what I had to stop doing to do it better
I read a lot — always have. But for most of my career, I read in the same way I approached most things: with efficiency as the primary goal.
The imposter thing doesn't go away. But it changes shape.
I spent a lot of my early career waiting for someone to notice I didn't know what I was doing.
Working on this in production?
We do this work directly alongside engineering teams — architecture review, migration, and hands-on enablement.