Tech lead vs engineering manager: when you need one

Why this choice gets messy fast

Teams usually ask about a tech lead versus an engineering manager when growth starts to hurt. More people join, more code ships, and the old way of working stops holding together. Everyone feels the drag, but the cause is easy to misread.

Most small teams expect one person to solve two different problems at once. They want cleaner code, faster technical calls, better coaching, steadier delivery, and fewer team issues. That sounds efficient. It usually is not.

Technical direction needs someone who can say, "We will build it this way," and stay close enough to the code to keep that choice consistent. Team management needs someone who can coach, hire, handle conflict, set goals, and protect focus. One person can cover both jobs for a while. Growing teams usually pay for that later.

The first thing that slows down is decision making. When nobody clearly owns technical direction, every important choice turns into a group debate. Should the team refactor now or ship first? Which pattern should they use? Who decides whether a shortcut is acceptable? These questions sit in chat, bounce through meetings, or get settled by whoever speaks first.

Then a second problem shows up. Engineering managers start reviewing pull requests, settling design arguments, and chasing review debt instead of managing people. They spend their day inside the work rather than improving how the team works. The team still lacks clear technical direction, and the manager has less time for real management.

Senior engineers often step in to fill the gap. That works briefly. After a few weeks, one person approves most changes, another sets informal standards, and a third makes architecture calls when things feel urgent. The work gets done, but authority stays blurry.

Blurry ownership does quiet damage. People hesitate, duplicate work, reopen old decisions, and ask the wrong person for approval. Nobody plans that outcome. It happens when a team adds responsibility without naming an owner.

Signs you need a tech lead first

Look at where work gets stuck. If the team ships code but slows down on technical calls, a tech lead usually fixes the problem sooner than a manager.

One clear sign is decision stall. The team debates service boundaries, database changes, or API shape for days and waits for full group agreement before anyone moves. That can look collaborative, but it burns time and leaves the hardest calls hanging.

Pull requests tell the same story. If reviews sit open for two or three days, or comments go in circles with no final call, the first problem is not people management. It is review debt and missing technical ownership.

Another clue is inconsistency. Two engineers solve the same problem in different ways, both seem reasonable, and now the codebase has two patterns for logging, testing, or state handling. A tech lead sets a default and stops the codebase from drifting.

Product delays often come next. A feature looks simple on the roadmap, then slips because nobody settles the tradeoffs between speed, quality, and future maintenance. In that moment, teams usually do not need another manager. They need one person close to the code who can say, "We will do it this way, and here is why."

Watch new hires closely. If they ask who approves design changes, who decides when to refactor, or whose opinion breaks a tie, and nobody answers clearly, ownership is already fuzzy. That confusion spreads fast. Senior engineers step on each other, mid level engineers hesitate, and junior engineers wait for permission that never comes.

A small startup often hits this point around five to eight engineers. Everyone still talks to everyone, but nobody owns technical direction across the team. Meetings get longer, reviews get slower, and product promises start to slip.

That is usually the moment to add a tech lead first. The team needs faster decisions, quicker reviews, and one person who keeps technical choices consistent week after week.

What a tech lead should own

When a team needs faster technical decisions, the tech lead should own the work that keeps code moving in one direction. This role stays close to design, delivery, and code quality.

A good tech lead sets the coding direction for the team. That does not mean writing every hard part alone. It means choosing sane patterns, naming a default approach, and ending debates before they drag on for a week. If the team builds APIs, for example, the lead decides how endpoints, errors, and versioning should work so every engineer does not invent a new style.

The role should also own risky reviews. Most pull requests do not need senior attention, but some do. Changes to auth, billing, database structure, public APIs, or anything hard to roll back deserve a careful review from the tech lead. That review should unblock work, not slow it down.

Large technical choices need an owner too. A tech lead takes a fuzzy question like "Should we split this service?" and turns it into a few clear options with tradeoffs, cost, and likely failure points. Teams get stuck when everybody sees the problem but nobody frames the decision.

Standards belong here too, but only when they stay practical. A lead should keep rules current, remove the ones nobody follows, and add guidance where bugs keep repeating. Good standards save time. Bad ones create ceremony.

On a lean team, that often means picking one testing level to trust for most changes, stepping into reviews that can break production, writing short design notes before bigger work, updating team rules when tools or scale change, and helping engineers cut large tasks into smaller shippable pieces.

Coaching is part of the job, but it is hands on coaching. A tech lead helps engineers think through design, spot risk earlier, and recover when a task goes sideways. Sometimes the most useful move is a quick whiteboard session or a short comment that says, "Keep this simple. We can split it later."

