Stop writing code: Why your most important PR is the one you never open

Let me provoke you first

You became a tech lead because you were good at writing code.

Now that skill is standing in your way.

Not because code doesn’t matter. But because your team has many people who can write code, and only one who can do your job. Every time you choose the keyboard, you give up something else: the review that was waiting, the question that stayed open, the standard that quietly cracked.

The math no one shows you

A good developer produces value linearly: one hour in, one hour of work out.

A good tech lead produces value multiplicatively: one hour spent closing a decision can save developers a week of guessing. One hour spent on a TDR can prevent months of repeated discussions. One hour spent heading off divergence can save months of cleanup. Think of this as a model rather than a formula – the tech lead’s leverage comes from removing blockers and creating conditions for other people to move.

As I wrote in Decision latency: teams are rarely slowed down by missing code. They are slowed down by open questions. And open questions don’t get closed by you sitting with headphones on, typing.

“But I’ll lose credibility if I don’t code!”

The objection is real – and it’s half right.

You should be in the code. Reading PRs. Picking up the occasional bug. Keeping a feel for the system. A tech lead who no longer understands the codebase can’t set the frame for it.

But there’s a difference between being in the code and being the bottleneck in it. The test is simple: if a critical task can only be solved by you, you haven’t proven your value. You’ve exposed a risk.

The most important PR

So what is your most important pull request?

It’s the one you don’t open, because instead you:

• let a developer own the solution, with you as a sparring partner
• spent the time making the quality expectations explicit
• wrote the principle down, so the question never gets asked again

It feels less productive. It’s the opposite.

What can the team do without you?

You didn’t become a tech lead to be the team’s best developer. You became one to make the team better than its best developer.

Put down the keyboard. A little. It’s the hardest refactoring you’ll ever do.