From senior developer to tech lead: what changes when the outcome is yours and the authority is not

Before the Room opens its preface with the sentence that names this transition better than any job description I have read: "This book is about the gap that opens when you become the person a result depends on before anyone gives you the authority to command it." The book calls that distance the authority gap: what you are accountable for, minus what you are allowed to command.

As an individual contributor, Priya was responsible mostly for what she could change. Then, in the book's words, "her accountability has crossed the boundary of her control, and being correct and capable, still necessary, has stopped being sufficient." That second clause is the whole transition. The skills that got you the role are now the entry fee, and from the inside the gap feels like needing more of what always worked. So you bring better data, and you work later.

The book is precise about what you are left holding. You reliably hold technical credibility, the right to be heard. You usually do not hold decision rights over the systems your result depends on: the other team's roadmap, the rollback design a Friday review comment can reopen, the date a director has already repeated to a partner. Once you say that plainly, the situation stops being a mood and becomes a map. The book's one-sentence version is worth writing down about your own role: you are responsible for an outcome produced by decisions you do not own, made by people you do not manage, driven by incentives you did not set.

Side by side, the senior engineer vs tech lead differences look like this:

The question that replaces "how do I fix this" is the book's line for this chapter, and I would keep it on a card: "I do not own this decision, so who does, and what would move them?"

The instinct, the first few times, is to treat the gap as a staffing error: someone forgot to hand over the authority that should come with the accountability, and once the reorg settles or the title arrives, the rights will catch up. Before the Room's observation is that they mostly do not. The director who wrote Priya's email is managing the same gap one level up, moving outcomes through peers she cannot direct. The gap rarely closes as you climb; it becomes much of the content of the role.

That is why the book reads promotion at these levels as largely a bet on skill at operating without authority, and why it says the moment of leadership "does not wait for a title". You can start practicing the job before you have it, on decisions your own team owns, and the book's level line says that is exactly where a senior engineer starts: running the moves on a design they are bringing to review, before running them on a decision owned elsewhere.

For the interview version of this skill, the question "tell me about a time you influenced a decision without authority", see the influence without authority answer, scored. This page stays on the job itself.

Before the Room does not prescribe a 90-day plan. It has a weekly operating system and a thirty-day repair, and it is a field guide built to be used on a current problem. What follows is how I would sequence its tools across a new tech lead's first three months. Each month has to produce something you can point at, not only something you learned.

Days 1 to 30: map before you change anything. Write your authority gap in one sentence, with names in it. Then list the decisions people already assume you own, and for the heavy ones fill in the book's decision-rights map: who proposes, who decides, who pays, who executes, and who can reopen. The reopen row is the one people leave blank, and it is the one that reverses decisions you thought were settled. On a mobile team, four questions belong on the map in the first two weeks, because the answers are rarely written down:

• Who owns the release train, and who can stop a release that is already in review or rolling out?
• Who decides the minimum supported app version, and how is an old version actually retired? Neither store forces an update on its own; the app has to trigger it.
• Who gets paged when the app breaks at three in the morning, and does that team know it yet?
• Which dates have already been promised outside the team, and who made the promise?

Resist one thing in month one: correcting everything you would do differently. You will be right about a naming convention, a test strategy and a log format, and the book's warning is that credibility spent on each correction makes the one objection that matters land as one more. Pick the hill. Write the others down for later.

Days 31 to 60: make one decision durable, and publish how decisions reach you. Take the most ambiguous thing your team is committed to and write its acceptance sentence, the line that completes "we will call this done when". The book's chapter on ambiguity is blunt about who leads: whoever converts the ambiguity into owners and a definition of done usually ends up leading the work, whatever their title, and it requires no rights you do not already have, because "anyone is allowed to write a sentence and ask people whether it is true." Record one real decision with a named owner and the evidence that would reopen it. Then publish your intake rule as one paragraph. The book's version is a good default: local implementation choices stay with the team, cross-team, irreversible and reliability decisions come through written intake with a recommendation and the alternatives, and "if someone can own a decision with context and a review point, I will not take it back."

Days 61 to 90: keep one promise and give one decision away. Choose one real gap and run the book's thirty-day repair on it: week one, diagnose the hidden decision, its owner and the incentive holding it stuck, and set the escalation threshold; week two, take the map to two people who see it differently and let them change it; week three, put one artifact in front of the owner and ask for a specific decision; week four, check the signal and decide whether to escalate, close or continue. The book's worked example is a mobile one: release builds keep failing on a pipeline another team owns, and the hidden decision is whether that team treats the mobile build path as a supported product. In the same month, move one class of decisions, such as local library adoption, to a team lead in writing, with guardrails and one review point. Then do the hard part and leave it there.

At day 90 you should be able to show three objects: a decision-rights map that survived contact with reality, one decision that is still closed, and one gap with a named owner that was not there before. That is more persuasive in your first review than a list of everything you attended.

Job descriptions for tech leads list technical direction, mentoring, delivery and stakeholder communication. All true, and almost none of it tells you what the people deciding your next level are looking at. From the hiring side, and in the debriefs Before the Room draws on, the evaluated responsibilities are narrower and more concrete:

Two of those deserve a sentence from the book, because they are the ones new tech leads miss. On closing decisions: "tech leads who stall tend to win reviews and lose threads". The review was one visible event; the decision gets remade every time the code is touched, in a pull request comment at night or a chat thread you were not in, and only a written record with an owner and reopen criteria lets you interrupt without relitigating.

