Understand the career landscape

"Where do you see yourself in five years?"

My manager asked me this during a 1-on-1 early in my career, and I froze. Not because I didn't care about my future. Because I genuinely didn't know what the options were. I knew "senior engineer" existed somewhere above me. I knew "engineering manager" and "CTO" were things people became. Beyond that? No clue! Tech lead? Principal engineer? Staff engineer? I'd heard the titles but couldn't have explained what any of them actually did day to day.

I mumbled something about wanting to "have more impact" and we moved on. But the question stuck with me, not because it was deep, but because it exposed a blind spot. I was working hard to grow without being able to describe what growth looked like.

There isn't one ladder. There are several, and they lead to very different places.

The fork you don't see coming

I didn't choose the management fork. It chose me. The people above me saw some glimpses of the soft skills they wanted in a team lead, and one day the role was mine. I'd never managed nor led a team before. I had no framework for what the job actually required. Spoiler: you'll be writing a lot less code, and you'll feel guilty about it.

The journey was difficult in ways I hadn't anticipated. Suddenly I was running 1-on-1s, shielding the team from organizational noise, navigating resource allocation fights, making hiring decisions, and still contributing to the systems. All while feeling like I wasn't doing enough technically. There was just not enough time to do everything.

None of that was part of the skillset I'd spent years building. It was a different job entirely. I sought mentors for help, and devoured a ton of books in a desperate attempt to compensate. I was learning the ropes on the fly.

Camille Fournier's The Manager's Path would have saved me months of figuring things out the hard way. It lays out what each management role actually involves, from tech lead through VP, with enough specificity to understand what you're signing up for before you're already doing it. The shift from writing code to enabling others to write it, the matrix reporting, the cross-functional politics. Understanding that distinction matters whether you end up managing or not, because it changes how you work with the people who do.

Gergely Orosz's The Software Engineer's Guidebook fills in what I didn't realize I was leaving behind: the IC track, mapped with a level of specificity most career advice lacks. What's actually expected of a senior engineer versus a staff engineer? How do performance reviews work in practice? How do you negotiate compensation? I navigated all of this through trial and error. Orosz lays out the mechanics explicitly.

Having both tracks visible earlier would have made the fork feel like a choice rather than something that happened to me.

The career that didn't have a name

At one point later I was managing a team, but also doing business analysis, talking to customers and vendors, managing projects, running standups, designing systems, and developing features. I liked all of it. Then I was given a hard choice: be a full-time manager, or go back to being an IC. Neither option fit. I liked making technical decisions that had real impact, but the problems I was most drawn to were stakeholder problems, human problems, organizational problems. I had to find and carve a path that didn't have a clear name yet.

Will Larson's Staff Engineer gave that path a shape. He defines archetypes for IC leadership at the staff level and above: tech leads who guide project execution, architects who own technical vision across teams, solvers who parachute into the hardest problems, right hands who extend a leader's reach. Reading the descriptions, I recognized what I'd been doing without a label. The staff engineer role fits neatly into this space where you're making technical decisions with organizational impact, and the problems you're solving are as much about people and alignment as they are about code.

Tanya Reilly's The Staff Engineer's Path picks up the practical side. How do you build credibility with teams you don't own? How do you drive technical strategy without direct authority? How do you manage technical debt as an organizational challenge rather than just a codebase problem? Reilly's emphasis on influence without authority matched my experience exactly. The further I moved along this path, the less the job looked like writing code and the more it looked like persuading, aligning, and unblocking. Nobody teaches you that transition explicitly. Reilly comes close.

What makes people follow someone

The best engineering leader I've worked with never had a management title. He ran architecture reviews where people actually showed up prepared, not because he made them, but because he made the sessions worth attending. He was honest when he didn't know something. He pushed back on bad ideas with enough care that people felt challenged, not attacked. When he proposed something bold, people went along because he'd earned it through months of following through on smaller commitments.

Steve Farber's The Radical Leap puts a framework around that kind of leadership. His model is built on four elements: Love, Energy, Audacity, and Proof (LEAP). Love your work and the people you do it with. Bring energy that others can feed off. Think boldly enough to challenge the status quo. And back it up with action, not just words.

That last element, proof, is the one that resonates most in engineering culture. Credibility is earned through results, not declarations. The engineers who drive the most meaningful technical change tend to be the ones who've built a track record of reliable follow-through before they ever propose something risky. Farber calls it "proof before audacity." In an industry where trust is built commit by commit, that order matters.

How the best teams actually work

I've been on a team where people surfaced problems early, ran quick experiments without asking permission, and disagreed openly in meetings without it getting personal. I've also been on a team with equally talented engineers where problems festered for weeks because nobody wanted to be the one to raise them. Same company. Same tools. The difference wasn't skill. It was whether people felt safe enough to take risks.

Robert Bruce Shaw's Extreme Teams studied teams at Pixar, Netflix, and Airbnb to understand what creates that difference. His finding is that it's less about who's on the team and more about the conditions they operate in: whether ownership is genuinely shared, whether experimentation is built into the process, and whether transparency is something the team practices daily rather than something leadership talks about quarterly.

What makes this useful beyond theory is that the conditions Shaw describes are designable. A tech lead who creates a weekly space for rough prototypes, who makes it safe to say "this isn't working," who shares context instead of hoarding it, is shaping the team's environment in exactly the ways Shaw's research points to. You don't need to be at Pixar to apply this. You just need to recognize that team performance is an output of the system, not just the people in it.

Charting your own course

If someone had handed me some of these books when my manager asked that question, I wouldn't have frozen. I might not have had an answer yet, but I would have understood what I was choosing between. IC leadership, management, purpose-driven teams, technical vision at scale. The landscape is wider than the junior-mid-senior-manager line most of us start with.

I still don't think there's one right path, and you'll likely jump from one track to the other several times. But seeing the map clearly enough to make a deliberate choice, rather than drifting into whatever opportunity shows up next, changed how I thought about my career entirely.

The list