Leading Engineering Teams Without Becoming the Bottleneck

The first time I led a team larger than a handful of people, I was the most productive engineer in the room and the single biggest obstacle to the project. Both things were true at once, and it took an uncomfortably long time to see the connection.

How Technical Founders Become Bottlenecks

It happens gradually and for good reasons. You know the codebase best, so you review every pull request. You designed the architecture, so every structural question comes to you. You have the client relationship, so you translate every requirement. Each of those is defensible in isolation. Together they mean that nothing ships without passing through one person, and that person also has their own work to do.

The symptoms are easy to misread. Velocity drops and you conclude the team needs to move faster. Pull requests sit open and you conclude people are not pushing. Decisions stall and you conclude the team lacks ownership. Every one of those diagnoses points outward, and every one of them is wrong. The queue is not forming because the team is slow. It is forming because you are the server and there is only one of you.

The tell I eventually learned to watch for: how often does someone wait for me before they can continue? If the answer is daily, the structure is broken regardless of how good the code is.

Decisions Are Not All The Same Size

The change that helped most was sorting decisions by reversibility rather than by importance.

Some decisions are cheap to undo. Which utility library, how a component is named, whether a helper lives here or there. If somebody makes the call and it turns out wrong, the cost is an hour of refactoring. Those decisions should never reach me, and when I insisted on reviewing them I was spending my attention on the lowest value work available.

Other decisions are expensive to undo. The data model. Whether the system is multi tenant. The auth boundary. How money moves through the application. Getting one of those wrong is not an hour of refactoring, it is a migration, a rewrite, or an incident. Those decisions genuinely warrant a senior person in the room.

Once I said that out loud to the team, most of the queue evaporated. Not because people started making better decisions, but because they stopped asking permission for the ones where being wrong was survivable. Engineers are usually happy to take ownership. They mostly want to know where the line is.

Review What Matters, Skim What Does Not

Code review was the other place I was creating drag. I reviewed everything at the same depth, which meant a naming change got the same scrutiny as a change to the permissions layer. That is both exhausting and backwards.

What I do now:

• Anything touching auth, billing, permissions, or the data model gets a full review. Line by line, with questions about the cases the author did not mention.
• Everything else gets a structural read. Is this in the right place, does it match how the rest of the codebase works, will the next person understand it. If yes, approve. Style opinions belong in the linter, not in my comments.
• Anyone can approve anything in the second category. Not just me. Not just the seniors. The point of the split is to remove single points of failure, and appointing two bottlenecks instead of one is not an improvement.

The uncomfortable part of this is accepting that code will ship that you would have written differently. That is the cost, and it is worth paying. A codebase written entirely to one person's taste does not scale past that person's availability, and every hour you spend enforcing your preferences is an hour not spent on the decisions that actually compound.

Writing Things Down Is The Whole Job

The single highest leverage habit I picked up is writing decisions down at the moment they are made.

Not documentation in the formal sense. A short note that says: here is the decision, here is what we considered, here is why we picked this, here is what would make us revisit it. Half a page. Committed to the repository next to the code it describes.

The immediate benefit is that people stop asking. The larger benefit shows up months later when somebody, often me, looks at a strange piece of architecture and wants to know whether it is deliberate or accidental. Without the note, you cannot tell, so you either preserve something that no longer makes sense or remove something load bearing. With the note, it is a thirty second read.

This matters enormously on client work, where the team that maintains the system is frequently not the team that built it. A codebase with its reasoning written down can be handed over. One without it can only be inherited, which is a much worse experience for whoever is next.

Standups Are Usually The Wrong Tool

I stopped running daily synchronous standups on most projects and have not missed them.

The stated purpose is coordination. The actual function is usually status reporting to whoever is running the meeting, which is a manager's need rather than a team's need. Fifteen people at fifteen minutes each is a meaningful fraction of a working day, spent mostly listening to updates that do not affect you.

The replacement is written updates in a channel: what I finished, what I am on, what is blocking me. Anybody can read it in two minutes. Blockers get picked up by whoever can unblock them rather than by whoever happens to be senior. And it produces a searchable record, which a spoken standup never does.

What I kept is a genuine weekly conversation, with an agenda, where the team looks at what is coming and argues about it. That meeting earns its place. A daily recitation of yesterday's tickets does not.

The Part That Is Actually Hard

Everything above is mechanics, and mechanics are the easy half. The hard half is that scaling a team requires you to stop being the person who does the work and become the person who makes the work possible, and those roles feel completely different from the inside.

Shipping a feature gives you an immediate, legible sense of progress. Unblocking four people so they can ship four features gives you nothing to point at. The second is worth more and feels like less, and if you are not deliberate about it you will drift back to the first because it is more satisfying.

I do not think that pull ever fully goes away. I still write code, and I still enjoy it more than most of what leadership involves. What changed is that I stopped treating my own output as the measure. On a good week now, the sign that things are working is that a lot shipped and very little of it required me.