What Tech Leads Actually Do (It's Not Architecture)

When I first got called "tech lead," I thought the job was architecture. Draw the boxes. Pick Postgres or Kafka. Win the whiteboard debate. Ship the diagram.

Six weeks in I had drawn exactly one box. The rest went to Slack threads about CI flakes, design-doc comments, and a junior who couldn't get staging credentials. The team shipped. I barely merged code.

I felt like I was failing upward.

That's the naive version. The mature version is simpler and less flattering: tech lead is a coordination-and-delivery role with a technical vocabulary. Architecture is on the list. It is not the job.

The Promotion Email Is Not Day One

Google's engineering leadership writing describes something most job descriptions skip: leadership often starts by accident. You get pulled into conflict resolution. You coordinate people who aren't sure who owns the blocker. Someone calls it manageritis. The org chart catches up later.

I've watched this on a payments squad. A senior IC started fielding every design-doc question because she was the one who actually read them. She unblocked staging access because she knew who to ping. She sat in the cross-team API meeting because nobody else would. Three months later, HR sent the promotion email. The job was already running. The title just made the accountability official.

What changes before the title: your calendar stops belonging to you, and people start treating your opinion as a decision even when you haven't decided anything.

What doesn't: you still debug. You still read diffs. You still get paged when the thing breaks at 2 a.m.

What the Title Actually Adds

Josh Hornby's framing is blunt: if you're still writing code 80% of the time, you're a senior developer with meeting invites.

The title adds scope, not speed.

The scope shows up in three places Google lists for tech leads: technology choices, priorities, velocity, and the project-management glue holding them together. Notice what's missing. Nobody gives you headcount. Nobody hands you perf-review forms. You inherit accountability for outcomes you no longer ship alone.

That accountability has a measurable symptom. As an IC, you end the day pointing at a merged PR or a closed ticket. As a lead, you end the day wondering what you actually produced. Google's authors call it counting apples while you're growing bananas. The banana tree is real. It just doesn't diff cleanly.

The coding ratio flips. Hornby puts real time on mentoring, planning, and communicating — not as a side quest, as the role. You will merge less. You will review more. That is not drift. That is the trade.

The first-90-days failure mode is guilt. You measure the new job with the old scoreboard — merged lines, closed tickets — and conclude you are useless. You are not. You are paying Coordination Tax with a currency that does not show up in git log.

Coordination Tax — Not the Architecture Layer

Tanya Reilly named the work everyone mislabels as distraction: glue work. Onboarding juniors. Updating the roadmap. Asking the questions on design documents nobody else asked. Noticing what got dropped. Making sure the team is roughly pointed the same direction.

Stop the glue work and the team slows down. Do it unconsciously and it eats your career. Do it deliberately and it is technical leadership.

Reilly's point is not that glue is beneath you. Undeliberate glue is how senior ICs get pushed into less technical roles without noticing.

I call the accumulated cost the Coordination Tax — the hours you spend making other people's work possible. It is not architecture. It is throughput.

A Worked Sprint

Picture a five-engineer payments team mid-sprint. The tech lead's week:

• Monday: Two hours on an RFC comment thread — not rewriting the design, but asking whether the idempotency key survives retries. Forty-five minutes in a cross-team sync because the ledger service changed an error code without telling anyone.
• Tuesday: Pairing with a mid-level on a flaky integration test. Updating the sprint board because two tickets were the same work wearing different hats.
• Wednesday: The architecture decision. Postgres outbox vs. Kafka event log. Forty-five minutes. Whiteboard. Done.
• Thursday: Escalating a CI permission issue. Writing the rollback steps for a deploy nobody else documented.
• Friday: Reviewing six PRs. One is fine. One needs a rewrite. Three are blocked on a question only the lead can answer.

One box on the whiteboard. Twelve hours of Coordination Tax. The sprint ships because the lead paid the tax — not because the diagram was elegant.

Architecture is on the job description. Coordination Tax is on the calendar.

Competing posts list "set technical direction" as bullet one. Direction is real. It is also maybe ten percent of the week if your team is honest.

What Stays Stubbornly the Same

Three areas still define the job, even when architecture is a minority sport: technical direction, team development, delivery. You do not get to phone those in because you are busy in Slack.

You still review code. You still veto bad ideas — the JWT-in-localStorage proposal, the "we'll fix it in prod" shortcut. You still debug the gnarly production issue when the team is stuck. Technical credibility is the currency. Spend it and you are a coordinator with a title. Keep it and people forgive the meetings.

What stays the same is the engineering judgment. What changes is who executes on it.

Influence Without a Badge

Will Larson's staff-engineering writing applies long before anyone says "Staff" in your level field: technical leadership runs on proxied authority. Your manager loans you organizational power.

You stay effective by staying aligned, trustworthy, and predictable — not by winning every argument on merit alone.

You know the paradox. High expectations, almost no formal authority, nobody reporting to you. The team can ignore your recommendation. You move forward anyway.

Delegation is how you do that without becoming a bottleneck. Google's guidance is explicit: you can finish the fix faster yourself. Delegating grows the team's capability. The slower path is usually the leadership path.

Staying in the room matters too — the roadmap meeting before stories exist, the scope conversation before sprints get carved. Larson's tech-lead archetype is "guide technical vision and execution." Vision without a seat at the planning table is a blog post, not a job.

Create space for others while you are at it. Sponsor the junior who should present the design review. Push the mid-level into the cross-team meeting. Your team should get stronger than your personal output. That is not generosity. It is how you scale past one person's merge rate.

The EM Boundary — Just Enough

Tech lead is not mini engineering manager. You are not running performance reviews. You are not handling compensation. You are not the hiring decider — though you may assess technical fit.

At Google, the split is clean on paper: the engineering manager owns people performance and happiness; the tech lead owns technology efforts — choices, architecture, priorities, velocity. On larger teams, that is a partnership. On small teams, one person wears both hats until something breaks.

Know which side of the line you are on. When a report asks about promotion timing, you listen. You do not own the answer. When delivery is drifting, you name it. That is yours.

Brian Grant's operational list is the unglamorous half competitors skip: code health, on-call rotations, postmortems, release procedures, CI/CD hygiene. Mature orgs have standards. Immature orgs need you to write them. None of that is a system diagram. All of it is tech lead work.

---

The whiteboard is the smallest room you will lead from.