From Keyboard to Boardroom: The Engineering Leadership Transition
The transition from principal engineer to engineering director is the most disorienting career shift I've experienced — more so than any technical challenge. The mental models that made me effective as an engineer were actively harmful as a leader, and nobody warned me that the learning curve would feel like regression.
The seduction of technical work
There is a particular pleasure in writing code. Not the social-media-for-developers pleasure of shipping a feature — I mean the quieter satisfaction of a well-structured function, of a data model that captures the domain without lies, of a test suite that fails precisely when it should and passes cleanly otherwise. Engineering rewards precision. The feedback loop is short and honest: you write the code, you run the tests, the system either behaves correctly or it tells you exactly where it doesn't.
This is the environment that shaped me for fifteen years. Ambiguity was a problem to be resolved through better specification. Disagreements had correct answers you could point at. Progress was measurable in commits, in coverage numbers, in latency metrics. I was good at it, and I was good at it in ways that were legible to myself and others.
The qualities that made me good at engineering — a low tolerance for approximation, a strong instinct for when something is wrong even before I can articulate why, a preference for doing things correctly over doing them quickly — produced a particular kind of engineer. One who ships reliable software. One who other engineers respected. One who, when a hard technical problem appeared, was the person you wanted looking at it.
What nobody told me is that these same qualities, applied to leadership, produce a particular kind of manager: a controlling, second-guessing, trust-depleting one. The precision instinct that made me a better engineer made me a worse director, right up until I understood why.
Month one: the calendar as diagnostic instrument
I accepted the director role at Vincit expecting a job that was 70% strategic thinking, 20% mentoring talented engineers, and 10% administrative overhead I would minimize through systems. What I got was a calendar that looked like a Tetris board after someone has been playing badly for several minutes — dense with meetings, every open slot filled within days, very little of it recognizable as "work" by the definition I'd been using for a decade and a half.
I remember sitting in a 1:1 with one of my team leads in the third week, and about midway through her update about a particularly knotty infrastructure problem, I caught myself mentally composing a solution. I knew the domain well. I could see a cleaner approach. I almost interrupted her to explain it.
I didn't — not because I was wise, but because I had a rule I'd set for myself at the start: no unsolicited solutions for the first thirty days. The rule felt arbitrary and slightly patronizing at the time I made it. By week three I understood it was the only thing keeping me from being actively harmful.
The shock of month one wasn't the volume of meetings. It was the realization that "productive" had an entirely different meaning in this job, and I had no intuition for it yet. An engineer is productive when they produce. A director is productive when the team produces — and the levers are indirect, slow, and deeply human. That is not a comfortable reframe when your identity is built around direct, fast, technical impact.
The bad habits that survived the promotion
I wish I could say I recognized the bad habits quickly and corrected them. I did not. Several survived well into the first year, and I'm still periodic in catching their recurrence.
The most damaging was code reviewing PRs at 11pm. I had an engineering team. They were competent. My job was no longer to review their code — there were senior engineers whose job that was. But at eleven o'clock, when the day's meetings were done and I wanted to feel like I'd done something concrete, I would open GitHub and start leaving comments. Comments that were correct. Comments that were also subtly undermining the authority of the engineers whose job it was to review code, and sending a signal to the team that the director did not fully trust them to maintain quality without supervision.
The second was rewriting engineers' implementations when I thought mine was better. I never did this openly. I would leave "suggestions" in code review that were complete rewrites. I would raise architectural concerns in planning that happened to lead toward my preferred solution. I told myself I was coaching. I was, in fact, optimizing for my aesthetic preferences at the cost of ownership and growth in the team.
The third was answering technical questions directly when engineers asked them. If someone asked me whether they should use an event-sourced architecture for a new service, I would answer the question. Immediately. With my opinion. The coaching move — the leadership move — was to ask what they'd considered so far, what tradeoffs they saw, what the risk tolerance was on the project. The direct answer felt helpful. It was actually an obstacle to the engineer developing their own judgment.
The moment it flipped
About eight months in, we were designing a significant new component of the platform — a notification delivery system that needed to handle multiple channels, priority queuing, and guaranteed delivery semantics. I had strong opinions about the architecture. I had designed similar systems before. I knew, with the confidence that comes from pattern recognition over many projects, how I would build it.
I held back. Not because of any particular discipline, but because I had three back-to-back stakeholder meetings that week and genuinely didn't have the time to be in the weeds. I gave the problem to two of our senior engineers and told them I wanted to see a proposal in two weeks, and that they should own the decision.
The proposal I got back was better than what I would have produced. Not incrementally better — meaningfully better. They had identified an operational concern I hadn't weighted heavily enough and had made a different queue topology choice because of it. The choice would turn out to matter significantly six months later when we had a spike in notification volume that would have exposed exactly the issue they'd anticipated.
I sat with that for a while. The system I would have built was technically correct by any objective measure. It was also worse than what two engineers produced when I got out of their way. That is a hard thing to absorb when your identity is built on technical judgment. It is also the most important thing I learned in the first year of directing.
Trust as core technology
Management books say trust is important. That's true and useless. What I've come to understand is that trust in an engineering team is a specific, technical thing — it has properties, it can be measured, and it behaves in predictable ways when you prod it.
Trust builds slowly and breaks fast, and the breaks are asymmetric. An engineer who watches their director review their code at 11pm, leave fifty comments, and never acknowledge the good work — that engineer's trust erodes in a way that takes months to repair, regardless of how many subsequent weeks go by without incident. The break is remembered; the absence of breaking is not.
What trust actually looks like in practice, in my experience, is almost embarrassingly mundane:
- When you say you'll do something, do it. Follow-through is the most powerful trust signal available to a leader and the most consistently underweighted.
- Be available. Not always on Slack, but reliably present when needed. The number of engineer frustrations that I've seen stem from a director being unreachable during a critical decision is not small.
- Make decisions visible. When a call goes against what a team member advocated for, explain the reasoning. Unexplained decisions breed conspiracy theories about motivations, which corrode trust faster than bad decisions do.
- Protect the team from organizational chaos. Engineers who feel like their director absorbs institutional noise and converts it into clear priorities are engineers who trust that director to have their interests at heart.
None of this is exciting. None of it will get you written up in a management book. It is also, in my observation, the majority of what separates teams with high trust from teams without it.
Metrics I actually track
I am constitutionally opposed to managing without data, and leadership is no exception. The specific metrics I've found durable:
eNPS (employee net promoter score) on a quarterly pulse — a single question, anonymous, with a free-text field. The trend line matters more than any single number. A six-point drop in a quarter is a signal worth investigating even if the absolute number is still acceptable.
Time-to-PR-review at the team level. This is not a performance metric for reviewers — it's a health metric for the team. When review time climbs, it usually indicates one of: too much work in flight, a bottleneck on a specific reviewer, or psychological safety erosion where people are avoiding the difficult feedback conversations. All three are worth knowing about.
Developer survey on psychological safety — four questions, quarterly, borrowed from Google's Project Aristotle framework. The most predictive single item: "I can raise a concern without fear of negative consequences." Teams where this score is low ship fewer bugs not because they're more careful, but because bugs go unreported until they're serious.
What I don't track: lines of code, individual velocity, time-to-close for tickets. Metrics that optimize individuals produce individual-optimizing behavior at the expense of team coordination. That's the wrong tradeoff at nearly every scale.
On the identity loss
Engineers have a legible identity. You write good code. You understand complex systems. You can point at the thing you built and say "I built that." The identity is specific, verifiable, and professionally portable.
Directors have... it's harder to name. You can point at the team and say "I led that," but the team built the thing, not you. You can describe your decisions, but decisions are invisible in a way that code is not. You can cite outcomes, but outcomes have many causes. The identity of a director is diffuse and hard to verify, including to yourself.
The answer I've found — and I'm aware this is going to sound either profound or insufferable depending on your tolerance for leadership philosophy — is that the director's identity is the quality of the team over time. Not the specific things the team ships, but whether the team is better at doing hard things this year than last year. Whether the engineers are growing. Whether the organization trusts the team's output. Whether the team can operate well in your absence.
That identity takes years to accumulate and is nearly invisible quarter to quarter. It is also the right answer to "what do you actually do?" and learning to be comfortable with the pace of its accumulation is, I think, the actual psychological work of the leadership transition.
What I wish someone had told me
The skills that made you a good engineer — the technical precision, the fast feedback instinct, the direct intervention when something is wrong — are not wrong. They are just calibrated for a different job. The transition is not about discarding those instincts but about learning which context they apply in and which they don't.
The learning curve genuinely feels like regression because you are bad at the new job before you are good at it, in the same way you were bad at engineering before you were good at it. The difference is that engineering badness is visible in compiler errors and failing tests. Leadership badness is visible in team morale surveys six months later and in engineers who leave for companies where they're trusted with harder problems. The feedback loop is long and ambiguous, which is uncomfortable for people trained on short, honest feedback.
Give yourself eighteen months before you evaluate whether you're suited to the job. In month three you will be certain you're not. In month eighteen you might be surprised.