Engineering manager vs tech lead: who owns what, and what each is judged on

Titles vary. One company's tech lead is another's staff engineer, some companies have a combined tech lead manager with a small team of reports, and at a twelve-person startup one person may do all of it. Underneath the titles, the split is stable enough to put in a table. The middle column is the one people skip.

The incident row comes straight from Before the Room's chapter on incident leadership: a systems review asks what conditions let a change do damage, and a deliberate policy breach, recklessness, or the same skipped step after it was clearly named and corrected "is a management matter, handled directly by the person's manager and outside the systems review." The tech lead runs the review. The manager handles the person.

The two roles are judged on different evidence, and that difference is what an interview loop or a promotion committee is reading for.

The failure row is the same failure in two costumes. Before the Room makes the tech lead version concrete in its weekly operating system chapter, describing debriefs and calibrations where the tech lead who read as ready for more scope "was usually the one whose team kept moving while they were on vacation", and the one who read as stuck was the one whose absence stopped everything. The book flags it as one view from the hiring side, not a rule every organization follows. Read it as a hint: the strongest signal for either role is what keeps working when you are not there.

For the tech lead, there is a second test the book puts in the mouth of its opening debrief, where a strong candidate is downlevelled for answering a question about a refusing upstream team with an argument: "The room is not testing whether I am right. It is testing whether I can move something I do not control." Being technically right is the entry fee for a tech lead, not the evaluation.

This is the part of the comparison that matters most in practice, and the part candidates blur in interviews. Before the Room starts from a precise statement of what you hold at this level: technical credibility, the right to be heard, and usually not the decision rights over the systems the result depends on. Its chapter on credibility and decision rights then splits every consequential decision into five roles: someone proposes it, someone decides it, someone pays for it, someone executes it, and someone can reopen it. Run the tech lead and manager pair through those five roles and the boundary draws itself.

Three lines in the book mark the edge most clearly. On funding: for most staff engineers, a question about whether the organization funds a migration "travels through their manager or director to the portfolio sponsor; go with them, not around them." On ownership: "Caring about a decision, however much, is not a decision right." And on the high performer, the line from the opening of this article, after which the book is plain that involving the manager "is not you failing to handle it": when the pattern outlives the standard you set, you escalate it as behavior, not character. The behavior was named, the replacement was clear, the review date has passed, and the pattern held.

The boundary runs the other way too, and managers cross it as often as tech leads do. A manager who overrules a design call because they were once the strongest engineer on the team is taking a decision that belongs to the person accountable for the system. The fix is the same artifact from either side: a decision-rights map for the contested call, with one real name in each of the five roles.

If authority stops at people and capacity, what does a tech lead lead with? The book's answer is influence, carried in artifacts, and its most practical observation is that leadership of ambiguous work goes to whoever shapes it. When five teams each mean something different by "ready", the person who writes the definition of done and walks it around ends up leading the work, whatever their title, and doing so requires no rights they did not already have, because "anyone is allowed to write a sentence and ask people whether it is true."

That is the tech lead's power, and it is a lot of power. The moves are covered in depth elsewhere on this site, so I will only point to them: getting a peer team to change a decision is in influence without authority, turning an impossible date into a choice is in how to say no to a project as a tech lead, and moving a stuck decision to its owner without a status war is in how to escalate as a tech lead. What this page adds is the rule for which way to aim them: at peers and sponsors for technical and priority decisions, and at your manager, with evidence, for anything that is about people or capacity.

Most teams have both roles and never agree, out loud, where one ends. The result is either a gap, where a performance problem or a staffing call sits unowned because each assumes the other has it, or an overlap, where both weigh in on the same design and the team learns to ask whichever is more likely to say yes.

Before the Room's tool for a single contested call is the decision-rights map, appendix template 3: one decision, the five roles, a real name in each, the reopen criteria and a follow-up date. For a recurring kind of decision it has a second tool, the decision-rights transfer, appendix template 4, which names the decision class, the future owner, the guardrails, a review checkpoint and a reversal trigger. A tech lead and manager pair can use the second one on themselves in an hour. Here is the kind of split I would expect a pair to write down, as an example rather than a rule:

The row people argue about is performance. A tech lead sees the work every day and the manager often does not, so the tech lead's evidence is essential. The decision still belongs to the manager, because it carries consequences, for pay, for level, for whether someone stays, that a tech lead is not accountable for and should not be making alone.

The variants of this search, career path tech lead vs manager, engineering lead vs manager, usually come from one person at one moment: a strong senior engineer who has been offered one of the two, or both, and suspects the choice is bigger than it looks. It is. Four questions help more than a pros and cons list.

