Transitioning to Technical Leadership, A Senior Engineer's Playbook

TL;DR — The transition from senior IC to technical leader is an identity shift, not a promotion. Your job is no longer to be the best engineer in the room. Your job is to make the room better. Three things matter most in the first ninety days: deliberate ramp, ruthless delegation, and a written operating model so people know how to work with you.

I’ve made this transition twice and watched a dozen friends do it. The pattern is consistent enough that I can almost predict the month-by-month failure modes. Month one, you try to do both jobs and burn out. Month two, you over-correct into pure coordination and lose the technical credibility that got you the role. Month three, you start to find your shape, but only if you’ve been honest with yourself about what’s working.

This isn’t a post about whether you should move into leadership. That’s a personal call and I won’t pretend the IC path is somehow lesser. This is a post for engineers who have already decided to take the step, or who are six months in and wondering why it feels harder than they expected. I’m going to give you the playbook I wish someone had handed me, with the frameworks I actually use rather than the platitudes you’ve already read on LinkedIn.

Everything below assumes you’re moving into a tech lead, staff engineer, or first-line engineering manager role at a company between fifty and a thousand engineers. The dynamics shift at the extremes, but the middle is where most of these transitions happen.

What actually changes on day one

The job change is real even when the title change feels symbolic. As a senior IC, you were measured on what you shipped. As a leader, you’re measured on what the team shipped, on the decisions that didn’t blow up, and on the people who grew under you. The output is the same on paper. The leverage is completely different.

Three things flip immediately. First, your calendar becomes the most contested resource you own. Meetings expand to fill it, and if you don’t actively shape it, the calendar shapes you. Second, your influence stops scaling with your typing speed and starts scaling with your clarity of thought. The artifact that matters most is no longer a pull request, it’s a written argument that ten people can read async. Third, every conversation becomes a leadership conversation whether you want it to or not. The throwaway comment you made in standup is now policy by Friday.

This last one is the hardest to internalize. Senior ICs get to think out loud. Leaders don’t, at least not in public forums. You can still be exploratory in one-on-ones, in a small group of trusted peers, or in writing where you can revise. But the casual “I think we should rewrite this in Rust” you used to drop in standup will now show up six weeks later as a roadmap item nobody actually wanted.

A ninety-day ramp that doesn’t waste anyone’s time

Your first ninety days set the tone for the next two years. I’m not exaggerating. The patterns you establish in the ramp, the questions you ask, the things you choose to fix first, become the team’s read on what you value. Spend this time deliberately.

Days 1 to 14, listen with structure

Resist the urge to ship anything in the first two weeks. I know. Your fingers will itch. Do not. Instead, run a listening tour with a written agenda. Talk to every direct report, every peer lead, your manager, and at least three engineers outside your immediate team who interact with your code.

Use the same five questions in every conversation so you can compare answers:

1. What’s the thing this team does best, and how do you know?
2. What’s the thing we’re worst at, and what would you change tomorrow if you could?
3. Who on the team is underrated, and why?
4. What’s a decision you made recently that you’d undo if you could?
5. What do you wish your previous lead had done differently?

Take notes. Keep them in a private document. Patterns will emerge by conversation seven or eight, and by conversation fifteen you’ll have a map of the team’s real shape, not the org chart shape.

Days 15 to 45, write your operating model

By week three, write a one-page document called something like “How I Work” and share it with the team. Not a manifesto. A practical reference. Mine includes:

• When I’m reachable async vs. synchronous
• How I want decisions surfaced to me (write it down, propose a default, then ping)
• What I will always read same-day (incident reports, ADRs, retro notes)
• What I will probably not read for a week (long Slack threads, Jira tickets I’m not tagged on)
• How I give feedback (direct, in private, with a specific example)
• What I expect in my one-on-ones

This document does more for your transition than any all-hands. It removes ambiguity. People stop guessing what you want, which means they stop wasting energy managing up.

Days 46 to 90, ship one visible thing

By day sixty, you should have committed to one change that’s visible across the team and ideally beyond. Not a rewrite. Not a reorg. Something small and concrete that demonstrates judgment. Examples I’ve seen work: introducing a lightweight ADR process, killing a stale on-call rotation, rebuilding the team’s deploy pipeline, or writing the first credible team strategy doc the org has seen in a year.

The point isn’t the size of the change. The point is that you picked one battle, fought it well, and finished. New leaders who try to fix five things in their first quarter usually finish zero.

Delegation is not handing off tickets

The single biggest mistake new leads make is treating delegation as a queue-management problem. You take the ticket from the backlog, assign it to someone, ask for an ETA, and move on. That’s not delegation, that’s dispatch. And it’s why you’ll still be working sixty hours a week in month four.

Real delegation has four levels, borrowed roughly from the Vroom-Yetton decision model but simplified for engineering work:

The mistake is staying at level 1 or 2 with people who deserve level 3 or 4. You’ll exhaust yourself, and they’ll either leave or check out. The opposite mistake (handing a junior engineer level 4 work on day one) ends in a quiet failure that erodes everyone’s confidence.

I review my delegation level for every direct report once a quarter. It changes more than you’d think.

The technical credibility problem

You will lose technical credibility if you stop coding entirely. You will also lose leadership credibility if you keep coding the way you did as a senior IC. Both are true. The resolution is to code differently, not to code more or less.

What this looks like in practice: I still write code, but I pick work that nobody else can or should do. Spikes on uncertain technical questions. Prototypes for risky designs before the team commits. Internal tooling that unblocks five people. I do not pick up feature work that a senior engineer on the team could do well, because if I do, I’ve taken a growth opportunity from them and added a bottleneck to the team.

The bar is simple: would shipping this myself make the team stronger or weaker in six months? If weaker, hand it off. The Staff Engineer’s Path by Tanya Reilly is the best treatment of this I’ve read, and worth re-reading every twelve months.

Building your written voice

If you’re not writing more than you used to, you’re not actually leading. Writing is how leadership scales past the people in your immediate orbit. The artifacts that matter most:

• Team strategy doc. One page. What the team is trying to achieve this quarter, why, and what we’re explicitly not doing. Updated every quarter.
• Architecture decision records. I cover this in depth in Writing ADRs That Actually Inform Decisions.
• Incident retrospectives. Not the blameless template box-checking. Real analysis that someone outside the team can learn from.
• Weekly written update. Five bullets, sent every Friday. What shipped, what’s blocked, what I’m worried about, what I’m proud of, what I need from peers.

The weekly update is the highest-leverage artifact of the four, and the one most new leads skip. It compounds. Six months in, your manager has a written record of your judgment over twenty-five weeks. That record is what gets you promoted, gets your team budget, and gets you trusted with bigger problems.

Harvard Business Review has a useful piece on this called The Leader as Communicator that’s worth reading even though it’s older. The point holds: leadership compounds through repeated, consistent communication.

Common Pitfalls

I’ve made every one of these. So has every lead I respect.

• The hero relapse. A bug shows up at 11pm and you fix it yourself instead of paging the on-call. Feels heroic, signals to the team that on-call doesn’t matter and that you don’t trust them.
• The all-things-to-all-people trap. Saying yes to every cross-team request because you want to be helpful. Your team’s roadmap erodes by inches. You won’t notice until standup feels weird.
• The shadow IC. You’re technically a lead but you still own three critical services personally. The team can’t ship without you. You’re the bottleneck and you don’t see it because you’re too busy.
• Performative busyness. Calendar packed wall to wall, but ask yourself which of those meetings would the team notice if you skipped. If the answer is fewer than half, you have a calendar hygiene problem.
• Avoiding hard conversations. The underperformer on your team is not going to fix themselves. The peer lead who keeps blocking your work isn’t going to wake up Monday more cooperative. Schedule the conversation. Today.

When This Goes Wrong

Some failure modes are predictable enough that I want to name them, because spotting them early is the difference between a recoverable quarter and a year of damage.

You can’t stop coding. Three months in, you’re still writing more code than your seniors. Your one-on-ones are perfunctory. Your team’s roadmap is fuzzy. Diagnosis: you took the title but not the job. Fix: pair with another lead you respect and have them audit your calendar and your last ten Slack messages. The pattern will be obvious.

The team avoids you. People stop bringing you problems. Your one-on-ones are smooth and shallow. You think things are going well. They’re not. Diagnosis: you’ve punished candor somewhere, probably without realizing it. Fix: ask each report directly, “what’s a piece of feedback you’ve been sitting on?” Then shut up and listen. Don’t defend.

Your manager is surprised by things. Your skip-level mentions a problem you didn’t escalate. Your manager hears about a deadline slip from another lead. Diagnosis: you’re managing down but not up. Fix: the weekly written update I mentioned earlier, plus a fifteen-minute managerial one-on-one specifically focused on what they need to know.

Wrapping Up

The transition to technical leadership isn’t a graduation. It’s a re-apprenticeship in a different craft. The skills that made you a great senior engineer (depth, focus, ownership) still matter, but they’re applied through different tools (people, decisions, written argument) and measured on different outcomes (team capability, not personal output).

The leads I respect most have one thing in common: they treat leadership as a skill they’re actively learning, not a status they’ve achieved. They read. They get coached. They write retrospectives on their own decisions. They’re honest about what’s working and what isn’t, with themselves first and their teams second.

If you’re six months in and it still feels hard, that’s not a sign you picked wrong. That’s the job. The leads who say it got easy at month six are usually the ones who quietly stopped trying. Keep going. Write things down. Make the room better.