This matters even more on small teams using AI coding tools. Those tools can produce a lot of code quickly, but they do not set clean system boundaries. The tech lead decides where speed is fine and where human judgment needs to stay close, especially around data, security, and public behavior.

If arguments drop, reviews get cleaner, and less work sits stuck, the tech lead owns the right things.

What an engineering manager should own

An engineering manager owns the team as a group of people doing work together. That means hiring, feedback, growth, workload, and the daily conditions that let engineers do solid work. If nobody owns those things, the team drifts even when the code looks fine.

A manager should run one to one meetings on a steady schedule and use them well. These are not status meetings. They are for career goals, blockers, team friction, and the small problems people hide until they turn into resignations or missed deadlines.

Feedback also sits with the manager. Engineers should know what good work looks like, where they are strong, and what they need to improve. When performance slips, the manager should address it early with clear examples and a plan, rather than hoping extra code review will fix it.

Staffing is part of the same job. The manager decides when the team needs another engineer, when a role no longer fits the stage of the company, and who is ready for more scope. Growth plans matter here too. Good people leave when nobody helps them grow.

The manager also protects focus. During planning and delivery, someone needs to push back on random requests, reshuffle work when priorities change, and keep the team from carrying too much at once. If every engineer gets dragged into meetings and urgent side work, output drops fast.

Conflict and workload problems belong here as well. If two engineers keep stepping on each other, or one person quietly carries the hardest tasks every sprint, the manager needs to step in. Leaving it alone usually turns into resentment, slower delivery, and messy handoffs.

This role also connects the team with product and leadership. The manager turns broad goals into clear priorities, explains tradeoffs, and makes sure engineers are not hearing three different versions of what matters. The split is simple: the tech lead guides technical direction, while the manager makes sure the team can deliver it week after week.

How to decide in five steps

Make the choice from real problems, not from titles that sound mature. Most teams do not need to solve the whole question at once. They need to fix the gap that keeps slowing work down.

Use a short review window instead of relying on a vague feeling about the last year. Six weeks is enough to spot patterns and short enough that people still remember what happened.

1. Look back at the last six weeks and write down every stall. Keep it concrete: pull requests waited for days, nobody approved an architecture change, two engineers argued over the same approach, or sprint scope changed after work had already started.
2. Mark each problem as technical, people, or planning. Technical problems include review debt, weak design choices, or unclear standards. People problems include feedback, conflict, and burnout. Planning problems include priorities, deadlines, and shifting scope.
3. Count where senior engineers lose the most time. If your strongest engineers spend hours unblocking code, reviewing risky changes, and making architecture calls, you probably need a tech lead first. If they spend that time hiring, coaching, running one to ones, or calming team friction, you likely need an engineering manager.
4. Check who makes the final call on code, architecture, and scope. Write one name next to each. If nobody owns the final decision, you are already paying for weak ownership.
5. Add the smallest role that fixes the worst delay. Do not create a wide job just because the team feels messy. Give one person clear ownership for the bottleneck you see most often.

A simple test helps. If one strong engineer can take clearer technical ownership and cut review delays in half, start there. If the team still misses deadlines because nobody manages workload, feedback, or planning, then add an engineering manager.

Outside help can save time here. A fractional CTO can review the team, find the bottleneck, and keep you from hiring the wrong role too early. That is often cheaper than adding a full manager and discovering six months later that the real problem was unclear technical decisions.

A simple example from a growing startup

Picture a startup with six developers. They ship often, customers keep asking for more, and nobody feels fully stuck. On paper, the team looks fine.

Then friction starts to pile up. Two developers prefer one backend pattern, two want another, and the rest wait for someone else to decide. Small choices turn into long threads, and bigger changes sit open for days because everyone wants approval from the same two people.

The founder ends up doing the worst kind of extra work. During the day, they talk to customers and chase growth. At night, they settle arguments about service boundaries, naming, and whether a shortcut will hurt the codebase three months later.

That is usually the point where a tech lead helps more than an engineering manager. The team does not need more status meetings yet. It needs one person to make technical calls, set a review rhythm, and give the codebase clearer ownership.

A good tech lead can take a lot off the founder's plate. They can choose a default backend approach for new work, set review rules so pull requests stop waiting on the same two people, write short design notes before larger changes, and assign clear owners for each part of the system.

Once that happens, the team often moves faster within a few weeks. Reviews stop piling up. Fewer debates spread across the whole team. Developers still disagree sometimes, but they stop reopening the same question every sprint.

The founder also gets time back. Instead of acting as the final reviewer for every hard decision, they only step in on product tradeoffs or high risk bets.