• Which problem do you want to wake up with on a bad week? A design that has to hold for two years and a migration that is stuck at ninety percent, or a person who is struggling, a hire you have to close and a team that has to keep shipping while you are in meetings about all of it.
• Where do you want your evidence to come from? A tech lead's best evidence is a system and its decision records. A manager's is other people's growth, which is slower to show and harder to claim.
• Can you have a performance conversation you would rather avoid, and have it early? If the honest answer is no, management will cost more than it looks like from outside.
• Are you choosing management to get authority? That is the one reason I would push back on.

The last question deserves the most weight, because the authority gap does not close when you change ladders. Before the Room's chapter on responsibility without control makes the point with a composite engineer whose director named her, in an email, as the person driving a checkout migration, then adds that the director "is managing the same gap one level up, moving outcomes through peers she cannot direct." A manager has authority over their own team's people and capacity. Over the peer teams, the product priorities and the platform the result depends on, they have the same tools a tech lead has: credibility, artifacts and the right owner.

The cheapest way to decide is to test the work before the title. Run interview loops and sit in the debriefs. Mentor one engineer through a hard quarter. Take a class of decisions off your manager with a written transfer and a review point, and see whether you enjoy owning it. In many companies the move between the two tracks is reversible, but how often people go back, and at what level, differs a great deal, so ask where you work. If you choose the technical path, the next question is how a tech lead grows into staff scope, which is covered in staff iOS engineer is not senior plus.

The two loops overlap more than candidates expect, and the overlap is where the role difference shows. Loops differ by company, but the shape is usually this.

The most revealing questions are the ones both loops ask, because the right answer changes with the role. Take "tell me about a strong engineer who shut down discussion on your team." From a tech lead candidate, I want to hear the review rule: objections name the failure mode and say whether they are a blocker or a preference, reversible calls get settled on evidence, and when the pattern held after that, the tech lead took dated examples to the manager. From a manager candidate, I want to hear the part the tech lead could not do: what changed in role expectations, in how rescues were rewarded, and in the performance conversation. A tech lead candidate who describes changing someone's rating, or a manager candidate who describes winning the design argument personally, has answered for the other job.

For the full sets, see the guides to mobile tech lead interview questions and mobile engineering manager interview questions. If you are building the evidence for a staff promotion on the technical path, the staff engineer promotion packet article covers what a calibration committee can actually read.

Two limits are worth saying plainly. First, titles are local. A combined tech lead manager role exists in many companies, small companies blur everything, and some organizations give tech leads formal input into reviews. Read the job description for who has direct reports, who writes performance reviews and who decides headcount, and trust that over the title.

Second, knowing where your authority stops does not make the gap your problem to absorb. Before the Room ends its list of when to stop using its methods with this: "Your ability to lead without authority does not excuse leadership from providing the authority or staffing the work needs." If you are a tech lead carrying work that needs a manager's decision and nobody is making it, the move is to name that gap to your manager, in writing, not to make the decision quietly yourself.

The short version fits on a card. The tech lead owns decisions about the system and leads through influence. The manager owns decisions about people and capacity and is judged on the team without them. Write the split down with your counterpart, choose your path by the problem you want to own, and do not mistake either title for the authority to move what you do not control.

What is the difference between a tech lead and an engineering manager?

The short version is decisions versus people. A tech lead owns the technical direction of a team's work: design calls, technical risk, the quality bar and how the plan gets built. An engineering manager owns the people and the capacity: hiring, performance, growth, staffing and who works on what. Titles differ by company, and some roles combine both, so check the job description for who has direct reports and who writes performance reviews.

Is a tech lead a manager?

Usually not. In most companies a tech lead is an individual contributor role with no direct reports, even though it carries leadership work. A tech lead can name a behavior, set a review norm and run the design conversation differently; changing role expectations, performance outcomes and what gets rewarded belongs to the manager. Some companies use a combined tech lead manager role, which does have reports.

Is engineering manager a promotion from tech lead?

Not by itself. Many companies run two parallel ladders, one for individual contributors through staff and principal and one for managers, and moving from tech lead to manager is a change of job, not a step up the same ladder. Ask how your company levels the two tracks before you treat the move as a promotion.

Can I go back from engineering manager to tech lead or staff engineer?

In many companies, yes, but it depends on the company, so ask how often it happens there and at what level people return. The safer way to decide is to test the manager work before you switch: run interview loops, mentor someone through a hard quarter, own a class of decisions with a review point, and notice which parts you look forward to.

Should I become a tech lead or an engineering manager?

Choose by the problem you want to own on a bad week. If you want to wake up thinking about a design that has to hold for two years, the tech lead and staff path fits. If you want to wake up thinking about a person who is struggling, a hire you have to make and a team that has to keep shipping without you, management fits. Do not choose management to get authority: the gap between what you are accountable for and what you can command exists at every level.