← Back to System Internals

The Manager's Path — High-Level Learnings

A practical, high-level summary of the ideas in The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier — a rung-by-rung field guide to the engineering management career ladder, from mentoring your first intern to running an organization.

Most books on management treat it as a single job. This one treats it as a ladder: a sequence of distinct roles, each with its own skills, failure modes, and a little more distance from the code you used to write. Fournier walks that ladder one rung at a time — being managed, mentoring, tech lead, managing people, managing a team, managing managers, and finally senior leadership — and for each she answers the two questions that actually matter: what is the job now, and what does doing it well look like? What follows is a summary of that progression in my own words, meant as a study aid; the book itself is worth reading for the candid stories and concrete scripts behind each stage.

1. The path, an overview

The core idea of the book is that management is not a promotion you receive once, but a distinct discipline you climb in stages. Each rung adds scope — more people, more ambiguity, longer time horizons — and each rung moves you a little further from writing code and a little closer to shaping the conditions in which other people write it. The skills that made you a great engineer do not automatically make you a great manager; every stage asks you to relearn what "doing good work" means.

The book is organized as a climb up this ladder. The table below lays out the stages and the one-line "core job" that defines each one.

2. Being managed well & mentoring

Fournier starts at the bottom of the ladder on purpose: before you learn to manage, you should learn what good management feels like from the receiving end. Knowing what to expect from your own manager makes you both a better-managed engineer and, later, a better manager yourself.

• Expect a real 1:1. A good 1:1 is protected, recurring time that is largely yours to drive — a place to raise blockers, get feedback, and talk about growth, not just a status readout your manager could get from a ticket.
• Own your side of the relationship. Bring topics, ask for what you need, and be honest about where you are stuck. Being managed well is a two-way effort, not something done to you.
• Expect feedback and context. Your manager owes you a clear sense of how you are doing and how your work connects to the bigger picture.

The first real step onto the leadership ladder is mentoring — taking an intern or a new hire and investing in their success. It is leadership in miniature: you practice explaining context, giving feedback, and being patient, but with a scope small enough to learn on. Mentoring well is also the clearest early signal that you might enjoy and be good at management.

3. The Tech Lead

The tech lead is, in Fournier's framing, a role, not a rank — a set of responsibilities you can be handed while remaining an engineer, not a rung you are permanently promoted onto. It is often the first place people discover whether they like leadership, because it forces the central tension of the whole ladder into the open: you are still expected to write code, and you are now also responsible for the success of a project and the people on it.

The hard part is the balancing act. A tech lead must:

• Keep building — stay hands-on enough to hold technical credibility and understand the work, without trying to do all of it yourself.
• Own the technical direction — make and defend the architecture and design decisions that set the project's course.
• Run the project — break the work down, sequence it, track it, and communicate status to stakeholders.
• Unblock others — treat clearing the team's path as first-class work, even when it costs you coding time. The instinct to grab the most interesting task yourself is the classic tech-lead trap.

4. Managing people

Becoming a people manager is the sharpest transition on the ladder, because it inverts your definition of productivity: your job is no longer to do the work but to enable others to do it. A day with no code written but a report unblocked and a conflict resolved can be your most valuable day, and that takes real adjustment.

The tools of this stage are relational, and trust is the currency underneath all of them:

• The 1:1 is your primary instrument — regular, protected, and mostly driven by the report. It is where you build the relationship, surface problems early, and coach.
• Feedback should be frequent, specific, and timely — not saved up for review season. Praise in public, correct in private, and never let the annual review contain a surprise.
• Delegation is how you scale, and it is uncomfortable at first: you must let others do work you could do faster, and accept that "good enough and theirs" often beats "perfect and yours."
• Underperformance has to be named honestly and early. The kindest thing is a clear, direct conversation with a concrete path forward — avoidance is what actually harms the person and the team.

5. Managing a team

Managing a whole team raises the stakes on a question that never goes away: how technical should you stay? Fournier's answer is that you must stay technical enough to earn respect, make good calls, and know when you are being told something that does not add up — even though you are no longer the one shipping the code.

Much of the job at this stage is debugging the team the way you once debugged systems. When delivery slows or morale dips, you look for the root cause: is it unclear priorities, a broken process, a personality conflict, a lack of ownership? A few themes recur:

• Diagnose dysfunction, don't just treat symptoms. A team that keeps missing dates or churning on rework has an underlying cause; your job is to find and fix it, not to add pressure.
• Manage process as a shield and a channel. Protect the team from pointless overhead, but introduce just enough structure — planning, on-call, code review norms — to make good work repeatable.
• Cultivate healthy conflict. A team that never disagrees is usually one where people have stopped speaking up. Your job is to make it safe to disagree on ideas while keeping it respectful about people.

6. Managing managers

When you start managing other managers, you begin leading almost entirely through other people. You are now two steps removed from the work, and your leverage comes from the quality of the leaders you develop rather than anything you touch directly. The central challenge is staying informed and effective without slipping into either of the two failure modes: micromanagement (you can't help meddling in their teams) or neglect (you assume no news is good news and lose touch).

• Delegate outcomes, not tasks. Hold your managers responsible for the results of their teams and give them room to decide how to get there.
• Use skip-level 1:1s. Talking directly with your managers' reports is your best window into what is really happening on the ground — it surfaces problems your managers might be filtering out.
• Hold managers accountable. Set clear expectations for their teams' health and delivery, and follow up. A struggling team is ultimately a management problem to address, kindly but directly.
• Spot problems at one remove. You have to read second-hand signals — attrition, missed commitments, quiet reports — and act on them before they become crises.

7. Senior leadership

At the top of the ladder — VP of Engineering, CTO, and the roles around them — the work becomes about the whole organization rather than any single team. Your impact is diffuse and long-range, mediated by the systems, structures, and culture you put in place. The core responsibilities shift again:

• Set strategy. Decide where the engineering organization is going and why, and translate that into priorities people can actually act on.
• Shape culture. At this level culture is largely set by what you model, reward, and tolerate. You are always being watched, so being a consistent role model is part of the job, not a nice-to-have.
• Design the org. Structure — team boundaries, reporting lines, how groups coordinate — is one of your most powerful and lasting levers.
• Decide with incomplete information. The higher you go, the less certainty you get. Senior leadership is largely the skill of making good-enough calls under ambiguity, taking responsibility for them, and adjusting as reality comes in.

8. Applying it — where are you on the path?

The value of thinking in rungs is that it lets you locate yourself and pick the next thing to grow. A few prompts to self-locate:

• Have you mentored anyone? If not, that is the cheapest, lowest-risk place to test whether leadership appeals to you — grab the next intern or new hire.
• Are you a tech lead? Notice which pull is stronger: the code, or unblocking the team. Your honest answer hints at whether the manager track fits you.
• Managing people? Audit the basics — are your 1:1s real, is your feedback timely, are you delegating or hoarding? Growth here is usually about letting go.
• Managing a team? Ask whether you are still technical enough to be trusted, and whether you can diagnose why the team is struggling, not just that it is.
• Managing managers or an org? Check for the two failure modes — are you micromanaging your leaders, or coasting on no-news-is-good-news? Grow toward accountability plus skip-level insight.
• Not sure you want the next rung? That is a valid answer. The ladder is not a mandate; a great senior IC or tech lead is a fine place to stay.

9. Summary

The whole book reduces to a single arc: management is a ladder of distinct jobs, and climbing well means relearning what "good work" is at each rung.