What Actually Changes When You Become a Tech Lead
I got promoted to tech lead on a Tuesday. By Thursday I’d convinced myself nothing had really changed: same standup, same sprint board, same Slack channels. I just had a new title next to my name and, apparently, an extra recurring meeting.
It took about six weeks for me to realize how wrong that was. Not because the org chart moved. Because almost everything about how I spent a day, what counted as a good week, and what I was actually accountable for had shifted underneath me while I was still measuring myself by the old rubric.
This is the post I wish someone had handed me that first week: not a list of new responsibilities, but a map of what genuinely changes when you become a tech lead versus what people (including you) assume changes but doesn’t.
What people assume changes (but mostly doesn’t)
Before I get to the real shifts, it’s worth clearing out the assumptions, because a lot of the early disorientation comes from bracing for changes that never actually arrive.
You don’t stop writing code. This is the one every new tech lead worries about out loud, and it’s the wrong worry. You’ll write less code, and the code you write will skew toward the gnarly, ambiguous, or foundational stuff nobody else has context for, but “tech lead” isn’t a synonym for “manager who used to code.” If you’ve fully stopped touching the codebase, something else has gone sideways, and it’s usually scope creep into people-management you didn’t ask for (more on that below). I wrote a whole separate post about the actual mechanics of learning to let go of that habit, if this is the part you’re stuck on: Why I Stopped Coding Everything Myself as a Tech Lead.
You don’t automatically get more authority. This one surprises people the most. The title suggests you can now make calls unilaterally on architecture, priorities, and who works on what, and in practice you can’t, not without spending trust you haven’t built yet. Authority as a tech lead is almost entirely earned in real time through judgment demonstrated in front of the team, not conferred by the promotion. I’ve watched new leads burn their first few months trying to use authority they technically had on paper and didn’t yet have in practice.
Your technical judgment doesn’t need to improve overnight. You were promoted because your judgment was already good enough. That’s usually the whole basis for the promotion. What changes is the radius of decisions your judgment gets applied to, not the judgment itself. Don’t confuse “I now need to think about more things” with “I now need to think better than I did last month.”
You’re not suddenly the smartest person in the room, and nobody expects you to be. New leads often overcorrect into having an opinion on everything, because they think that’s the job. It isn’t. Knowing when to say “I don’t know, let’s find out” is a bigger credibility builder than having an answer ready for every question in a design review.
What actually changes
Here’s what genuinely shifted for me, roughly in the order I noticed it.
The unit of your output stops being code
As an IC, “what did you do this week” has a clean answer: here’s the PR, here’s
the feature, here’s the bug I fixed. As a tech lead, your best weeks often
produce nothing you can point to in a diff. You unblocked three people. You
caught a design flaw in a review before it got built. You had a hard
conversation that kept a project from quietly drifting off course. None of
that shows up in git log.
This is disorienting because it removes the immediate feedback loop you’ve relied on your whole career. Code either compiles or it doesn’t; tests pass or they don’t. Leadership output doesn’t resolve that cleanly, and you have to get comfortable evaluating your own week on a different axis: did the team move faster or slower because I existed this week? There’s no crisp green-checkmark confirmation for that one.
Your time horizon stretches, in both directions
As an IC, your planning horizon is usually the current sprint, maybe the current quarter if you’re senior. As a tech lead, you’re holding two horizons at once: the next two weeks of execution detail, and the next two quarters of “where is this system going to need to bend, and are we building ourselves into a corner right now to hit a deadline.” Nobody hands you a document that tells you to think this way. You’re the only one on the team positioned to see both ends at once, so if you don’t notice, nobody does.
You become the person who has to know what you don’t know
As an IC, it’s fine (expected, even) to stay deep in your lane and let someone else worry about the parts of the system you don’t touch. As a tech lead, “I don’t really know what’s happening in that part of the codebase” is a liability, because you’re often the only person whose job includes seeing across the whole thing. You don’t need to be the expert in every corner. You do need to know enough to ask the right question when something looks off, and to know who to go find when it is.
Your calendar becomes a technical decision, not an inconvenience
This was the one that actually broke my old workflow. As an IC, meetings are interruptions to real work. As a tech lead, a meaningful chunk of your calendar (1:1s, design reviews, cross-team syncs) is the work, because that’s where you catch problems early enough to matter. I spent my first couple of months resentful of my calendar before I realized I was still optimizing for “protect maker time” when my job had quietly become “spend time where my presence prevents the most expensive future mistakes.” Those aren’t the same optimization function, and using the old one made me worse at the new job.
Mistakes get more expensive and less visible
An IC’s mistake is usually a bug: visible, attributable, fixable. A tech lead’s mistake is more often a bad call that looks fine for months: the wrong abstraction, the team structured around the wrong assumption, the person who should have gotten more room and instead faded out without saying anything. These mistakes don’t show up in a stack trace. They show up as slower velocity six months later that nobody can quite trace back to a decision. Part of the job now is building the discipline to revisit your own past calls honestly, since nothing external is going to flag them for you.
You start managing energy, not just tasks
Task management was always part of the job. What’s new is that you’re now responsible for noticing when someone on the team is quietly burning out, or checked out, or stuck on something they’re too proud to raise, because if you don’t notice, often nobody else with the standing to do something about it will. This is the part of the role that looks the least like engineering and is, for a lot of new leads, the part they’re the least prepared for.
What this actually means day to day
If I had to compress all of this into one shift: as an IC, your job is to produce good outcomes yourself. As a tech lead, your job is to create the conditions where good outcomes happen even when you’re not the one producing them. That’s a different skill; it doesn’t correlate cleanly with how good an engineer you were, and nobody tells you that going in. You find out by watching what breaks on the weeks you don’t create them.
The good news is that none of this requires becoming a different person. It requires noticing which of your old instincts still serve you and which ones you need to consciously override, because they were tuned for a job you no longer have.
If you’re looking for the practical, week-by-week version of everything above (what to actually do with it in your first three months on the job), that’s The First 90 Days as a New Tech Lead. This post is the map; that one’s the field manual.
And if part of what you’re weighing is whether this move is actually worth it, not just what it changes day to day, the Comp Delta Calculator is a free way to see what a tech-lead-level promotion is worth, compounded over the next five years, using your own numbers.