Leverage Over Commits

Being an individual contributor is deterministic. There is a deep, simple satisfaction in fixing a flaky TypeScript test, getting a green build on a frontend pipeline, and seeing exactly what you delivered. Your colleagues are happy, success is easy to measure, and when you log off for the day, you know exactly what you accomplished.

Being a people lead isn’t like that.

As Camille Fournier points out in The Manager’s Path, stepping into management isn’t just a promotion; it’s a lateral move into a completely different discipline. The most jarring part of that shift is losing your tight feedback loop.

Instead of shipping features, the work happens away from the IDE. You spend your days in 1:1s, untangling organizational friction, and curating context. It is about ensuring engineers understand the why behind the product without getting bogged down in the how of the organization. The hardest part is that when you do your job perfectly, it often looks like nothing happened at all. The impact is highly visible to the group, but it is entirely unquantifiable by Git.

As a manager, your worth is tied to clarity. It is taking ambiguous requirements and helping the group carve out a solid technical path before a single line of code is written. It is absorbing organizational noise and filtering out distractions so engineers can maintain deep, uninterrupted focus. It is ensuring that everyday technical decisions map cleanly to long-term goals. None of this yields a satisfying green checkmark.

Because I still enjoy the technical side, the temptation to just open the editor and jump back into the codebase is always there. When a week is just a blur of context-switching and small group alignments, picking up a coding task feels like a relief. It is a quick way to guarantee I actually delivered something today.

But defaulting to IC work just to get that quick win misses the point of the role. It’s not about stepping away from technology. I still need that context, and writing code for internal tooling or scaffolding can still be highly multiplicative. It is rather about recognizing where my time creates the most leverage for the group.

Taking a coding task on the critical path feels good because it provides immediate, tangible value. If I jump in to fix a tricky pipeline issue, the problem is solved and the build is green. But there is a hidden cost. Because I am not living in the codebase forty hours a week, I lack the deep, evolving context that full-time engineers have. My intervention might introduce subtle technical debt, or worse, it makes me the bottleneck instead of focusing on the alignment the group actually needs. True leverage means acting as a multiplier for the system, not just closing a single ticket.

I’ve had to completely redefine what a “good day’s work” looks like. Success isn’t just about personal delivery anymore. It is the escalation that didn’t happen, the systemic bottlenecks I quietly resolved weeks ago, and seeing the engineers execute autonomously. The output might not show up on a burndown chart when I log off today, but building a system where engineers can thrive is the most impactful work I can do.

The itch to write code never really goes away. It is the craft that brought us here, after all. But leverage doesn’t come from a personal commit history anymore. When I close my laptop on a Friday, I don’t measure the week by the PRs I merged. I look at proxies. Are technical decisions being made smoothly without escalating to me? Is the group maintaining momentum without relying on single points of failure? That is the baseline capacity we raised for the entire group. It is quiet work. But it is the only work that scales.