From Senior Engineer to Tech Lead: What Actually Changes

The email went out on a Friday afternoon: I was now the tech lead for our platform team. I remember closing my laptop that day feeling like something big had just happened. Monday morning, I opened the same laptop, looked at the same backlog, and had absolutely no idea what I was supposed to do differently.

Nineteen years into this career, across a handful of companies and a lot of team shapes, I've now made that jump myself and watched a dozen other engineers make it. The pattern is remarkably consistent: the title changes overnight, but the job takes months to actually change — and if you don't notice it needs to, you end up doing your old job with a new title stapled on top, which helps no one.

What Doesn't Change

It's worth naming this first, because a lot of "leadership advice" implies you should suddenly stop being an engineer. You shouldn't, and you can't — not if you want to be any good at this.

You still need deep technical judgment. Arguably you need it more, because now your calls affect five or ten people's work instead of just your own. You still need to understand the codebase, not at the level of "I could find my way around it" but at the level of "I can tell when a proposed approach is going to cause pain in eight months." That understanding doesn't come from standups and status reports — it comes from staying close enough to the code that you can still read a diff and have an opinion worth listening to.

I've seen tech leads drift away from the codebase within a few months of the promotion, and it's almost always a mistake. Not because they need to be the best coder on the team — they don't, and pretending otherwise creates its own problems — but because losing the thread of what the codebase actually looks like erodes the exact judgment that got them the role in the first place.

What Actually Changes

Your time allocation flips

As a senior engineer, a good week meant I closed out a hard ticket, reviewed a couple of PRs, and maybe unblocked a teammate once or twice. As a tech lead, a good week might mean I didn't write a single line of production code — but three people on my team shipped work they'd have been stuck on without a conversation I had with them on Tuesday. That trade is uncomfortable at first. It stops being uncomfortable once you stop measuring your day by lines changed.

The success metric moves

This is the single biggest mental shift, and it's the one that takes longest to actually internalize rather than just intellectually agree with. As a senior engineer, "what did I ship this sprint" is a perfectly good question to ask yourself. As a tech lead, that question stops being useful. The question becomes "what did the team ship, and were the right things blocked or unblocked at the right time."

The uncomfortable part is that your personal output can go down while you're doing a genuinely better job than before. That's a hard trade to make peace with if you've spent a decade being rewarded for individual throughput.

Decisions now have a people dimension

As a senior engineer, a technical decision is mostly a technical decision: which library, which pattern, which trade-off between performance and simplicity. As a tech lead, the same decision now has a sequencing question attached — who's blocked on this, who should do it, does it fit the skill level of the person likely to pick it up, and what happens to morale if two people want the same piece of work. You're not just deciding what's technically correct anymore; you're deciding what's correct given the five humans who have to execute it.

The Habits That Made the Transition Work

Real 1:1s, with an actual agenda

I used to think 1:1s were a formality — a status check I could get from a Slack message. They're not. A good 1:1 is where you find out someone's been quietly stuck for three days, or that they're bored and about to start job hunting, or that they disagree with a technical direction but didn't want to raise it in front of the group. None of that surfaces in standup. I keep a running doc per person with open threads from the last conversation, so the 1:1 starts with "last time you mentioned X, how did that go" instead of an awkward silence.

Write decisions down

As an individual contributor, I could hold most context in my head. As a tech lead, if a decision only exists in a conversation two people had, it effectively didn't happen — it won't survive the next person joining the team, the next re-org, or even just three weeks passing. I started writing short decision records for anything that would be expensive to re-litigate: why we picked an approach, what we considered instead, and what would make us revisit it. It's saved us from the same architecture debate resurfacing from scratch more times than I can count.

Absorb interruptions so the team doesn't have to

One of the most concrete things a tech lead can do is stand between the team and the noise — the urgent Slack pings, the "can someone jump on a call" requests, the cross-team asks that arrive with no warning. Every one of those you take yourself is one less context-switch for someone who's trying to hold a hard problem in their head. This is invisible work. Nobody thanks you for the interruption that didn't happen. Do it anyway.

Delegate ownership, not just tasks

The lazy version of delegation is handing off the boring tickets while keeping the interesting architecture work for yourself. That's not delegation, that's just task distribution, and your best people will notice and resent it. Real delegation means giving away a piece of ownership you'd actually enjoy keeping — letting someone else own the design of a system, make the calls, and get the credit, even when you're confident you'd do it faster yourself. It is slower in the short term. It's the only way the team's capability grows instead of just your own.

Keep shipping something, on purpose

I make a point of taking on one small, well-scoped piece of hands-on work every few weeks — not because the team needs me to, but because it keeps my technical opinions grounded in what the codebase currently feels like to work in, not what it felt like a year ago. It also means code review conversations come from someone who's recently felt the same friction, not someone lecturing from a distance.

Traps I Watched Myself (and Others) Fall Into

• Becoming the bottleneck: insisting on reviewing every PR yourself feels responsible; in practice it just means everyone waits on you, and nobody else builds the judgment to review well.
• Avoiding the hard conversation: when someone's underperforming, it is always easier to quietly route work around them than to name the problem directly. It's also unfair to everyone else absorbing the slack.
• Solving the technical problem and ignoring the people problem: a recurring incident is often a symptom of an unclear owner, not a missing retry policy. Fix the retry policy and the ownership gap either way, or it'll surface again in a different shape.
• Optimizing for being liked over being useful: a tech lead who never pushes back on a bad plan to avoid conflict isn't being kind, they're outsourcing the consequences to the team six months later.

The First 90 Days, Concretely

Closing Thought

I'd love to tell you this becomes a solved problem after the first year. It doesn't. Every new team, every new mix of personalities, every new stage of company growth resets part of the equation. What changes is that you get faster at noticing when you've slipped back into old habits — reviewing everything yourself, avoiding a hard conversation, measuring your week by what you personally shipped. The job isn't to arrive at a fixed way of leading. It's to keep noticing, and keep adjusting, faster each time.