I Love Managing as Much as I Ever Loved Building. Nobody in This Seat Is Supposed to Say That.

I love managing as much as I ever loved building. I want to say that plainly at the start, because almost nobody in this seat says it out loud, and the people who do tend to say it in a way that sounds like they are making peace with something.

I started as a lone software developer back in the 1900s. What I loved then was watching the thing I had built come to life: I wrote it, it ran, and something existed at the end of the day that had not existed that morning. That is a clean and complete kind of satisfaction, and I have never met a developer who outgrew it.

Then I moved into front-line management, and the surprise was not that the satisfaction went away. It multiplied. My victories were still mine, and now I also shared in the victory of every person on the team, which meant there were more of them and they arrived from directions I had not planned. Watching somebody do something they could not have done a year earlier turns out to feel a great deal like watching your own code run for the first time.

Managing managers added another layer on top of that one. I shared in my managers sharing in the victories of their teams, which is a longer chain and a slower signal, and no less real when it arrives. By then I was still building a system, and most people never see a team that way. I did not either, at first. When I finally did, everything clicked: a group of people who can build without me in the room is a system, designed and maintained like any other, and the joy compounded the moment I started treating it as one.

Now I sit as a partner and an equal inside a C-level group, and I still have every one of those earlier layers. I have also added a set of wins I never had access to before: a closed sale, a contract that survived its red-pen edits, a security review completed, a new product line released, a minor enhancement that mattered more to a customer than the release it shipped in. None of that replaced anything. It stacked.

That is not the story the industry tells about this climb. The standard account is a series of subtractions: you stop writing code, you stop making things, and each rung costs you what the last rung gave you. Every technical leader reading this has heard some version of it, and many have told it about themselves, usually with real feeling. The advice that follows is always about managing the loss, whether by scheduling weekend projects or by making peace with a trade.

That belief is expensive, and the cost is invisible for a long time. A leader who thinks the climb is taking something away protects what they think they are losing, which in practice means staying on the critical path for work that does not require them: work with no constraint at all on who else could have taken it on. From outside, at the stage where anybody would still call it admirable, that looks like dedication. It looks like a leader in the weeds with their team, taking the hard ticket, reviewing everything personally.

What it actually spends is the exact capacity that would have built somebody else's. So the team does not compound, the scale of what you can make stays roughly the size of your own hands, and every year confirms the story that made you protect it. The narrative proves itself, which is why it is so hard to argue anybody out of.

The leaders who love this work are not more disciplined than the ones who miss the code, and they did not stop caring about the technology. They stopped believing that the making had ended, and noticed the unit had changed.

Because I do make things. Constantly, and at a scale I could never have reached alone, which is far more grandiose than anything I shipped as a lone coder. The unit went from a function, to a team that ships far beyond what one person could cover, to a business capability that outlives the quarter. That is what I mean by Design Aim, which is a term I named for the outcome a seat exists to move, as distinct from the specialty it exercises in order to move it. My specialty is still technology; it is what I wield, and it is not what the seat is for.

There are three parts of this job I love most, and they are the same three I believe matter most, which is the argument I want to spend this week making: managing a team; pre-sales work and the conversations with customers and partners, including sales support for the largest enterprise accounts; and strategic long-term planning, which prepares a company for the shifts that maturity forces on it whether anyone scheduled them or not. None of those is a technology task. All three are how technology is wielded to solve a business problem and move a company to its next stage.

Before tomorrow, one thing to notice. Think about the last thing at work you were genuinely proud of. Was it something you made, or something your team made that you made possible? Both count. If you cannot remember one of the second kind from this year, that is the week we are about to spend together.

This is the first of five. The rest arrive daily, one per part of the job, and they go out to the daily email list before they go anywhere else: https://technicalleader.coach/daily-email