You're Accountable for the Team. You're Not in Charge of It. | Your Dev Team Coach<br>Guest post by Ryan Murphy.

The day you become a tech lead, you get handed responsibility for the team’s technical output. What you do not get handed is the authority to make anyone do anything about it.

You cannot hire. You cannot fire. You cannot set anyone’s pay. You cannot order a senior engineer to pick up the unglamorous work, or to stop gold-plating the part of the system they happen to love. You can ask. That is the whole toolkit. And yet when the project slips, when the architecture quietly rots, when the on-call rota is a shambles, it lands on you.

Tech lead reads like a promotion that comes with power. It isn’t. It is responsibility with a downgrade in how directly you can act on it. Most advice treats the move as “now lead the team,” as if leading were a switch you flip. The real problem is narrower and more uncomfortable than that. You are accountable for outcomes you can only influence, never command.

The instinct that got you the job will sink you

You were made lead because you were the strongest engineer in the room. You had the best answers, you saw the risks first, your code was the code other people learned from. That instinct is exactly what will sink you now, because the obvious move is to lead the way you earned the title, by being right.

Being right turns into just telling people what to do. You are correct, so the team does it your way. It works for a sprint. Then people stop bringing you problems, stop pushing back, stop thinking hard about the decision, because why would they when you will override them anyway. You have trained the team to wait for you. Now you are the bottleneck and the single point of failure, and the accountability you carry just got heavier, not lighter.

The three ways this goes wrong

The first is the one above. You stay right, you tell people what to do, and the team stops thinking.

The second is doing it yourself. The hard problem lands, and since you cannot make anyone else own it, and you would do it faster and better, you take it. Do that for six months and you have a team that has never once been handed the hard thing, a growing pile of work that only routes through you, and you are the most indispensable and most exhausted person on the team. Indispensable is not a compliment. It is a design flaw.

The third is backing off and not really leading at all. You know you cannot order anyone around, so you stop having strong opinions, let everything go to consensus, and call it collaboration. The team drifts. The accountability still lands on you. You have simply given up your own ability to do anything about it.

When I first led a team, my instinct was the second one. If a problem was hard, political, or risky, I took it. Partly because I cared about the people and did not want them carrying it. Partly, if I am honest, because I could not make anyone else take it and doing it myself was the path of least resistance. It felt like leadership. It was the opposite. I built a team that had never been handed the difficult thing, because I kept the difficult thing for myself. They did not grow. The work routed through me. And the moment I was unavailable, everything stalled. I had confused protecting the team with leading it, and I had quietly made myself the ceiling on what they could do.

Your job changed and nobody told you

Your job is no longer to have the best answer. It is to make the team’s output better than your individual output would have been. Those are different jobs, and they conflict more often than anyone admits.

Sometimes the right call is to let a good-enough approach win over your better one, because the engineer who owns it will execute it with conviction, and your better approach handed down as an instruction gets executed with resentment and half attention. A worse plan the team believes in beats a better plan they are enduring.

That sentence is genuinely hard for engineers, because we spend our whole careers being rewarded for correctness. Correctness is now necessary and nowhere near sufficient.

The only lever you actually hold

The lever you do have is the one that buys real influence on an engineering team: technical credibility. You earned it. That is why you are in the chair. The mistake is spending it on orders. Spend it instead on the things that compound:

Be the person who explains the why and not just the what, so people can make good calls when you are not in the room.

Let people own decisions end to end, including the ones you would have made differently, and be visibly fine when they go a way you did not pick.

Go first on the boring work, the flaky test suite, the migration nobody wants. A lead who only does the interesting parts has no standing to ask anyone else to carry the rest.

Disagree and commit out loud, so the team learns that losing an argument to you is survivable and bringing one to you is not dangerous.

None of that...