From Senior Engineer to Tech Lead, The Identity Shift Nobody Warns You About

TL;DR — Tech lead isn’t a promotion, it’s a role change with a different scoring system / your value moves from code shipped to decisions enabled / the identity loss is real, plan for it.

I got my first real tech lead title about six years ago. I remember the week vividly because I shipped almost no code, attended what felt like every meeting on the calendar, and ended Friday convinced I’d had the least productive week of my career. My manager at the time told me, gently, that it was actually one of my best. That conversation rewired how I thought about output, and a version of it has played out in every tech lead I’ve coached since.

This piece isn’t a how-to. There are plenty of those, and most of them are fine. What I want to write about instead is the part that the books and courses tend to skip: the identity shift. The quiet grief of no longer being the person who solves the gnarly bug at 11 PM. The disorientation of being good at something for a decade and then waking up bad at the new version of your job. If you’re reading this and you’ve just stepped into a lead role — or you’re about to — I hope some of it lands.

This is the first post in a December run on leadership, discovery, and team design, so I’ll keep this one personal and use the rest of the month to get more tactical.

The Scoring System Changes, But Nobody Tells You

Senior engineers get rewarded for output you can point at. PRs merged, incidents resolved, systems designed, services migrated. The feedback loop is tight — you write code, code runs, things work or they don’t. You know within a day, sometimes within an hour, whether you did good work.

Tech leads get rewarded for second-order effects. Did the team make a good call on the database choice? Did the junior engineer who joined three months ago grow into someone who can drive a project? Did the product manager and the staff engineer leave the planning meeting with the same understanding of scope? These outcomes show up weeks or quarters later, and most of them are not legibly attributable to you. The dopamine cycle that powered you for years just stops working.

The first thing to accept is that this isn’t temporary. There’s no productivity hack that gets you back to the old feedback loop. You have to build a new internal scoreboard, or you’ll burn out chasing the old one by sneaking code reviews and side-projects into your nights and weekends. I did this for about four months and the only thing it produced was resentment.

What You’re Actually Optimizing For Now

A useful reframe: as an IC, you optimized for the quality of the artifact you produced. As a lead, you optimize for the quality of the decisions your team makes — including the decisions made when you’re not in the room. That second part is where the leverage lives.

Three areas I’ve found worth investing in early:

Context distribution. Most bad team decisions come from uneven information, not bad judgment. The lead’s job is to make sure the right context reaches the right people at the right time — the upcoming compliance deadline that engineering doesn’t know about, the architectural constraint that product hasn’t internalized, the half-finished migration that makes “just add a column” actually mean three weeks of work.

Default-setting. What does “done” mean on this team? How do we write RFCs? When do we page someone? What’s the bar for code review? You don’t set these by decree, but you do set them by what you tolerate and what you push back on. The defaults you establish in the first ninety days will outlive you on the team.

Decision quality vs. decision speed. Most teams over-deliberate on reversible decisions and under-deliberate on irreversible ones. Part of the lead’s job is to name which is which. Jeff Bezos’s “two-way door” framing is overused but the underlying point holds. If something is reversible, ship it and learn. If something will lock you in for years, slow down and write the doc.

The Code Question

Here’s the question I get most often from new leads: should I still be coding?

My honest answer is “yes, but less than you think, and not on the critical path.” On the critical path, you become a single point of failure — the team can’t ship without you, you can’t go to your other meetings, and the work that only you can do (the leadership work) gets squeezed out. Off the critical path, coding keeps you grounded, keeps your technical instincts sharp, and gives you firsthand feel for the developer experience your team lives in every day.

Things I still try to do as a lead:

• Pick up one or two well-scoped tickets per sprint, ideally in unfamiliar parts of the codebase, so I’m forced to use the same docs and dev setup as everyone else
• Prototype during the design phase, not the implementation phase — a 200-line spike beats a 2,000-word RFC for certain kinds of decisions
• Pair with juniors and mids regularly, both to teach and to learn what’s painful about the codebase right now
• Stay out of the hot path during incidents unless I genuinely have unique context

Things I stopped doing:

• Owning core services where my unavailability becomes a delivery risk
• Volunteering for the most interesting ticket (it’s not yours anymore — that’s how you grow people)
• Reviewing every PR; instead, set the review norms and trust the team

The framing I keep coming back to is from Camille Fournier’s The Manager’s Path — your job is to be a “force multiplier,” which is a buzzword until the day you watch your team ship something good without you in the room and realize that’s the whole point.

The Identity Grief Is Real

Nobody warns you about this part. You spent a decade or more becoming good at something. You have muscle memory for it. You have stories. You have an internal sense of yourself as “the person who can.” And then the job changes, and the things you were best at are no longer the things you’re paid to do.

For me, this showed up as a low-grade irritability that I couldn’t trace for about six months. I’d come home tired but with nothing to point at. I’d open a side project on weekends and feel guilty for not doing it during work. I’d see a junior engineer struggle with a problem I knew I could solve in twenty minutes, and I’d have to sit with the discomfort of letting them work it out.

What helped, eventually:

• Naming it. The grief over the old role is not the same as regret about the new one. Both can be true at the same time.
• Finding a peer group of other leads. Not your manager, not your reports. People at your level going through the same transition. Will Larson’s Staff Engineer book helped here even though it’s pitched at a different level — the stories are recognizable.
• Picking a deliberate technical practice to maintain outside the day job. For me it’s reading source code of tools I use, weekly. Cheap, keeps me sharp, doesn’t pretend to be production work.
• Letting the calendar reflect the role. If the role is mostly people and decisions, the calendar will be mostly people and decisions. Trying to keep an IC calendar in a lead role is a recipe for resentment.

Common Pitfalls

The traps I’ve seen most often, in roughly the order they tend to appear:

The hero anti-pattern. You jump in to solve every hard problem because that’s what you’re good at and it feels productive. Three months in, your team is more dependent on you, not less, and you’re the bottleneck on every project.

Premature process. New leads often try to fix team dysfunction by introducing process — standups, retros, planning meetings, RFC templates. Some of this is good. Most of it is theater that lets you feel like you’re leading without actually leading. Diagnose first.

Avoiding the people work. Performance conversations, expectation-setting, giving direct feedback to someone you used to peer with — these are the trickiest parts of the job and the easiest to put off. They don’t get easier with time. The longer you wait, the worse the conversation gets.

Becoming a meeting recipient. Your calendar will fill up with meetings other people scheduled. If you don’t proactively block time for thinking, writing, and one-on-ones, you’ll spend the role being reactive. Treat your calendar as the most important codebase you own.

Confusing being liked with being respected. You don’t need everyone to like you. You do need them to trust that you’ll be straight with them, advocate for the team, and make calls when calls need to be made. The first months are when you build or fail to build that trust.

Wrapping Up

The transition from senior engineer to tech lead is, in the end, mostly an internal transition. The external part — new meetings, new responsibilities, new scope — is the easier half. The internal part is the identity shift, and that one takes longer than anyone tells you. Give yourself a year before you decide whether you’re any good at this.

Next post this week, I’m getting into consultative discovery — specifically, how to run the first conversation with a new client or stakeholder without falling into the trap of taking their stated requirements at face value.