There’s a particular species of tech lead that makes me want to file a ticket against the org chart. You know the one. They run standup, hand out work, sit in every planning meeting, have opinions about your variable names — and then, the moment you ask them to make an actual architecture call, they turn into a null pointer. This is the tech lead who is management without the title. All the accountability of leadership, none of the authority. All the meeting load of a manager, none of the budget. All the code review power of a senior engineer, none of the time to actually read the diff.
I call this the phantom manager pattern. It sits right next to the accidental manager, the lead by default, and the senior engineer who got promoted into a spreadsheet. It matters because it’s one of the most reliable ways to burn out your best people while telling yourself you’re developing leaders. The gap between what engineering teams say they value — autonomy, ownership, technical excellence — and what they actually do shows up in the operational signals. Deployment frequency drops. Code review latency spikes. Incident response turns into hot potato. Documentation freshness decays like an unmaintained cron job.
This is a systems problem, not a people problem. And like most systems problems, you can debug it if you stop blaming the individual and start looking at the feedback loops.
The Tech Lead Role Is a Race Condition
In most orgs, the tech lead role is defined by what it isn’t. It isn’t a manager, because managers do performance reviews and have direct reports. It isn’t a pure senior engineer, because seniors are supposed to write code and mentor. It isn’t an architect, because architects are supposed to draw boxes and disappear. So the tech lead becomes the catch-all thread that handles every blocking call the team generates.
This is a race condition. The tech lead is expected to:
- Run standup and sprint planning
- Review every pull request
- Write code for the hardest tickets
- Talk to product managers about scope
- Talk to other tech leads about cross-team dependencies
- Mentor junior engineers
- Debug production incidents
- Keep the documentation up to date
- Attend architecture review meetings
- Explain to the VP why the estimate was wrong
Every one of those is a blocking call. The tech lead is the only thread that can handle them. The result is predictable: the tech lead becomes a bottleneck, the team waits, and the work slows down. The operational signal is code review latency. If pull requests sit for days waiting on one person, you have a single-threaded bottleneck. The fix isn’t to tell the tech lead to work harder. The fix is to make the role non-blocking.
Management Without the Title Is a Legacy System
Here’s the uncomfortable truth: a tech lead who is management without the title is running a legacy system. The role was designed for a different era, when teams were smaller, codebases were simpler, and the distance between a decision and its consequence was short. Now the role gets patched with new responsibilities every quarter, like a monolith that keeps getting new endpoints bolted on. Nobody wants to refactor it, because that would mean admitting the org chart is wrong.
The symptoms are easy to spot if you look at the operational signals:
- Deployment frequency drops because the tech lead is the only one who can approve releases, and they’re in meetings all day.
- Incident response patterns become erratic because the tech lead is the de facto incident commander, but they’re also the only person who knows the database schema.
- Documentation freshness decays because the tech lead is supposed to keep it updated, but they’re too busy unblocking everyone else.
- Code review latency spikes because the tech lead is the only reviewer with enough context, and context is a finite resource.
These aren’t personal failures. They’re system outputs. The system is designed to route everything through one person, and then the system acts surprised when that person becomes a bottleneck. It’s like designing a load balancer with a single backend and then wondering why the site goes down on Black Friday.
The Authority Gap Is a Deadlock
The core problem with management without the title is the authority gap. The tech lead is expected to make decisions, but they can’t actually enforce them. They can suggest a coding standard, but they can’t put it in the performance review. They can recommend a refactor, but they can’t allocate budget for it. They can flag a toxic team dynamic, but they can’t fire anyone. They can push back on scope, but the product manager reports to someone else.
This is a deadlock. The tech lead is holding a lock on the team’s technical direction, but they’re waiting for a lock on authority that never gets released. The team sees the tech lead as a leader, but the org chart says they’re just a senior engineer with extra meetings. The result is decision paralysis. The tech lead stops making decisions because every decision gets overridden or ignored, and the team stops asking because they know the answer will be “I’ll check with the manager.”
The operational signal here is incident response patterns. When an incident happens, does the team know who’s in charge? Or does everyone wait for the tech lead to show up, and then the tech lead waits for the manager to approve the rollback? If your incident response looks like a game of telephone, you have an authority gap.
Why This Pattern Persists
You’d think a role this broken would get fixed. But the phantom manager pattern persists because it serves a purpose for the organization. It’s a cheap way to get management work done without paying for managers. The tech lead absorbs the coordination overhead, the meeting load, the cross-team communication, and the planning work — all without a title change, a pay bump, or a direct report. The org gets a manager for the price of a senior engineer.
This isn’t a bug. It’s a feature. The system is working exactly as designed. The problem is that the design is bad.
There’s also a cultural factor. Many engineers get promoted to tech lead because they’re good at writing code, not because they’re good at leading. The org assumes technical skill translates to leadership skill, which is like assuming a great quarterback will automatically be a great coach. The skills are related, but they aren’t the same. The result is a tech lead who’s excellent at debugging a race condition in the codebase and terrible at debugging a race condition in the team’s communication patterns.
What the Tech Lead Actually Needs
If you’re a tech lead stuck in this pattern, here’s what you actually need, in order of priority:
- Decision authority. You need to be able to make a technical decision and have it stick. If you can’t do that, you’re not a lead. You’re a suggestion box.
- Time to write code. If you’re not writing code, you’re losing context. And if you’re losing context, your code reviews are worthless. Block off at least one full day a week for deep work.
- A manager who actually manages. You need someone above you who handles the people stuff — performance reviews, career conversations, conflict resolution — so you can focus on the technical stuff. If your manager is also a phantom manager, you’re both doomed.
- A clear scope. You need to know what you’re responsible for and what you’re not. If the answer is “everything,” that’s not a scope. That’s a trap.
- A path to a real title. If you’re doing management work, you should get the management title and the management pay. If the org won’t give you that, start looking for an org that will.
How to Debug the Phantom Manager Pattern
If you’re a manager or a director reading this and you recognize the pattern in your own org, here’s how to debug it. Treat it like a production incident, because that’s what it is.
Step 1: Measure the Bottleneck
Look at your operational signals. What’s the code review latency? How many pull requests are waiting on one person? How many meetings does your tech lead attend per week? How many decisions get escalated to them? If the answer to any of these is “too many,” you have a bottleneck.
Step 2: Identify the Missing Locks
What authority does the tech lead actually have? Can they approve a refactor? Can they change the sprint scope? Can they tell a senior engineer to stop bikeshedding? If the answer is no, you have an authority gap. Fix it by giving them the authority, or by taking the responsibility away.
Step 3: Refactor the Role
Split the role. If the tech lead is doing management work, make them a manager. If they’re doing architecture work, make them an architect. If they’re doing both, you have two roles crammed into one person, and that person is going to quit. The refactor is painful, but it’s less painful than losing your best engineer.
Step 4: Watch the Signals
After you refactor, watch the operational signals. Did deployment frequency go up? Did code review latency go down? Did incident response get faster? If yes, you fixed the system. If no, you moved the bottleneck somewhere else. Find it and fix it again.
The Cost of Ignoring the Pattern
If you ignore the phantom manager pattern, here’s what happens. Your tech lead burns out. They start looking for a new job. They find one. They leave. You lose the person who knew the most about the codebase, the team, and the architecture. The team loses its de facto leader. The codebase loses its institutional memory. Deployment frequency drops further. Code review latency spikes further. Incident response gets worse. And then you promote the next senior engineer into the same broken role, and the cycle repeats.
This is the tech lead churn loop. It’s one of the most expensive patterns in software engineering, and it’s entirely preventable. The fix isn’t to hire better tech leads. The fix is to design a better role.
What a Healthy Tech Lead Role Looks Like
A healthy tech lead role has three properties:
- Bounded scope. The tech lead owns a specific area — a service, a module, a team — and they’re the final decision-maker for that area. They’re not responsible for everything. They’re responsible for one thing, and they do it well.
- Real authority. The tech lead can make decisions that stick. They can say no to scope. They can enforce coding standards. They can allocate technical resources. They don’t need to ask permission for every small thing.
- Protected time. The tech lead has at least one full day a week with no meetings, no interruptions, and no firefighting. They use that time to write code, review pull requests, and think about the architecture. If they don’t have that time, they’re not a tech lead. They’re a meeting attendee with a fancy title.
If your tech lead role doesn’t have these three properties, you don’t have a tech lead. You have a phantom manager. And phantom managers don’t scale.
FAQ
What is the difference between a tech lead and a manager?
A tech lead is responsible for technical decisions — architecture, code quality, technical direction. A manager is responsible for people decisions — hiring, firing, performance reviews, career growth. The problem is when a tech lead is expected to do both without the title or authority of a manager. That’s the phantom manager pattern.
How do I know if I am a phantom manager?
Ask yourself three questions: Can I make a technical decision and have it stick? Do I have at least one full day a week to write code? Do I have a manager who handles the people stuff? If the answer to any of these is no, you’re probably a phantom manager. The operational signals are also telling: if code review latency is high, if deployment frequency is dropping, if incident response is chaotic, you’re likely the bottleneck.
What should I do if I am a tech lead stuck in this pattern?
First, document the problem. Write down what you’re responsible for, what authority you actually have, and where the gaps are. Then take that document to your manager and ask for a specific change: either give you the authority, reduce the responsibility, or change the title. If your manager won’t make a change, start looking for a new role. Life is too short to be a bottleneck.
How can a manager fix the phantom manager pattern on their team?
Measure the bottleneck first. Look at code review latency, meeting load, and decision escalation. Then identify the missing authority. Then refactor the role — split it into a technical track and a management track if necessary. Then watch the operational signals to see if the fix worked. The key is to treat it as a systems problem, not a people problem.
Next Steps for This Blog
This article is part of a series on operational signals that reveal broken team dynamics. The next piece will look at code review latency as a cultural diagnostic — what your pull request queue says about your team’s trust, autonomy, and decision-making patterns. If you have a war story about a phantom manager, a tech lead churn loop, or a role refactor that actually worked, send it over. I read everything, and I’ll quote the good ones.
