Deep Reading · Off-list
Camille Fournier · 2017
This book turns "how a technical person leads teams, one rung at a time" into a clear route — from mentoring a single intern all the way to being CTO — and at every level it tells you the one thing almost everyone only learns the hard way: each step up is not "the same job with more authority" but an entirely new job, one that forces you to let go of the very craft you were proudest of on the rung below. No pep talk — just a map with real desks marked on it.
Camille Fournier was CTO of the fashion-rental company Rent the Runway, a senior engineering leader at the hedge fund Two Sigma, and an early contributor to Apache ZooKeeper (a coordination service for distributed systems) — someone who climbed from writing code to the executive suite and actually led teams along the way. Her 2017 book grew out of a popular blog and talks, and is the acknowledged "ladder handbook" of engineering management. Unlike most management books, which treat "management" as one vague activity, it is written level by level — each chapter maps to a real step on the engineering-management ladder. That layering is the whole point: most management confusion is really you doing this level's job with the previous level's mindset.
This is the book's spine and its most counterintuitive claim. People assume "senior engineer → manager" is one notch up; in fact it is a sideways leap into another profession. As an engineer, your output is what you personally deliver; as a manager, your output becomes what your whole team delivers — you write not a single line of code, the team ships faster and better, and that is what "doing your job well" now means.
Fournier breaks the route into clear steps: mentoring newcomers → tech lead → manager of people → manager of multiple teams → manager of managers → executive (director/VP/CTO). At every step up, you are forced to put down the very thing you were once best at and most secure in. The tech lead codes less; the manager barely codes; the executive no longer touches individual projects at all. Many people rise and suffer precisely because they clutch the previous level's work — a manager still fighting to write the core module himself is, at bottom, fleeing back to his comfort zone while starving his team. See that "this is a career change," and you will go learn the new job instead of treating the new role as a beefed-up version of the old one.
If this book leaves you with only one thing, let it be to run your one-on-ones well. A 1:1 is the fixed, private, regular conversation (usually weekly or biweekly) between a manager and each direct report. Fournier hammers the point: do not casually cancel them — the moment you do, the signal you send is "you don't matter."
The 1:1 does two irreplaceable things. First, it builds human connection and trust — if you never talk in calm times, you have no account of trust to draw on when something goes wrong. Second, it is a channel for information — a report's confusion, worries, and doubts about direction only surface in this safe, private setting. She also names the common failure modes: running the 1:1 as a "status report" (just look at the board for that) or, at the other extreme, letting it drift with nothing to say. A good 1:1 mixes it up: sometimes a run through the to-do list, sometimes a pure check-in on how they're doing, sometimes a session set aside for feedback or career growth. Treat the 1:1 as the heart of managing down, not an optional formality — this is the earliest place good managers pull away from new ones.
Fournier sees the move from pure coding to tech lead as often the most awkward transition on the whole path. The reason: you usually have no real management authority — the people on the team aren't rated or paid by you — yet you are responsible for a project's technical direction and delivery. In her words, this is the first lesson in leading through influence, not authority: you get people to move by making the technical case clearly and earning their confidence, not by "I'm your boss."
Harder still is the "player-coach" tension: you're still writing code, but the moment you bury yourself in the hardest chunk for two weeks and vanish, nobody is left to coordinate, break down, and align the project. Fournier's practical advice: a tech lead should deliberately dial down the share of time spent writing code personally (she puts it at roughly a third) and pour the freed-up energy into making it easy for others to write — splitting big tasks into parallelizable pieces, clearing blockers, aligning goals, and shielding the team from outside interference. The lesson of this leap: admit that "however fast I code alone, I can't outpace a team I've unblocked."
Two ways new managers capsize most easily: one is micromanagement — questioning everything, jumping in to edit it yourself, managing people until they suffocate; the other is abdication — total hands-off, no attention, dressed up as "delegation," until something breaks and you find it went off the rails long ago. Good management lives in between: delegate, but keep appropriate visibility.
Fournier offers a very usable heuristic. To decide whether and how to delegate a task, look at two dimensions — is it done "often or rarely," and is it "simple or complex" — which gives roughly four plays:
| Simple | Complex | |
| Done often | Delegate it away (don't hoard busywork) | Delegate to grow people (let them stretch in it) |
| Done rarely | Just do it yourself (handoff isn't worth it) | Do it, or coach closely (high risk, needs experience) |
Schematic: Fournier's delegation call — decide by "frequency × difficulty" whether to let go or do it.
The point: delegation is not "throw it over the wall and forget it" but keep the dashboards you need (watch measurable output, not every step of the process) and let go of the hands. Her maxim: trust, but verify — give people autonomy while keeping one channel that lets you catch problems early.
Fournier detests dumping feedback all at once in an annual review. Feedback's value lies in timeliness — say it when it happens and a person can still change; hoard it for half a year and it arrives late, cold, and feeling like an ambush. Her rules: praise in public whenever you can; criticize only in private, one-on-one; and be specific to behavior, not a vague verdict on someone's character.
She also debunks a popular but poor technique — the feedback sandwich (tucking criticism between two compliments): it looks smooth but leaves the other person either missing the real problem or, worse, treating your every compliment as the prelude to bad news. The better way is direct, respectful, and about the specifics — genuinely caring about the person while daring to name the problem to their face. (This is on exactly the same wavelength as Radical Candor.) Feedback is not a year-end ceremony; it is a daily muscle: the more you train it, the less your team fears the truth.
When you rise from "managing a few people" to "owning a team's output," Fournier offers a mindset especially palatable to engineers: treat a team that isn't delivering as a system that's throwing errors. Slow delivery, low morale, endless rework — these are "symptoms," and your job is to locate the "root cause," not to guess and blame some individual.
She lays out common team ailments and their treatments. Is it unclear direction (no one knows why they're doing this, priorities are a mess)? Then what's needed is clear goals and trade-offs. Is it no delivery cadence (projects drag forever, nothing ships)? Then slice the big goal into small steps that keep shipping — she treats "can this team ship reliably" as the most direct vital sign of team health. Is there hidden conflict or broken trust? Then put it on the table and address it head-on rather than tiptoeing around it. Or is it a skills/staffing mismatch? Then it's a hiring-and-growing problem. The key shift is this: when a team breaks, a good manager's first reaction is not "whose fault is it" but "where is this system stuck" — swapping emotional blame for engineer-style root-cause analysis.
Higher up, you begin managing managers — a whole layer of people now stands between you and the hands-on work. This creates a new difficulty: information gets filtered and prettified at every layer, and by the time bad news reaches you it is often too late. One of Fournier's remedies is the skip-level meeting (talking directly to your reports' reports, skipping the manager in between): periodically bypass that middle layer to hear the front line directly, so you can calibrate how far your managers' reports drift from what the team actually feels.
The deeper shift: your output is now the quality of "your managers." You no longer edit code or plans directly; you influence a large group indirectly by choosing, growing, and supporting good managers. A weak manager slowly bleeds a whole team dry — so the most important work at this level moves from "getting the thing right" to "getting the people-who-lead-teams right." She warns: don't pretend not to see just because you can't reach the front line, and don't reach past your managers to command directly (that undercuts the very people you appointed); walk the harder middle line between "trusting your managers" and "keeping visibility all the way down."
On "should a manager still touch technology," Fournier's answer is clear-eyed: you no longer need to be the best coder on the team, but you must keep enough technical judgment that you can follow along, ask sharp questions, and not be fooled. An engineering manager fully detached from the technology gradually loses the team's trust and can't make sound technical trade-offs or personnel calls. She rejects both extremes: don't fight to write the core code, and don't decay into a "pure manager" who only schedules meetings and can't read the system.
At the organizational level she has a sharp metaphor: process and structure are like "scar tissue" — almost all of it grew in response to some real wound in the past. That yields a superb test: whenever someone wants to add a new process, first ask "what real, existing problem does this actually solve?" Process that solves no concrete pain and is just "everyone does it this way" merely scars the organization and adds stiffness. Good process is the minimal response to a real problem, not decoration for a sense of safety. Add it as the team grows and it becomes truly necessary — don't strap on a suit of armor from day one.
The book's undercurrent is a question that keeps returning: are you the kind of boss you yourself would want to work for? Fournier honestly writes the part of management few name aloud — that it is emotional labor: you absorb the team's anxiety without leaking your own, stay steady in the face of bad news, and handle conflict and other people's emotions, all of it draining and often without the instant hit of accomplishment (unlike merging a PR). Precisely because of this, a manager must first manage themselves: know your own triggers, temper, and needs, and actively "manage up" (proactively ask your own boss for direction, resources, and feedback) to get the support you need, rather than expecting the role itself to take care of you. A manager who doesn't know themselves mistakes their own mood for a judgment about the team — a bad day becomes "that report has an attitude problem"; that is the most hidden kind of harm. Her self-check is plain and powerful: after each decision, each hard conversation, look back and ask, "if I were my report, would I want to be treated this way?" — carrying "would you work for this version of yourself" around as a pocket ruler.
Compress the whole book into one line, and it is a series of handovers as you climb the ladder — each rung trading "doing it yourself" for "getting it done through others":
What does it prove, and how? — It proves that engineering management is not a vague "soft skill" but a chain of concrete jobs that can be decomposed level by level and learned rung by rung; success at each level turns on whether you can put down the previous level's craft and pick up the leverage of "amplifying output through others." It proves this not with theory but by laying out, one by one, each level's daily tasks, common pitfalls, and self-check questions.
Misreading: this is a "how to get promoted" playbook. No. It is about what each level's job actually is and how to do it well, not how to climb. Come for "fast-track promotion tricks" and you'll be disappointed; its real use is keeping you from bringing the wrong mindset to each step and wasting years.
Criticism one: a strong industry and context bias. The whole book rests on U.S. tech companies, especially growth-stage firms of some size. Its assumptions about an "engineering organization" (clear levels, hiring budget, a 1:1 culture) don't necessarily transfer to small shops, outsourcing, non-tech industries, or steeply hierarchical cultures; it also says relatively little about remote/distributed teams, an issue that loomed larger later. Discount accordingly when porting it.
Criticism two: more operational checklist than deep theory. Its strength is being concrete and do-this-next, but that also makes it more of a warm field guide than a work of management theory. If you want a deeper account of "why people collaborate the way they do" (motivation, the mechanisms of organizational behavior), it offers little — better filled in elsewhere. Read it as an "on-ramp map," not a "final theory," and your expectations will be right.
Debate: "how much should a manager still code" has no fixed answer. She argues for keeping your technical edge, but at higher levels (managing managers, being a VP) what "staying technical" even means, she admits, varies by person and company. Some argue that an executive clinging to the technology oversteps and crowds out reports; that boundary each reader must calibrate against their own level and team.