On routing, the book's chapter on the weekly operating system gives the clearest test I know, from the debrief side: "the tech lead who read as ready for more scope was usually the one whose team kept moving while they were on vacation." The one who read as stuck was the one whose absence stopped everything and who described that as proof of being essential. The book adds that this is one view and not every organization reads it that way, which is fair. It is still the view of the people in the room.

What is missing from the table matters as much. The number of tickets you closed, how fast you answer messages, and how many pull requests you reviewed are not on it. Answering faster feels like leverage until every decision in the team queues behind your response time, and your speed becomes the ceiling on everyone else's autonomy. When the review arrives, the evidence for all of this has to exist already; the staff promotion packet article covers the ledger that keeps it.

Before the Room names three fixes strong engineers reach for when they first feel the gap, and says all three keep them stuck. They are worth listing because each one feels like integrity from the inside.

• Being more right. More data, a cleaner diagram, a tighter proof. Sometimes it works. When the resistance comes from an incentive, a better argument can make the proposal look more threatening instead of more persuasive. The test the book gives for telling the two apart: a technical objection names a failure mode and gets more precise when answered; an incentive conflict is "not ready" or "too early", and a new objection replaces the old one with the same conclusion.
• Carrying it yourself. The three late nights. It scales until it does not, and it teaches the organization that nothing needs to change. The quieter version is registering privately that a date is shaky and resolving to make it work, which hides the decision from the only person who can make it.
• Private frustration. The org is broken, the other teams are irrational, and you retreat into being correct and unheard. None of the three touches the decision, and the decision is where outcomes are won.

Four more show up once the role is real:

• Answering the visible request. A director asks whether you are still on track for the fifteenth. You check the board and reply yellow, trending green. Ten days later the fifteenth is a hard commitment to a partner, and your status was the cover. The stronger reply asks first whether they are deciding to commit the date outside the team, because your confidence for an internal target and for an external promise are different numbers.
• Treating the nod as the decision. The design review agrees, you start building, and on Thursday someone who was not in the room reopens it. The check takes one sentence before relief sets in: who actually owns this decision, and who could reopen it who is not in this room? As the book puts it, "Caring about a decision, however much, is not a decision right."
• Delegating and keeping the veto. You hand a class of decisions to a team lead, then re-review every call. In the book's words, "Re-review every call and you have kept the veto and handed over only the typing", and the team learns the transfer was never real.
• Waiting for the authority to arrive. Covered above, and the most expensive of the seven, because it looks like patience.

There is also an overcorrection, and new tech leads who have just learned to look for hidden decisions fall into it. Not every request hides one. Answer "what is the status of the flaky test" with "help me understand what you are deciding" for the third time and people stop bringing you questions. The book's tell is weight: surface when a wrong answer would commit someone to something, when the asker has more riding on it than the words suggest, or when the timing is odd. Answer fast on everything else.

The authority gap is normal. Some gaps are not. Before the Room draws two boundaries that a new tech lead should know before the first hard quarter. First, naming what you hold does not manufacture influence you do not have: if you have neither credibility with the decision owner nor a path to them, the honest step may be to refuse the accountability rather than absorb a risk you cannot move. Second, your ability to lead without authority does not excuse leadership from providing the authority or the staffing the work needs. If you are the only one still carrying it, that is a gap to name to your manager, not a test of your endurance.

When the gap is real and the decision belongs above you, the move is an escalation, not a heroic weekend; see how to escalate as a tech lead. For the daily habits that keep you from becoming the person others chase in the first place, see the engineer nobody chases. If you are preparing for interviews for the role rather than starting it, the guide to mobile tech lead interview questions covers what each question is scoring.

The short version fits on a card. You are no longer paid to have the best answer in the room. Find the decision under the problem, name its owner, put it in writing, and check a week later that it held. Then give it away.

What is the difference between a senior engineer and a tech lead?

A senior engineer is mostly responsible for what they can change: their code, their design, their part of the plan. A tech lead is responsible for an outcome produced by decisions they do not own, made by people they do not manage. Being right is still required, but it stops being enough. The work moves from solving the problem to finding the decision under it, getting it to the person who owns it, and keeping it decided.

How do I become a tech lead?

Do the parts of the job that need no title first, inside the decisions your own team owns: write the definition of done nobody wrote, ask who owns a decision before building on a meeting's nod, and turn a vague status question into the decision it is hiding. Keep a record of the decisions you moved while the work is live, and tell your manager which behavior you are building, so the evidence is visible before the role opens.

What should a new tech lead do in the first 90 days?

In the first month, map before you change anything: write your authority gap in one sentence and find out who decides, who pays and who can reopen the decisions you are assumed to own. In the second, make one decision durable and publish how decisions reach you. In the third, close one real gap end to end with a thirty-day repair and give one class of decisions away without taking it back.

What are the responsibilities of a tech lead?

The ones that get evaluated are turning ambiguous work into an inspectable definition of done, closing decisions so they stay closed, owning promises through costed options instead of revised dates, making status mean integrated evidence, escalating decisions rather than frustrations, bringing order to an incident, and routing work so the team keeps moving when you are away. Code and review still matter; in the book's phrase, correct answers are the entry fee, not the part of the role that changes.

Should I accept a tech lead role that comes without any authority?

The authority gap is normal; it is most of the job, and waiting for the rights to catch up rarely works. The boundary is narrower: if you have neither credibility with the people who own the decisions nor a path to them, the honest step may be to refuse the accountability rather than absorb a risk you cannot move. And if you end up the only one carrying the work, name that gap to your manager.