The Tech Lead is a Senior Developer who made the mistake of being good at explaining things.
This is how it happens: a senior developer, during a planning session, draws an architecture diagram that is clear, simple, and correct. The Product Manager understands it. The Engineering Manager understands it. The junior developers understand it. Someone says: “You should lead this.” The senior developer, who intended to draw one diagram and then go back to writing code, has just become a Tech Lead.
The transition is never formal. There is no ceremony. There is no training. There is a Slack message from the engineering manager that says “I’d like you to be the tech lead for this project” and a calendar that, within two weeks, will have no empty slots between 9 AM and 5 PM.
The Tech Lead is the most structurally confused role in software engineering. It is neither management nor individual contribution. It is both. It is the quantum superposition of “I make technical decisions” and “I also write the code,” which collapses into “I make technical decisions during the day and write code at night” the moment anyone observes the calendar.
The Split
Every Tech Lead’s week is divided into two halves that the calendar refuses to acknowledge:
The Visible Half (9 AM – 5 PM):
- Sprint planning
- Backlog refinement
- Architecture reviews
- 1:1s with team members
- Code reviews
- “Quick question” conversations (never quick, always questions)
- Cross-team alignment meetings
- Incident response coordination
- The meeting about reducing meetings
The Invisible Half (7 AM – 9 AM, 5 PM – 11 PM):
- Actually writing code
The Tech Lead’s git log tells the story the calendar won’t. Commits at 7:14 AM. Commits at 10:47 PM. A commit at 6:30 AM on Saturday with the message “fix the thing I said I’d fix on Tuesday.” The code is written in the margins of the day, in the spaces the meetings leave behind, in the hours that are technically personal time but are functionally the only uninterrupted hours available.
This is not sustainable. Every Tech Lead knows this. Every Tech Lead does it anyway, because the alternative is to stop writing code, and the moment a Tech Lead stops writing code they become an Engineering Manager — which is a valid career path but not the one they chose.
The Translation Layer
The Tech Lead’s primary function is translation. Not between languages — between people.
The Product Manager speaks in user stories, customer impact, and quarterly OKRs. The developers speak in APIs, data models, and technical constraints. The Engineering Manager speaks in headcount, velocity, and delivery dates. These are three different languages describing the same reality, and none of them is wrong, and none of them is complete.
The Tech Lead translates:
- PM → Developers: “The PM wants real-time notifications” becomes “we need a WebSocket connection with reconnection logic, a message queue for reliability, and about three weeks.”
- Developers → PM: “The database schema doesn’t support this” becomes “we can do it, but we need to migrate the user table first, which is a prerequisite that should go in the next sprint.”
- Everyone → Manager: “We’re on track but the auth integration is riskier than we thought” becomes exactly that sentence, because the Tech Lead has learned that translating technical risk into management language means using the same words but saying them with more eye contact.
The translation is lossy. It is always lossy. The PM’s vision loses nuance when compressed into tickets. The developer’s concerns lose urgency when compressed into risk assessments. The Tech Lead lives in the loss — in the gap between what the PM meant and what the developer understood, between what the developer flagged and what the manager heard.
The Architecture Decision
The Tech Lead makes architecture decisions. This sounds important. It is important. It is also the source of the Tech Lead’s deepest anxiety, because architecture decisions are the decisions that are hardest to reverse and the Tech Lead is the person who will have to live with them.
A junior developer makes a bad decision and it affects one function. A senior developer makes a bad decision and it affects one service. A Tech Lead makes a bad decision and it affects the team for the next two years.
The Tech Lead’s architecture decisions follow a pattern:
- Day 1: The Tech Lead considers three approaches. Approach A is simple but limited. Approach B is flexible but complex. Approach C is the one the Squirrel proposed, involving an event-sourced CQRS pipeline with a custom DSL.
- Day 2: The Tech Lead eliminates Approach C. The Squirrel is disappointed.
- Day 3: The Tech Lead chooses Approach A, because Approach A ships this quarter and Approach B ships next quarter, and the Tech Lead has learned that the flexible approach is only valuable if the flexibility is actually needed, which it usually isn’t.
- Month 6: Approach A turns out to be insufficient. The Tech Lead adds one extension point — the specific extension point that was needed, not the seven that Approach B would have provided.
- Month 12: The system works. It is not elegant. It is adequate. Adequacy, shipped, is worth more than elegance, planned.
The best Tech Leads make decisions that are just barely sufficient. Not over-engineered, not under-engineered — sufficient. This requires knowing the difference, which requires having over-engineered and under-engineered in previous roles, which is why the Tech Lead is always a Senior Developer first.
“The Tech Lead chose the boring option again. The system works again. These two facts are related.”
— The Lizard, on architecture decisions
The Team
The Tech Lead is responsible for the team’s technical output without having any formal authority over the team. This is the role’s central paradox and its central value.
A manager can assign work. A Tech Lead can only suggest work. A manager can mandate a technical standard. A Tech Lead can only advocate for a technical standard. A manager can put someone on a PIP. A Tech Lead can only have a conversation about code quality and hope that the conversation lands.
This constraint — influence without authority — forces the Tech Lead to be right more often than they are wrong, because influence evaporates the moment the team stops trusting the Tech Lead’s judgment. A manager who makes a bad call retains their authority. A Tech Lead who makes a bad call loses the team’s confidence, and without confidence, the Tech Lead is just a senior developer with more meetings.
The best Tech Leads make the team better without the team noticing. The code reviews improve quality. The architecture decisions reduce complexity. The technical guidance prevents dead ends. Six months later, the team is shipping faster, the codebase is cleaner, and nobody can point to the specific moment it improved, because the improvement was distributed across a hundred small decisions made by someone who was paying attention.
The Tech Lead’s job is to make the team not need the Tech Lead. This is the definition of success, and it is also the reason the role is so rarely celebrated — by the time the Tech Lead has succeeded, the success looks like it happened on its own.
The Escape Velocity Problem
Every Tech Lead faces a gravitational pull toward management. The pull is not malicious. It is structural.
The engineering manager notices that the Tech Lead is good with people. The Tech Lead’s 1:1s are productive. The Tech Lead navigates conflict well. The Tech Lead translates between PM and developers with ease. “Have you considered management?” the engineering manager asks, the way a car salesperson asks if you’ve considered the leather interior — casually, as if it’s not the whole point.
Some Tech Leads accept. They become Engineering Managers. Their calendars, already full, achieve 100% meeting density. Their git logs go silent. They discover that management is a different skill set, and that being good at technical leadership does not automatically make you good at people management, which is why the Peter Principle exists.
Some Tech Leads refuse. They oscillate — Tech Lead for a project, back to Senior Developer for the next, Tech Lead again when the team needs one. Their LinkedIn titles update every six months. They are not indecisive. They are testing the boundary between “I want to lead” and “I want to code,” and the boundary moves with every project.
The rarest Tech Leads find the equilibrium: they lead without managing, decide without mandating, guide without controlling. They write code at 7 AM and review code at 3 PM and draw architecture diagrams at noon and the team ships on time and nobody asks the Tech Lead to become a manager because the Tech Lead has made the role look like what it is — the most productive seat in the room, occupied by someone who still ships.
Measured Characteristics
- Time writing code (calendar says): 40%
- Time writing code (actually): 15-20% (evenings and early mornings)
- Time in meetings: 50-60%
- Time translating between PM and developers: the rest
- Git commits before 9 AM: suspicious number
- Git commits after 9 PM: concerning number
- Architecture decisions per quarter: 3-5 (each lasting 1-2 years)
- Architecture decisions that chose the boring option: ~80%
- Architecture decisions the Squirrel agreed with: ~20%
- “Quick questions” per day: 8-15 (average duration: 12 minutes, never quick)
- Slack messages reading “can you take a look at this?”: constant
- Formal authority over the team: 0
- Actual influence over the team: everything
- Times asked “have you considered management?”: 2-3 per year
- Times the answer was “no”: depends on the Tech Lead
- The calendar’s opinion: there is no time to write code
- The git log’s opinion: code was written anyway
