Eighteen months ago I moved from Lead Software Engineer to Engineering Manager. The organisation is now 20+ people across engineering, DevOps, and AI, running on three cloud providers in a regulated environment.
The thing nobody quite prepares you for is that the job doesn't get bigger. It gets different, and for a while you keep doing the old one very well while the new one goes unattended.
The Leverage Shift
As a lead, my output was roughly proportional to my effort. Hard week, more shipped. The relationship was direct and, honestly, satisfying.
That relationship breaks. My output is now almost entirely other people's output, which means the highest-value hours of my week are the ones that look least like work: a clarifying conversation before someone spends a sprint on the wrong thing, a decision unblocked, an architectural argument settled at the right altitude.
The uncomfortable part is the feedback delay. Writing code gives you a result in hours. Coaching an engineering lead gives you a result in months, and you're never entirely sure which input produced it.
I spent my first few months solving problems that would have been better solved by the person who brought them to me. It felt productive. It was, at best, neutral — I was a well-intentioned bottleneck with good intentions.
Hiring Leads Is Different From Hiring Engineers
The single highest-leverage thing I do now is hire and develop leads. It's also where I've made my most expensive mistakes.
The obvious error is promoting your strongest individual contributor. Sometimes that works. Often you lose a great engineer and gain a frustrated manager who solves problems by doing them personally — which is exactly the trap I'd just climbed out of.
What I look for instead: people who already act like leads without the title. Who unblock others before being asked. Who explain rather than take over. Who can hold a position under pressure and change it under evidence.
And then the part I got wrong at first — tell them what the job actually is. I promoted people and left them to infer the role from watching me. That's an unfair thing to do to someone. Now the expectations are explicit and written down: what they own, what they decide, what they escalate.
Three Clouds Is an Organisational Problem
We run across Azure, GCP, and Oracle Cloud. Not because multi-cloud is a strategy — because different workloads landed in different places for good reasons, and GPU capacity in particular goes where it's available.
The technical cost of that is real but manageable. The organisational cost is the one I underestimated: three sets of tooling, three permission models, three billing structures, three sets of failure modes to be on call for. A team can absorb a lot of technical complexity. What it can't absorb is complexity that fragments the on-call rotation, because you end up with individuals who are the only person who understands one cloud.
Our response was to standardise the layer above — Kubernetes, the same deployment patterns, the same observability everywhere — so cloud choice is a deployment detail rather than a specialisation. It isn't perfect. It means nobody is deeply expert in any one provider, and occasionally that costs us. It's still the right trade, because the alternative is single points of human failure.
In a regulated environment the same principle applies to compliance. NPHIES, HIPAA, PDPL — these are not a checklist you complete before launch. They're constraints on how you design, and the way you keep them from becoming a tax is to build them into defaults rather than reviews.
What I Kept
I still write code most days. Not on the critical path — that would be a different kind of bottleneck — but reviews, prototypes, the occasional production investigation at an hour when the right thing is to help rather than delegate.
I've heard the argument that managers who code are failing to let go. I don't buy it, at least not at this scale. You cannot evaluate an architectural decision you don't understand. You cannot tell whether a two-week estimate is careful or padded if you've lost your feel for the codebase. And when someone says the test suite is painful, you need to have felt it.
The discipline is staying off the critical path. My name on a PR that blocks a release is a failure of planning, not a contribution.
The Metrics I Actually Watch
Two, mostly: deployment frequency and change failure rate. Together, because either alone is trivially gameable. Ship more often with more breakage and you've achieved nothing; ship perfectly once a quarter and you've achieved less.
Both improved materially over the past year, and the causes were unglamorous: containerized test infrastructure, AI-assisted code review catching things earlier, progressive delivery making rollback boring.
What I deliberately don't measure: individual output. Lines, commits, story points. Every proxy for individual productivity I've encountered measures something adjacent to the thing you want and corrodes the behaviour you want on the way.
Three Things I'd Tell Myself
Your calendar is your strategy. Whatever you actually spend time on is your real priority, regardless of what the roadmap says. Mine didn't match my stated priorities for months, and I only noticed when I looked properly.
Decide at the right altitude. Some decisions are mine — architecture, vendors, headcount, what we're not doing. Most aren't. Taking a decision that belonged to someone else is a small theft of their growth, and you get to make it again next quarter.
Say the unpopular thing early. A slipping deadline, an underperforming vendor, a project that isn't working. These never improve with age, and the credibility cost of a late disclosure is much higher than the discomfort of an early one.
Still Learning
Eighteen months in, I get this wrong regularly. I still take problems that weren't mine. I still underestimate how long it takes for a message to actually land across twenty people.
But the shift I'd name, if asked what changed: I stopped measuring my week by what I built, and started measuring it by what the team could do that it couldn't do before. That's a slower, vaguer, much less satisfying signal.
It's also the job.
