Do I Miss Being a Principal Engineer? Yes and No
Someone asked me last week whether I miss being a principal engineer. I had to think about it for longer than I expected, which usually means the honest answer is more complicated than the polite one.
The question matters beyond me. Most senior engineers hit a fork where one path goes deeper into technical work and the other bends towards consulting, management, or leadership. The reasons people give for the choice they make are often not the real reasons, and that gap is where careers stall.
Where I came from
I spent several years as a principal engineer before moving into consulting and leadership roles. The work was deep and technical: architecture decisions, code reviews that mattered, and long stretches of focused problem-solving.
I was good at it, and I liked it. That’s worth saying plainly, because “I moved on” is easy to misread as “I was escaping something”. I wasn’t.
The honest answer: yes and no
What I miss
I miss the clarity. As a principal engineer, the success condition is mostly unambiguous. Does the system work? Is the code good? Did the architecture hold up under real load?
Consulting and leadership have fuzzier success conditions. Did I help the right people make the right decisions? Is the team more capable now than before I showed up? Those are hard to measure and often impossible to know for months. Feedback loops that used to take minutes (a failing test, a slow query) now take a quarter, and some never close at all.
What I don’t miss
Politics. Navigating organisational complexity was the part of the principal role I was least suited for.
As a consultant, I walk in, do the work, and leave. The politics still exist, but they’re not my long-term problem to solve.
I’m aware that isn’t entirely healthy. Stepping around a weakness is not the same as fixing it, and it means I sometimes understand a client’s organisation less well than their own staff do. I wrote about a version of that humility in The Expert Trap. But it’s the honest answer, and pretending otherwise would make the rest of this post less useful.
The trap in the technical ladder
Some engineers keep chasing technical depth as an avoidance strategy. Staff engineer, principal, distinguished: the title ladder goes up, and it feels like pure technical merit is the operating system.
It isn’t. At every rung, the work becomes more about people, communication, and influence. A principal engineer who can’t get three teams to agree on an interface contract has the same outcome as one who designed the wrong contract.
The principal engineers who last are the ones who realised this early and worked on it deliberately. The ones who didn’t tend to end up in roles where technical credibility covers for underdeveloped people skills, until a reorganisation or a new leader removes the cover.
What I tell engineers who ask
If you’re deciding whether to stay deeply technical or move towards leadership, both paths are valid. The part that matters is being honest about why you’re choosing.
| Stay technical | Move to leadership | |
|---|---|---|
| Good reasons | You love hard technical problems more than anything else; you’re genuinely better at that than at leading people; the organisation needs your specific expertise more than another manager | You want to develop people and find their growth rewarding; you’re energised by shaping how a group works, not just what it builds |
| Bad reasons | You’re avoiding the work of developing leadership skills; “technical” feels like a safer identity than “leader”; you’ve conflated depth with worth | It comes with status or a pay bump; it feels like the only way up; you’re tired of the hands-on work rather than drawn to the people work |
The bad reasons on both sides share a pattern: they’re about escaping something rather than choosing something. My rule of thumb is to ask, “If both roles paid the same and had the same title, which would I pick?” The answer to that is closer to the truth.
What staying sharp looks like now
I still code. Not every day, but enough to stay honest.
In client environments, I build proofs of concept myself before handing off to their team. When I recommend an architecture, I’ve tried to implement it, at least at a small scale.
That matters more than it sounds. Advice from someone who no longer codes drifts. The abstractions survive but the texture fades: the part where you feel the friction of an SDK that doesn’t quite do what the docs imply, or a deployment step that looks trivial on a diagram and eats an afternoon. Without that texture, recommendations get cleaner and less correct at the same time.
The goal isn’t to be the best individual contributor on the team. The goal is to stay close enough to the work that my perspective is still useful to the people doing it.
When this advice doesn’t apply
Not everyone needs to stay hands-on. If you lead a large organisation, your leverage is in hiring, structure, and decisions, and trying to keep coding can turn into a way of avoiding that harder work, which is the same trap in reverse. And if you’ve chosen a deep specialist track on purpose, “work on your people skills” doesn’t mean “become a manager”. It means being able to explain your reasoning well enough that others act on it.
A better question than “do I miss it?”
The more useful question is: what work actually energises me now, and am I doing enough of it?
For me, the answer is hybrid. Deep technical work on hard problems, combined with helping teams work through those problems. Neither alone is right for me. I’m still figuring out the ratio, and I suspect it will keep shifting.
There’s no wrong answer to the principal engineer question, only an honest one and a dishonest one. Know what you actually want, and know why. If you can say both out loud without flinching, the path tends to sort itself out.