Every Rung Is a Different Job

The Core Insight

Camille Fournier joined Rent the Runway in 2011 as a director of engineering in name and something closer to a tech lead in practice. Four years later she was CTO.

The Manager's Path walks that distance one rung at a time. Each rung is a different job. The skills that earned the promotion are the ones the new job asks you to stop using.

Most engineers read the ladder as one job with more scope bolted on at each level. Fournier treats every level as a distinct job with its own failure mode, and the common failure is doing the previous job well. Marc Hedlund gives her the line the book rests on: new manager is an entry-level job with no seniority on any front.

She writes for engineering managers and treats engineering management as a technical discipline. Each rung gets defined by how much code you still write, and by what replaces the code you stopped writing.

The Framework

Fournier sizes each rung by how much of the output is still yours.

• Being managed teaches the instrument from the other chair, since one-on-ones run the same in both directions.
• Mentoring practices three skills: listening, communicating what needs to happen, and adjusting to the response.
• Tech lead is a set of responsibilities, often temporary, that any senior engineer can take on.
• Managing people adds one-on-ones, feedback, reviews, and firing on top of the technical work.
• Managing a team means owning the bottlenecks and roadblocks that stop other people.
• Managing managers and the executive rungs trade sight of the work for strategy and accountability.

The code line gets drawn precisely. An engineering lead still ships bug fixes and small features, on the condition that they block nobody. Past three or four direct reports across a couple of teams, production code stops, and secondary code reviews, pair programming, and postmortems replace it.

Fournier sets one prerequisite for leaving daily code. Get fluent in a language first, which took her about 10 years including her undergraduate and graduate degrees.

Delegation is not abdication, and the manager stays accountable for the team's problems regardless of what caused them.

Key Ideas

The Tech Lead Carries the Project and Gets No Raise

Rent the Runway wrote the definition into its own ladder. The tech lead role is a set of responsibilities any engineer takes on at the senior level, and it is not a rung. It can include people management, and then it carries weekly one-on-one touchbases and regular feedback on career growth. Patrick Kua puts a floor under it: at least 30 percent of the time still writing code with the team.

Fournier runs the role through one scene, with a product manager, four other engineers, and a multiweek initiative. The tech lead names the systems that must change and orders the estimates. Agreed abstractions create parallel work, so the frontend starts once the JSON format is settled and before the API exists. The tech lead keeps coding, raises obstacles before the heroics start, and delegates as delivery nears.

Fournier calls the reward the Stone of Triumph: a pure increase in responsibility and scope, with a raise or title bump rarely attached. Your own productivity now counts for less than the productivity of the whole team.

The One-on-One Is the Instrument, and Weekly Is the Default

The default cadence is weekly, changed only by mutual agreement. Mondays and Fridays lose to long weekends, and mornings beat afternoons. Status belongs in email or chat, which leaves the meeting for what status cannot carry.

Five styles cover the room: the to-do list, the catch-up, the feedback meeting, the progress report, and getting to know you. Quarterly is frequent enough for the feedback meeting unless performance is the problem. The progress report suits managing managers and is a waste with a handful of individual contributors.

One shared running document per person becomes the record the review gets written from. Marc Hedlund compares regular one-on-ones to oil changes, and skipping them strands you at the worst time. With too many reports, shorten the meeting or move to biweekly. Skipping it is how you miss the person about to quit.

Ask a new report which channel carries serious feedback and which manager behaviors he hates. Set a 30, 60, and 90 day plan, since goals inside 90 days catch a mishire early. State the struggle window out loud: an hour on some teams, a week on others.

Delegation Has a Matrix, and Abdication Is Not on It

Jane sits in every standup, reassigns tickets, and takes the project back from her tech lead Sanjay, who quits the role. Sharell agrees with Beth which meetings she attends and which details get escalated. Autonomy is part of motivation, so a micromanager cannot keep a good team.

Five rules pick what a manager digs into. With goals progressing, systems stable, and the product manager happy, a cursory overview is the whole job. Go to the systems before the people, because version control, tickets, alerts, and metrics answer most of it. Standards for code and systems take the person out of technical feedback. Given 45 hours in a week, five of them spent nitpicking a junior developer's code is the wrong trade.

• Simple and frequent work gets delegated: daily standups, weekly progress summaries, minor code reviews.
• Simple and infrequent work you do yourself, even when it looks beneath your title.
• Complex and infrequent work gets delegated for training: performance reviews, hiring plans.
• Complex and frequent work gets delegated with care, to grow the team: project planning, systems design, outages.

The same sorting runs the calendar. Important and not urgent work is what gets dropped: hiring plans and conflict with a peer manager. Fournier keeps a solid half day once a week with no meetings in it.

Debug the Team Before You Debug the People

Four dysfunctions cover most broken teams. Not shipping shows in release frequency, and her own team went from weekly releases that took hours to daily ones. Morale jumped, because a release used to be a scarce contended resource. People drama covers the brilliant jerk and the negative person. Overwork gets 20 percent of every planning session spent on system sustainability work.