A full engineering manager can still wait. If nobody struggles with hiring, one to ones, performance feedback, or team conflict, adding that role too early may just create extra process. In a team like this, the first gap is technical direction, not people management.

Mistakes teams make when adding the role

Teams often get this wrong because they add a title before they change the work. The org chart looks cleaner, but the same decisions still bounce around chat, pull requests still wait, and nobody knows who can say yes.

One common mistake is giving a new tech lead people management on day one. If that person now runs reviews, salary talks, and hiring loops, their technical time disappears fast. A tech lead can help people grow, but formal performance work usually turns the role into a manager job.

Another mistake is keeping ownership vague. Some teams announce a lead, then leave architecture calls, release calls, and review standards shared across five people. The new lead gets blame without authority, which burns people out quickly.

A strong coder is not always the right pick either. If your top engineer hates mentoring, avoids hard conversations, or keeps rewriting other people's code instead of guiding them, the team will feel it. A tech lead does not need to be the loudest person in the room, but they do need to coach others and close decisions.

A few patterns show up again and again. Teams hire an engineering manager to fix review debt when the real problem is missing technical direction. They keep approval rules fuzzy after the change, so developers still chase three different opinions. They expect one person to own delivery quality without giving them control over scope or standards. Or they treat the title like a reward instead of a job with real tradeoffs.

This often starts small. A founder promotes the best programmer, assumes the process will sort itself out, and two months later the review queue is longer than before. The new lead is buried in meetings, senior engineers argue over design, and junior developers wait for answers.

Keep the change concrete. Decide who owns review standards, final technical calls, mentoring, and team health before you announce anything. If you cannot name those owners in one short document, the role is still vague.

Quick checks before you create the title

A new title will not fix a blurry job. Check the work first. Most teams can tell what they need by looking at a normal week instead of staring at an org chart.

Start with technical direction. If nobody can say yes or no on architecture, tools, or tradeoffs without a long debate, the team already has a gap. That usually points to a tech lead, especially when engineers keep reopening the same decisions.

Review speed is another easy test. Healthy teams move pull requests in a day or two for normal changes. If reviews sit for days, comments pile up, and nobody feels responsible for closing them, you may not have a management problem. You may have review debt and no clear technical owner.

Standards tell the same story. Engineers should know who decides what "good enough" means for testing, naming, monitoring, and release safety. If everyone has an opinion and nobody has the final call, work slows down and small disagreements turn into recurring arguments.

Watch the founder's calendar too. When the founder still settles most technical disagreements, the team is borrowing authority instead of holding it. That may work for five people. It usually breaks once the product and team start growing.

A quick gut check helps. One person should be able to approve technical direction today. Reviews should usually move within 24 to 48 hours. Engineers should know who owns standards. The founder should not be the default tie breaker. And delivery problems should be more urgent than people problems if you are leaning toward a tech lead.

If most of those statements are false, do not treat the debate as if both roles solve the same issue. They do not. A tech lead clears technical stalls, sets standards, and keeps delivery moving. An engineering manager handles hiring, feedback, conflict, and team health.

One last filter is simple: where does the pain show up first? If releases slip because decisions drag, reviews stall, and ownership is muddy, hire or appoint a tech lead first. If the team writes decent code but struggles with feedback, conflict, missed expectations, or uneven growth, an engineering manager will help more.

What to do next

Before you create a new title, write down the exact decisions this person will own. Be plain about it. If you need someone to break technical deadlocks, approve architecture changes, set coding standards, and keep reviews moving, say that.

Vague ownership causes most of the mess here. When two people think they can make the same call, the team slows down. When nobody owns the call, the team circles the issue for days.

A short trial works better than a permanent org change. Pick one person, give them a narrow role for one delivery cycle, and tell the team what that role covers. One sprint can be enough for a small team. A month is often enough for a bigger one.

Track a few simple measures before and after the trial: how long pull requests wait for review, how long technical decisions stay open, how much rework appears after a decision changes, and how often work bounces between people because ownership is unclear.

Numbers help because memory gets fuzzy fast. A team may feel better after a role change, but the real test is whether review debt drops, decisions land faster, and fewer tickets come back for rewrites.

If the trial helps, make the role official and keep the scope tight. If the numbers barely move, stop and look again. You may need a different split of work, or you may need an engineering manager instead of a tech lead.

If the picture still looks messy, an outside review can save time and money. Oleg Sotnikov at oleg.is advises startups and small businesses on team structure, product architecture, infrastructure, and practical AI adoption. A short review is often cheaper than hiring the wrong role and undoing it later.