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 compels anyone to do anything. All of it makes the path you want the easiest and most respected path to walk, and then lets people choose to walk it. That is the entire game when you have no formal power. You are not issuing orders. You are removing the friction from the right decision until following you is simply the obvious thing to do.
The accountability never balances out
You will answer for outcomes you could only nudge. That asymmetry is not a flaw in your particular situation that more seniority will eventually fix. It is the job.
The engineers who do well as leads are the ones who stop waiting for the authority to arrive and get good at the only lever they actually hold. The ones who struggle spend years quietly resentful that they are responsible for a team that does not have to listen to them. They are right about the facts and missing the point.
Final thoughts
You are accountable for the team. You are not in charge of it. Those two facts do not resolve, and the faster you stop trying to make them resolve, the faster you get good at the role.
The authority you keep wishing for would make you worse anyway. It would let you command instead of convince, and convincing is the skill that separates a tech lead people tolerate from one they would follow to their next company. You already have the technical respect. The work now is learning to lead with it, rather than waiting for something more official to lead on top of it.
Ryan Murphy spent nearly twenty years in software engineering and built and led engineering teams at Yelp. He writes The Software Engineering Times and runs EM Accelerator, a premium training platform for engineering managers. He recently built a quiz on the five types of engineering leader. Find out yours for free here.