The budget is 10 productive engineering weeks per engineer per quarter. A quarter holds about 13 weeks, and vacations, meetings, review season, outages, and onboarding take the rest. Hold 20 percent for sustaining engineering, since filling to 100 percent with features slows features down. Double any off the cuff estimate, and past a couple of weeks demand planning time as well.

As a deadline approaches, saying no becomes the job. Cutting scope is the only way to hit the date, and the no goes to engineering and to product.

Debugging a broken team runs like debugging a system. Form a hypothesis, then check the data in chats, tickets, code reviews, and calendars. A manager who skips one-on-ones shows up there, and a boring meeting signals an absence of healthy conflict. The engineering proxies for team health are release frequency, check-in frequency, and infrequency of incidents.

Skip-Levels Are How You See Past Being Managed Up

The open-door policy is a fallacy, since few engineers walk into their boss's boss with a problem. The risk of trusting the door grows with distance. A skip-level is a meeting with the people who report to the people who report to you. It catches the manager who is managing you up at his team's expense.

The first form is a short one-on-one with each person, roughly once a quarter. With 60 working days in a quarter and 60 people, that is one meeting a day. At 1,000 people it consumes a 40 hour week and nothing else. The second form is a team lunch a couple of times a quarter, which reads dynamics and loses individual coaching.

Fournier tests accountability on three scenarios: a changing roadmap over unstable systems, a rabbit-holed tech lead, and a team firefighting legacy systems. The manager is accountable in all three, and surfacing the problem early is the work. The people pleaser is everyone's friend and fixes nothing, and the repair is moving decisions out of his discretion. The control freak removes the team's ability to decide at all, hides from you, and gets caught by skipped one-on-ones.

Structure Arrives After the Failure That Proves You Need It

Startup people hear structure and process as slow and hostile to invention. Fournier renames them: structure becomes learning, and process becomes transparency. Jo Freeman supplies the argument in The Tyranny of Structurelessness, where a group that pretends to lack structure grows a hidden one. An unstructured group works only when it is task oriented, small and homogeneous, high in communication, and low in skill specialization. The limit is about five people, and 10 to 15 only when the group holds several smaller subgroups.

Gall's law sets the build order: a complex system that works evolved from a simple one that worked. Failure teaches, and success is a poor teacher. New hires slowed her team for months with no onboarding process, and a third production outage came from someone dropping a critical table.

The career ladder came out of a pay failure, where salaries ran on prior salary plus negotiating skill. Her first attempt copied a friend's ladder, eight levels from entry-level engineer to executive across four categories. It flopped, because her team came from many backgrounds and his came from one large employer. Where levels are few, bands go wide and overlapping: 50,000 to 100,000 dollars for software engineer against 80,000 to 150,000 dollars for senior. Then set the breakpoint level, the lowest level where a person sits forever without underperforming, which for many companies is senior engineer.

Practical Applications

Put a weekly one-on-one on the calendar for every report, in the morning, off Monday and Friday. Take the notes yourself. When the report count grows, shorten it or move to biweekly, and never cancel.

Budget the quarter before you promise anything. Count 10 productive engineering weeks per engineer, hold 20 percent for sustaining engineering, and double every estimate you gave off the cuff.

Run the matrix over your own calendar this week. Delegate the standups and the minor code reviews, do the rare small task yourself, and hand the next review cycle to someone learning it.

New to managing five engineers, spend the first 60 days inside the work. Run the developer onboarding, watch code reviews, and ship a couple of features. Pair in both directions, perform a release, and take a support rotation.

When you hire a manager, test the skills before the culture, because a manager bluffs you better than an engineer does. Have her future reports role-play a one-on-one using a problem they have this week, and ask her for a management philosophy.

Who This Is For

Engineers about to take the tech lead role get the most, then first-year managers, then managers who just inherited managers. Each chapter answers the rung you are standing on.

Skip it for generic management theory, or for managing people outside engineering. The advice assumes you can read a code review and judge an architecture.

The vantage is one company. Rent the Runway was a venture-backed software business with real funding, a real ladder, and enough people to average across. At five people, much of this inverts. An eight-level ladder, a 360 review cycle, and a quarterly skip-level program are structure a five-person team does not carry. She says so herself, calling rigid hierarchy at that size ridiculous.

The averages break at small size too. A budget of 10 productive weeks per engineer and a 20 percent sustaining reserve assume a team large enough to average. The tech lead advice assumes a ladder exists to be promoted on. Her own warning runs the other way for small companies, where structure arrives too late more often than too early.

The figures are her practice at one company rather than measurements across many. The case characters are named caricatures like Jane and Sharell, and they carry the pattern rather than the evidence. The mechanisms hold on their own logic, and the cadences need your own measurement before they enter a plan.

The Decision

Write down what the rung above you produces. For a senior engineer, the answer is a project that keeps moving and a team that is not blocked. For a manager of one team, the answer is other people making the calls you used to make.

Then mark last week's calendar against that list. Hours spent producing the output of your current rung are the hours the next rung deletes.

Fournier's ladder expects people to act at the next level before the promotion arrives, which is her guard against the Peter Principle. The test and the job are the same thing.