Building Software at Scale in the AI & Cloud Era

← the whole book on one page

Chapter 9: Teams at Scale — Growing, Designing, and Leading the Organization That Builds

A team can be asked to do the impossible once. An organization has to be designed to do the difficult every year.

Every chapter so far has treated the organization as a given: forty teams, a platform group, a trio here and a staff engineer there. This chapter asks how it came to be, and how it should be shaped. Who belongs on which team, and how much should a team own? Who decides when two teams disagree, and who writes the decision down? How many people can an organization hire in a year before it stops getting faster and starts getting slower? These are among the oldest questions in our field, and engineers are seldom taught to answer them; most of us learn by getting them wrong.

The story that frames the chapter took place in a basement in Westborough, Massachusetts, between 1978 and 1980, where a small group of young engineers at Data General built a 32-bit minicomputer under a manager named Tom West, and the writer Tracy Kidder watched them do it. His book, The Soul of a New Machine (1981), won the Pulitzer Prize and has been passed from engineer to engineer ever since, usually as a story about what a committed team can achieve. Read to its end, it is also a story about what an organization pays when it depends on heroics instead of design, and that second reading is the one this chapter needs.

Encore reached 400 engineers in its seventh year and has stayed at about that size since. Now, in year nine, Verified Resale needs a team that does not yet exist. By month four of the bet a Resale team must be formed from people who already have jobs, with a product trio and a staff engineer, and its first cross-team decision, whether Resale or the Inventory team owns the reissue of a barcode, must be settled in a way that 12 teams will accept. We will follow that team, and use Encore’s history from nine engineers to 400 to explain why its teams, roles and decision forums look the way they do.

9.1 Growing from 9 to 400

The Eagle and what it cost

In 1977 Digital Equipment Corporation released the VAX, a 32-bit machine, and Data General’s 16-bit Eclipse line began to lose sales. Data General’s founder, Edson de Castro, moved the company’s lead development group to North Carolina to build an ambitious new 32-bit design, the Fountainhead Project. Tom West, who ran the Eclipse group in Westborough, was among the senior engineers who stayed behind, and in 1978 he proposed something smaller: a 32-bit extension of the Eclipse, compatible with the software customers already ran, offered as insurance in case North Carolina failed. De Castro gave tacit approval, West promised the machine in a year, and it was code-named Eagle.

West and his deputy, Carl Alsing, recruited about two dozen engineers, most of them straight out of college. The “Microkids”, led by Alsing, wrote the microcode; the “Hardy Boys”, led by Ed Rasala, built the hardware; Steve Wallach was the architect. West’s word for the commitment he asked of them was “signing up”, and in Kidder’s account it meant agreeing to do whatever the machine required, including a great deal of overtime, for no extra pay. West called the reward “pinball”: win one game and you get to play another, so the prize for building this machine was the chance to build the next. The team worked in near isolation, shielded from the company’s politics by a leader who kept the schedule always in front of them. Figure 9.1 draws the project and its team as a schematic.

The machine was late, as ambitious machines are, but it shipped. Fountainhead was cancelled, and Eagle was announced in April 1980 as the Eclipse MV/8000; by Evan Ratliff’s account in Wired 20 years later, it kept Data General in the minicomputer business for several years. What happened to the team concerns us more. A new vice president of engineering regarded the group as having defied the company, the group was broken up, and West was sent to Data General’s office in Japan before a single MV/8000 had been sold. By the time Kidder’s book appeared in July 1981, many of the engineers had left or were leaving, some to found companies and some simply burned out. Ken Holberger, one of the Hardy Boys, told Ratliff the team had been like gunfighters brought into town to solve a problem; they solved it, and “then the town had to figure out what to do with them afterward. Which was mostly to get rid of them.”

Figure 9.1 — The Eagle at Data General, drawn as a schematic. The machine shipped and the North Carolina project was cancelled, yet soon after the launch the team that built it was broken up.

Burnout is part of the story, but the departures were caused at least as much by the organization’s inability to recognize and absorb what the team had done. A small, isolated group can do remarkable work; Heidi Helfand would later call this the isolation pattern of reteaming, and Data General used it long before it had a name. An organization that relies on isolation, overtime and one protective leader has no way to keep the people afterward, fold their knowledge back into the company, or do the thing again. Tom West was a substitute for a design. This chapter is about designing an organization in which the next machine does not depend on another Tom West.

One team of nine

Encore began, as the Architecture book told, with nine engineers in one team building a modular monolith. Much of what made that team effective was invisible because it worked. There was one backlog. The two founders acted as an informal product trio, one holding the customer and the other the code. Decisions were made in conversation and remembered by everyone, because everyone had been in the room. New engineers learned the system by sitting next to the people who had written it, and nobody needed to write down who owned the payments code.

Tom DeMarco and Timothy Lister argued in Peopleware (1987, now in its third edition) that the major problems of software development are sociological more than technological. It is a thesis without a measurement behind it, but nearly four decades of practitioners have recognized it, and it is the right lens for what happened next. Encore did not hit a technical wall as it grew. It hit a social one, built of things that had been free. Implicit decisions stopped reaching everyone who needed them. Onboarding by proximity stopped working when the people worth sitting next to had three newcomers each. And knowledge of the payments code, still held by one person, became a risk whenever that person took a holiday.

Encore’s history marks the moment. In its second year, at about 25 engineers, a thread appeared in the company chat that began “Who decided this?” Someone had changed how holds expired, for good reasons, and two other engineers had built on the old behavior. Nobody had been careless; the decision had been made in a conversation that two of the people it affected were not part of. The Architecture book’s Chapter 5 opens with the arithmetic behind this, the number of possible conversations growing roughly as the square of the group, and the thread was its first visible sign at Encore.

Nine teams of 70

By year four Encore had 70 engineers in nine teams, drawn along the services that the Architecture book’s Chapter 5 cut (its Section 5.1 and Section 5.5 tell that half of the story). The half it leaves out is management, which is where most of the early mistakes were made.

The first managers were promoted from the best engineers, as they are in most young companies. Camille Fournier, in The Manager’s Path (2017), makes this a fork in a career: stay on the technical track, or become a manager. The branches lead to different jobs, and the skills that made someone an excellent engineer are only part of what the second demands. Encore presented management as a promotion, so some of its best engineers took a job they had not chosen and nobody had trained them for.

Will Larson’s rules of thumb, from his experience at Uber and Stripe, give a check on what Encore built. In “Sizing engineering teams” (2018) he writes that “managers should support 6-8 engineers”, that “small teams (<4) are not teams”, and that a new team is best made by growing an existing one to 8 or 10 and splitting it into two of four or five. These are heuristics, but they encode real forces: a team smaller than four cannot carry an on-call rotation or survive one departure, and a manager with more than eight reports has stopped managing and started triaging. The first draft of Encore’s 70-engineer map broke both rules. It showed 11 teams, two of them of three people who depended on a neighbor for every review and every page, and one manager in Orders & Payments had 14 reports. The two small teams were folded into their neighbors, which is how Encore came to nine, and the 14 were split under two managers within the year.

Hypergrowth to 400

Between years four and seven Encore grew from 70 engineers to 400. Hiring outpaced the organization’s ability to absorb people, managers of managers appeared, and every practice that had worked for nine teams was tested at forty. The Architecture book’s Section 15.3 shows what happened to the architecture review board, which becomes a bottleneck or a rubber stamp at forty teams, and its Section 5.5 shows what replaced it. The human side of the same growth followed the same arithmetic.

Larson’s essay “Productivity in the age of hypergrowth” (2016) is the clearest model of that human side. Writing about Uber, he observed that “our process is always six months behind our headcount.” In his model a trained engineer must spend time training each new one, and in his worst case, two untrained engineers to every trained one with the hiring load included, “the overall team is getting 1.06 engineers of work out of every three engineers.” The numbers are illustrative, from one company, and Larson presents them that way; the direction is not in doubt. Past a certain ratio of new people to experienced ones, adding people subtracts work. His prescriptions follow: concentrate hiring in one team at a time, and shorten training, because every week cut from it returns capacity to the whole team.

Encore’s version of the lag was visible in its numbers. At the end of year six it had 250 engineers, and 145 of them had joined within the previous 12 months. More than half the organization had never been through an on-sale and had learned the system from people who had learned it a few months before.

The organization as stocks and flows

The tool that makes this lag visible before it becomes a crisis comes from outside software. Jay Forrester founded system dynamics at MIT in the late 1950s, and Donella Meadows’s Thinking in Systems (2008) is its most readable introduction. A stock is a quantity that accumulates over time, such as the number of engineers still ramping up; a flow is a rate that fills or drains a stock, such as hires per month. Stocks change only through their flows, and flows are limited by things we can name. Tarek Abdel-Hamid and Stuart Madnick applied the method to software projects in Software Project Dynamics (1991). We borrow the method for a narrow purpose: checking a growth plan against the organization’s capacity to absorb it before anyone approves the plan.

Larson’s “Introduction to systems thinking” (2018) uses the frame mainly for developer velocity, with stocks of open pull requests and ready commits, and briefly for trained managers; the hiring model we need is closer to his hypergrowth essay. Drawn for people, it is simple. Hires enter a stock of engineers who are ramping; ramping engineers flow into the productive stock at a rate limited by onboarding capacity, which is the time of experienced people; and productive engineers leave through attrition or move into management. Each arrow has a limit, and a growth target has to be checked against all of them. Figure 9.2 draws it.

Figure 9.2 — People as stocks and flows. The valve between ramping and productive is opened only by experienced people’s time, and the productive stock feeds back into it, so a slow year weakens the next one.

Anyone who has worked the doors of a large concert venue knows this shape. However many fans are queuing outside, the hall fills only as fast as the doors and stewards allow, and a promoter who sells more tickets than the doors can admit before showtime has sold a longer queue. The ramping stock is the queue, and experienced engineers are the stewards. The analogy breaks in a way that makes the organizational case worse: fans who get through the doors simply watch the show, while newcomers who get through onboarding become the stewards for the next cohort, so a slow door one year produces poorly trained stewards the next.

In year nine, prompted by the developer survey of Section 1.2, in which one engineer in five named new engineers taking about a quarter to make a meaningful change among their top three complaints, Encore redrew its years of hypergrowth this way. Figure 9.3 shows the result.

Figure 9.3 — Encore’s people as stocks and flows. The ramping stock grew faster than the engineers available to teach it, and the time to a tenth change, a proxy for ramp-up, nearly doubled and never came back down.

The table told a story the retrospectives had missed. For two years teams had blamed slow delivery on “culture”: on newcomers who did not care about quality, or a loss of the founding spirit. The stock-and-flow view named the constraint. Onboarding depended on a buddy from the same team, and a buddy could usefully take one newcomer at a time. In year six there were fewer engineers with a year’s tenure than newcomers, so buddies were doubled up, borrowed from other teams or skipped. The time to a tenth change rose from about five weeks to about 10 and stayed there after hiring slowed, because those who had ramped slowly became the next cohort’s buddies. It was a flow limited by a stock, and Section 9.4 applies the flow solutions.

The model also has an outflow, which Encore had watched carelessly as a single annual attrition percentage. It now tracks regretted attrition, the departures its managers would have tried to prevent, separately from the rest, and reads exit interviews against the stock-and-flow picture, because a team that loses two experienced engineers in a quarter also loses part of its capacity to ramp the next ones.

What did not have to break

Not everything that broke was forced by arithmetic. Some of it Encore did to itself, and Peopleware has catalogued such wounds for nearly 40 years. Its best-known evidence comes from the Coding War Games that DeMarco and Lister ran from 1984 to 1986, in which more than 600 developers from 92 companies worked separately on the same specification, in pairs from the same organization. Language made no difference except for assembly, and years of experience did not predict performance. Pay barely tracked it: the better-performing half earned less than 10% more than the other half while performing nearly twice as well. Nearly a third of participants finished with zero defects and paid no penalty in speed. The top quarter outperformed the bottom quarter by 2.6×, the best organization worked 11.1 times faster than the worst, and pair mates from the same organization performed within about 21% of each other, which points to the organization more than the individual. The top performers also reported quieter, more private workspaces. The data are correlational, partly self-reported and gathered in offices before open-plan floors and remote work. They remain the best-known evidence that the environment an organization provides accounts for much of the difference between developers.

Peopleware also named the ways organizations destroy teams without meaning to, which it called teamicide: defensive management, bureaucracy, physical separation, fragmentation of people’s time, the quality-reduced product, phony deadlines and clique control. Read against Encore’s year six, the list is uncomfortable. At about 200 engineers, a quarter of them were assigned to two or three initiatives at once. A launch date for the organizer console was set before discovery had started, and missed by a quarter. Encore avoided other items: teams sat together, in an office or a shared channel, and nobody was asked to ship a product the team believed was broken. Each item on the list looks like a reasonable management decision on the day it is made, and its cost appears later, in a team that has stopped jelling.

Encore’s engineers work across several EU countries and time zones, so the office data of the 1980s describe only part of its world. The claim about uninterrupted time carries over; a distributed team protects it with written communication, meetings clustered into part of the day, and agreed core hours.

Recap. Encore’s growth broke first where things had been free: implicit decisions, onboarding by sitting nearby, and knowledge held by one person. Larson’s hypergrowth model and the stock-and-flow frame show why: the ramping stock grows faster than the experienced people who can drain it, and process lags headcount by months. Some damage was not forced by growth at all, and Peopleware’s teamicide list, old as it is, still names it.

Exercise 9.1. Draw your organization’s last three years as a stock-and-flow diagram of people: hired, ramping, productive, leaving. Put a number on each flow, and mark the stage at which each of your current pains first appeared. Then name the flow that limits the others.

9.2 Designing Teams

Forty teams on one map

The vocabulary for team design is shared across this series. Matthew Skelton and Manuel Pais’s Team Topologies (2019; second edition 2025) gives four team types, stream-aligned, platform, enabling and complicated-subsystem, and three ways for teams to interact. The Architecture book’s Section 5.5 uses them, with Conway’s law, to draw teams to match services, and its Section 15.2 sizes the platform group at 5 to 10% of engineering. We take all that as given and show the map itself, since a vocabulary proves its worth only on a real organization.

Figure 9.4 — Encore’s team map at about 400 engineers. Forty stream-aligned teams average nine engineers each; enabling work is carried as a second duty by two teams instead of by standing enabling teams.

Two features of the map depart from the textbook. Encore has only one team that behaves as a complicated-subsystem team, Forecasting, whose demand models need specialist statistical knowledge and reach Organizer Insights through an interface. Seat allocation and bot scoring are hard too, but they are the core of their stream-aligned teams’ work, and separating the specialists from the stream would add a hand-off to every change; a complicated-subsystem team earns its place only when the specialism is deep and the interface narrow. And Encore has no standing enabling team. Design System coaches other teams on accessibility and AI Platform helps teams adopt its gateway and eval tooling, each as time-boxed engagements that end when the other team can work alone. Marty Cagan and Chris Jones’s Empowered (2020) gives a product-side reading of the same map, distinguishing experience teams, whose customers are end users, from platform teams, whose customers are other teams.

A caution belongs beside any published team map, this one included. The “Spotify model” of squads, tribes, chapters and guilds was copied widely after Henrik Kniberg and Anders Ivarsson described it in a 2012 paper, Scaling Agile @ Spotify. In April 2020 Jeremiah Lee, who had worked at Spotify, wrote that the model had been “only ever aspirational and never fully implemented” there. A published map shows the shape one organization chose for its own constraints. Another organization can borrow the reasoning only if it can see it, which is why this section gives the reasons beside the map.

Cognitive load as a budget

The Architecture book defined cognitive load and traced it to John Sweller’s research on learning, and the Operations book uses it to limit what a team can be asked to operate. Here it is a budget: when a team overspends it, something must be handed away. The framing matters in practice. Asked whether a team is overloaded, people argue about the answer; asked what the team would hand to someone else, they have to name a responsibility, and a named responsibility can be moved.

No validated instrument for team cognitive load exists; Team Topologies’ own materials call its measurement a challenging area, and the book offers the idea, with a team size of roughly five to nine people, rather than a scale. Encore runs a short self-assessment each half: each team rates how many domains it owns, how often other teams interrupt it, how much of its on-call load comes from things it did not build, and how well it understands each system it owns. The answers start a conversation between a team and its manager and are never used to compare teams. The Brazilian fintech Creditas has described a similar practice as a Team Topologies case study, without numbers, which is about the strength of the evidence: the practice is in use, and its value is the conversation.

The assessment earned its keep in year nine. Partner APIs already owned the partner endpoints, inventory feeds, sandbox, certification and webhooks; Verified Resale would add a new partner API, a reissue certification suite and Tessera’s onboarding after Rowmate’s, while three of its nine engineers left for the Resale team. Every dimension came back red, and the conversation produced one decision: Partner APIs would hand webhook delivery to the platform group. Chapter 6 tells the platform’s side. Its own audit of requests had already ranked shared webhook delivery among its first increments, and it built the capability by absorbing three home-grown senders, Partner APIs’ first. From this side the same hand-off was a budget decision by an overloaded team, and because the two views met, the work moved within a quarter.

Team APIs and interaction modes over time

A team that owns services also owns promises to the teams around it, and they are worth writing down. A team API is a short, written description of what a team owns, how other teams should ask it for things, and what it promises in return. Skelton and Pais publish a free template, and the Resale team’s first draft read like this:

# Team API: Resale (formed month 4)
Owns: Resale service, Resale fan-app module (15th), resale rules engine (InnerSource host),
      organizer rule assistant
Does not own: barcode issuance and revocation (Inventory), payouts (Billing & Payouts)
Ask us: #resale-requests channel; reply within 1 working day; rule-type contributions by PR
Interaction modes:
  Inventory            collaboration on reissue, months 4–7; then X-as-a-Service via `reissue` API
  Security Engineering collaboration on partner credentials, months 4–7 (Chapter 6)
  Web & API Paths      collaboration on shared webhook delivery, months 4–8; then X-as-a-Service
  Partner APIs         X-as-a-Service: we consume the partner gateway and sandbox
On-call: own rotation from first production deploy; runbooks in the service registry
Review this API: every quarter, and whenever a mode's end date arrives

The middle section carries most of the design. In collaboration, two teams work closely on a shared problem, with blurred boundaries and high communication cost, because neither yet knows where the boundary belongs. In X-as-a-Service, one team consumes what another provides through a clear interface. In facilitating, one team helps another learn something and then steps away. Collaboration discovers the boundary, and X-as-a-Service makes it cheap to live with.

This works only if the end date is real. Teams that collaborate well tend to drift into it permanently, because nobody is obliged to define the interface that would let them stop, and a collaboration without an end date becomes one team spread across two org-chart boxes, paying the coordination cost of two teams without their independence. So Encore writes the end date into both teams’ APIs and reviews it when it arrives. Resale and Inventory collaborated on reissue for one quarter, months four to seven, working in the barcode issuance code together; then Inventory published a reissue operation with a contract test, and the relationship became X-as-a-Service.

Reteaming as a capability

Teams change shape constantly in a growing organization, and most organizations improvise each change and then forget it. Helfand’s Dynamic Reteaming (2nd edition, 2020), drawn from her years at AppFolio and interviews elsewhere, treats reteaming as a capability and gives it five patterns. In one-by-one, people join or leave a team. In grow-and-split, a team grows too large and divides. In isolation, a small group is set apart, with its own way of working, to build something new or handle an emergency. In merging, teams combine; in switching, people move between teams to spread knowledge or to grow. Her evidence is practitioner experience, so the patterns describe what happens in growing companies without promising what works.

Two practices from the same tradition have public cases. In self-selection, people choose their teams within stated constraints; Sandy Mamoli and David Mole ran such events for a department of about 300 people at Trade Me in New Zealand and described the method in Creating Great Teams (2015). The constraints make it work: each team must end with the skills it needs, and people know in advance what happens if choices do not balance. The calibration session is a working meeting, held when a team forms or doubles, at which it agrees its purpose, working agreements and roles instead of assuming the old habits carried over. Helfand also names anti-patterns, two of them common: breaking up a high-performing team to “spread” its performance, and reteaming by abstraction, announcing a structure without explaining what it means for the people in it.

A larger reorganization adds a sequencing problem. Larson’s “Running an engineering reorg” in An Elegant Puzzle (2019) and Lara Hogan’s communication plans in Resilient Management (2019) agree on the essentials: decide who hears what, in which order and through which channel, before anything is announced, and write down the questions people will ask. Managers hear first so they can answer, the people most affected hear next and in person, and everyone else hears the same day.

Encore formed the Resale team by the isolation pattern, from volunteers. Before announcing it, the engineering director for the partner area wrote a one-page reteaming FAQ: why a new team instead of a project inside Orders & Payments, who could volunteer, what would happen to the teams they left, and whether anyone could go back. There were 12 volunteers for seven engineering places. Four came from Orders & Payments, among them Katrin, who had been the discovery trio’s tech lead, and three from Partner APIs, so that the team held both the purchase saga and the partner surface. Theo, a graduate, joined at month 4 as the team’s first hire from outside, after these founding seven (Section 5.5). Amira, the product manager, and Paolo, the designer, who had run discovery with Katrin (the Products book’s Section 1.3), moved with the work, so the trio that wrote the bet also built it, and a staff engineer from Orders & Payments was lent to the team for nine months. In its first week the team held a calibration session and wrote the team API above.

The isolation pattern is the Eagle’s pattern, which is a reason for care. Encore planned the return before the departure: the FAQ promised that anyone could go back to their old team after a year, and the plan said in advance that the Resale team would grow and split after month 18, so that its knowledge would spread through the organization.

The four states of a team

Asking every team for “more velocity” treats different problems as one. Larson’s “Staying on the path to high performing teams” (2018) describes four states, each with its own fix. A team falling behind has more work arriving than it can finish: “hire more people until the team moves into treading water.” A team treading water keeps up but cannot reduce its backlog: “add process to consolidate the team’s efforts to finish more things and reduce concurrent work”, which is to say, limit work in progress. A team repaying debt can at last pay down its accumulated problems: “add time.” A team innovating can take on new work: “maintain enough slack in your team’s schedule that the team can build quality into their work.” Figure 9.5 draws the four as a staircase.

Figure 9.5 — The four states of a team, after Larson. Each state has its own fix, and the fix for one state is the wrong medicine for another.

The model is a heuristic whose value is that it makes a manager diagnose before prescribing. At month four, Partner APIs was falling behind, which is why it shed webhook delivery; Inventory was repaying debt on the barcode core and needed protected time for characterization tests (Chapter 2); and the new Resale team was, by design, innovating. Section 10.2 shows how Encore’s quarterly planning uses the four states.

Teams that jell

DeMarco and Lister called a jelled team a group of people so strongly knit that the whole is greater than the sum of the parts, with its own identity and momentum. Such teams cannot be built by decree; management can create the conditions in which they form, and can easily destroy them.

The evidence that stability pays is stronger than Peopleware could offer. Robert Huckman, Bradley Staats and David Upton studied more than 1,000 software project teams at the Indian services company Wipro (Management Science, 2009). Team familiarity, how often a team’s members had worked together before, had a significant positive effect on performance, while years at the firm were not consistently related to it. Encore draws the practical conclusion: it treats the stable team as the unit to invest in, and when it breaks one up it counts a cost that the org chart does not show.

Touring crews know this well. A road crew that has loaded in and out of 100 venues together needs few words at four in the morning: each person knows where the others will be and who will catch the mistake they are about to make, and a pickup crew of equally skilled strangers is slower and more error-prone. The analogy stops at the nature of the work. A crew repeats nearly the same load-in every night, while a software team rarely does the same thing twice, so its familiarity pays off less in rehearsed motions than in knowing whom to ask, whose judgment to trust, and how far a teammate’s “nearly done” is from done.

Change is still inevitable. In 1965 Bruce Tuckman proposed that small groups pass through forming, storming, norming and performing, and in 1977 he and Mary Ann Jensen added adjourning. The model is descriptive, built from a review of studies of mostly therapy and training groups, and deserves modest confidence. Hogan uses it as a reminder that a team returns to something like forming whenever its membership changes, even by one person. So when Orders & Payments lost four engineers to Resale, its manager told planning to expect a slower quarter, before anyone could be surprised by one.

Recap. Encore’s map applies the shared vocabulary to forty teams, with enabling work carried as a second duty and only one true complicated-subsystem team. Cognitive load is used as a budget that forces hand-offs, written team APIs carry interaction modes with real end dates, and reteaming is treated as a practiced capability with its FAQ, its sequence and its calibration session. Team familiarity, which has evidence behind it, makes the stable team the unit of investment, and every change returns a team, briefly, to forming.

Exercise 9.2. For your team, write its team API on one page, including an interaction mode and an end date for each neighboring team. Then run the four cognitive-load questions from this section with your team and name one responsibility you would hand to another team or to the platform.

9.3 Product, Design, and Engineering Together

What forty trios need from engineering leadership

The Products book’s Section 1.3 introduced the product trio, and its Section 1.4 described what leaders must provide so that forty empowered teams pull in one direction: vision, principles, team topology, product strategy and team objectives, following Cagan and Jones. This section takes up the engineering half, which product writing tends to assume and engineering leaders often fail to supply.

It has three parts. The first is the team map of Section 9.2, because a trio can be empowered only over a problem its team owns, and where ownership is unclear a trio spends its weeks negotiating with neighbors over who may change what. The second is an engineering strategy, which Section 9.5 shows how to write, so that a trio choosing between a quick integration and a durable one knows which the organization prefers. The third is principles held by code. Verified Resale’s product principles became the five fairness invariants of Section 1.3, tested in continuous integration; invariant 3, “Organizer caps and rules can only tighten”, is a product principle, a type in the rules engine and a test that fails the build. When leadership turns the principles that must never bend into constraints the system enforces, trios can spend their autonomy on everything else.

Staffing the trios

How many product managers and designers does an organization of 400 engineers need? No evidence supports any particular ratio; surveys circulate, but none measures what a ratio does to outcomes, so Encore’s numbers are reasoned choices. Cagan’s position is a principle: an empowered team has a product manager and a designer of its own, because discovery is their work and cannot be done part-time from elsewhere.

Encore applies the principle where discovery is continuous. It has 40 product managers: 39 across the 41 stream-aligned teams, since four mostly operational teams share two, and one in the platform group, Hana, whose customers are engineers and who was hired in month 2 as the group’s first (Chapter 6). Its 24 designers make design the scarce role. Every fan and organizer team has its own designer, because those teams change what users see every week, while teams with narrow surfaces share: Box Office, Venue Entry and Venue Integrations share one designer, whose time is planned quarterly across the three. Partner APIs has its own trio, as the Products book’s Section 9.4 notes, since a developer’s experience of an API is designed as surely as a fan’s experience of a screen.

When a trio lacks a member, the other two tend to absorb the role silently: a tech lead who also designs does both jobs less well, and a product manager who leads engineering judges feasibility without the knowledge. Encore names the gap in the team’s charter, says who covers it and until when, and treats the cover as temporary.

The engineering manager

Fournier’s The Manager’s Path describes the management ladder as a sequence of different jobs: the tech lead, who still writes code; the manager of people; the manager of managers; and the director, whose work is mostly the organization itself. Each step changes how the week is spent, and each is a place where someone excellent at the previous job can fail. The core of the people manager’s job is well established: one-on-one meetings that belong to the report more than the manager, continuous feedback given close to the event, and, a level up, skip-level meetings with the people two levels down.

Hogan, in Resilient Management, separates three acts. Mentoring is sharing one’s own experience and advice. Coaching is asking questions that help the other person find their own answer. Sponsoring is using one’s standing to put someone forward for an opportunity they would not otherwise get. A manager who only mentors teaches people to wait for advice, and one who never sponsors leaves the quietest good engineers invisible.

Encore’s first managers had none of this vocabulary. By year five it ran a programme for first-time managers: cohorts of six to eight meeting every two weeks for six months, each paired with an experienced manager from another area, with Fournier’s book as the shared text. Two later pieces of machinery matter as much. The performance cycle runs twice a year, and managers calibrate their assessments together so that “exceeds expectations” means the same in Catalog as in Checkout; Larson’s The Engineering Executive’s Primer (2024) and Fournier both treat calibration as what makes reviews fair across teams. And there is succession. Larson’s An Elegant Puzzle asks every leader to know who could take over their role, and Encore asks the same of knowledge. The barcode issuance code, written in year one, is still understood only by Lena, one of the original nine, a truck factor of one, which Section 11.2 shows Encore raising to four.

Writing roles down

When roles are left implicit, their overlap is decided by whoever pushes hardest, and at the top of a product team the overlap is large. Does the product manager, who owns the outcome, decide what goes into a launch, or the tech lead, who knows what is safe? Hogan’s advice is to set expectations in writing, and Fournier’s is to depersonalize decisions by agreeing in advance how they will be made, so that a disagreement about a decision does not become one about a person.

The tool is the responsibility chart: a table listing recurring decisions down one side and roles across the top, marking for each decision who decides, who is consulted and who is informed. RACI (responsible, accountable, consulted, informed) is the best-known variant; whatever the letters, each decision has exactly one person who decides.

Theatre solved this long ago. In a running show every cue is called by one person, the stage manager, from a prompt book that lists each cue and who executes it, because two people acting on the same cue a second apart is how scenery falls on actors. The responsibility chart is a team’s prompt book. The comparison fails in one place: a prompt book is fixed in rehearsal, while a product team meets new kinds of decision as the product changes, so its chart must be reopened when they appear. Figure 9.6 shows the Resale team’s charter.

Figure 9.6 — The Resale team’s responsibility chart. Each decision has one owner, except the launch call, which the Products book’s Section 10.4 makes a joint decision of the trio and the staff engineer against criteria written months earlier; any one of the four can stop a launch alone.

The chart did its most useful work before it was finished. Drafting it, the Resale trio found that the product manager and the tech lead each believed they owned launch scope, and settled it on paper in an hour.

Coaching and collaboration

Cagan and Jones argue that a leader’s main job is coaching: assessing each person’s skills, writing a coaching plan, using the one-on-one for it, and asking people to write narratives of their thinking. It is a prescription from Cagan’s consulting work at the Silicon Valley Product Group, without outcome data, and it gives leaders of forty teams something to do besides deciding on the teams’ behalf.

They also argue that stakeholders such as legal, finance, sales and trust and safety belong inside discovery. The Products book’s Section 1.3 makes the case that these functions shape viability; this chapter adds the working arrangement. Encore’s legal counsel and a trust-and-safety lead joined the Verified Resale trio’s weekly discovery sessions from the first month. Legal’s earliest contribution changed the product. Under the EU’s Digital Services Act (DSA), Encore is an online marketplace for resale and the fans who resell are consumers; the Act’s trader-traceability rules (Article 30) would oblige Encore to vet and identify anyone reselling as a business. That became one more reason for a rule Encore had already chosen, that Verified Resale admits no professional resellers, and it was settled months before any review.

Recap. Engineering leadership’s half of strategic context is a clear team map, a written engineering strategy, and product principles turned into constraints the code holds. Staffing ratios are choices to be reasoned about, gaps in a trio should be named and time-limited, and the engineering manager’s job is a sequence of distinct jobs built on one-on-ones, feedback, calibration and succession. Writing roles down settles overlaps on paper, and stakeholders do the most good inside discovery.

Exercise 9.3. Write the responsibility chart for your team’s leadership roles, with your five most frequent decisions down the side. Show it to every person named in it, separately, and record each cell where their answers disagree.

9.4 Hiring and Onboarding

Hiring as a system

Hiring at 400 engineers is a production system with stages, defects and throughput. Larson’s The Engineering Executive’s Primer gives the elements: a documented process every hiring manager follows; hiring managers who are trained; leveling decided at offer time, from the interviews; funnel metrics that show the stage where good candidates are lost; and a hiring plan tied to the financial plan, so that open roles are a decision about money.

Should a committee outside the hiring team make the final decision? Google’s hiring committees, described by Laszlo Bock in Work Rules! (2015), protect the bar from hiring managers under pressure, at a cost in time and distance from the team. Encore chose a narrower check: two senior engineers from outside the hiring team review the evidence for offers at staff level and above and confirm the level. Below staff, the hiring manager decides, against a written rubric.

Interviews that predict

The evidence on selection is unusually good and mostly ignored. In 1998 Frank Schmidt and John Hunter combined 85 years of studies in a meta-analysis of how well selection methods predict job performance: work samples had a validity of .54, general mental ability tests .51, structured interviews .51 and unstructured interviews .38. In 2022 Paul Sackett and colleagues found that the earlier work had over-corrected for range restriction. Their revised figures are lower by .10 to .20, and the ranking changes: structured interviews come first at .42, then job-knowledge tests at .40, empirically keyed biodata at .38, work samples at .33 and cognitive ability tests at .31. Both are meta-analyses across all jobs, with no special weight on software.

What the revision supports is precise: structure matters more than format. A structured interview gives every candidate the same questions, or the same task, and scores the answers against criteria written in advance. A work sample scored on an interviewer’s impression is an unstructured interview with a laptop; scored against a written rubric, it combines the realism of the task with the consistency the 2022 evidence ranks highest. Peopleware made a related point long before: to hire a juggler, ask to see the juggling, which DeMarco and Lister called an audition.

In 2013 Laszlo Bock, then running Google’s people operations, told The New York Times that brainteasers were “a complete waste of time” and that Google had moved to structured behavioral interviews with a consistent rubric. Encore made the same move in year six, replacing puzzle questions with a 90-minute work sample on a trimmed copy of one of its own services: the candidate extends a small feature, fixes a planted bug and explains a design choice. One criterion of the rubric reads:

criterion: reading-unfamiliar-code
question: "Before changing anything, how did the candidate learn what the code does?"
evidence_to_record: the files opened, the tests run, the questions asked
scores:
  1: edited before reading; could not explain the existing behavior
  2: read the code but missed the test that encodes the planted bug's expected behavior
  3: ran the tests first; explained the behavior; found the bug through a failing test
  4: as 3, and named a risk in the surrounding code the task did not ask about
calibration: two interviewers score independently, then compare before the debrief

The last line matters as much as the scores, because independent scoring keeps the loudest interviewer from setting everyone’s view.

Hiring when candidates use AI

Coding assistants built on artificial intelligence (AI) have changed what a work sample measures, and this is emerging practice. The most detailed public account is Canva’s: its engineering blog announced in June 2025 that it expects backend, machine learning and frontend candidates to use tools such as Copilot, Cursor and Claude in technical interviews, and assesses whether they can explain and defend what they accept. Meta was reported in 2025 to be introducing an AI-enabled coding interview. Neither company has published evidence that the new formats predict performance, and Canva’s early results are self-reported.

Encore’s rule since year nine follows Canva’s reasoning because it matches the job. Assistants are allowed in the work sample, and the rubric weights what an assistant cannot do for the candidate: reading the existing code, judging generated changes, finding the planted bug and explaining the design. The criterion above survived the change unaltered, a fair sign it measured the right thing. Section 5.5 discusses what assistants do to junior engineers’ learning.

Onboarding as a product

Every new engineer is a customer of the engineering system, and their first weeks are its most honest usability test. Treating onboarding as a product means giving it an owner, a defined journey, a measure of success and a backlog driven by that measure. The best-known public precedent is Facebook’s engineering bootcamp, which Andrew Bosworth described in 2009: six weeks in which engineers had real work assigned the first time they opened their laptops, many pushed code to the live site in their first week, senior engineers rotated through as mentors, and at the end each bootcamper chose the team they would join, which gave every team a reason to be one people wanted to join.

Research confirms that most of what newcomers struggle with is social. Andrew Begel and Beth Simon followed new graduates through their first months at Microsoft and found their difficulties lay mostly in communication and collaboration. An Ju and colleagues, also at Microsoft, found three themes in successful onboarding, learning, confidence building and socialization, and found that managers chose first tasks by strategies they used without naming. A buddy, a deliberately chosen first task and introductions to the people a newcomer will depend on are what the evidence recommends.

Medicine has the oldest worked example of designed onboarding. A teaching hospital takes in a cohort of new doctors on a fixed date, gives each a curriculum and a supervisor, and grades their responsibility upward as they show they can carry it. Software can borrow the cohort, the curriculum and the graded responsibility. It differs in our favor: a newcomer’s change in a well-built engineering system is reviewed, tested and can be rolled back before it harms anyone, so a software team can let a new engineer ship in week one, where a hospital waits years before letting a resident operate alone.

Encore’s measure has a public precedent. In 2021 Spotify reported that the time for a new engineer to make their tenth pull request fell from over 60 days during a hiring boom to 20 after its developer portal, Backstage, was in place. The figures are self-reported, in a post promoting Backstage, but the metric is sound because it captures sustained contribution. Encore measures time to first and to tenth merged change, per cohort.

In year nine Encore gave onboarding an owner, Hana, the platform group’s product manager, with the Developer Portal team building its tooling. The curriculum covers the system map, an on-sale explained by someone who has worked one, and the golden path. The buddy is assigned before the start date and never doubled up. The first task is chosen in advance and sized to merge in week one, the onboarding test Section 4.1 sets for the inner loop, made possible by Chapter 6’s golden path. Figure 9.7 shows the cohorts.

Figure 9.7 — Encore’s onboarding cohorts in year nine: median days to a new engineer’s first and tenth merged change, with what changed for each cohort. The first change moved into week one once the environment was ready on day one; the tenth change, which depends on people more than tools, fell more slowly.

The two columns moved at different speeds. Tools fixed the first change, which mostly needs a working environment and a good task. The tenth depends on knowing whom to ask, how the team reviews and where the system’s surprises lie, and it improved only as buddies and curriculum did.

Absorption rate

A team’s absorption rate is the number of new people it can take in over a period before its output falls. It is limited by the stock of experienced people who can teach, by the time a newcomer takes to ramp, and by how far the team’s own work can pause while it teaches.

The oldest statement of the limit is Fred Brooks’s, in The Mythical Man-Month (1975): “adding manpower to a late software project makes it later.” The Architecture book’s Chapter 5 opening teaches the communication arithmetic beneath it; the law adds training time and ramp-up time, which on a late project arrive exactly when there is none to spare. Brooks himself, in the 1995 anniversary edition, called the law an oversimplification, and it is one: more people can help when the work divides cleanly and the newcomers know the domain. As a warning about the general case it has held for half a century.

Larson’s model and Encore’s own figure turned the law into two rules. First, no team is more than a third new at any time, counting anyone who joined Encore less than six months ago, so a team of nine absorbs three newcomers and a fourth waits or goes elsewhere. The threshold is Encore’s choice, with no study behind the exact number; it keeps two experienced engineers for every newcomer, so no buddy is doubled up. Second, Encore hires into teams, never into a pool, so that each offer is checked against a named team’s absorption rate. When Orders & Payments lost four engineers to Resale, it backfilled two in month five and two in month 11, which kept it inside the rule.

Recap. Hiring is a system with a process, trained managers, leveling at offer, funnel metrics and a plan tied to money. The evidence favors structured assessment, and a work sample scored against a written rubric takes the best of both; letting candidates use assistants is emerging practice with public accounts and no validity data yet. Onboarding becomes a product with an owner and a measure, and the absorption rate, with Brooks’s law as its oldest statement, sets how fast any team can grow.

Exercise 9.4. Find the time to first and to tenth merged change for your last five hires. For the slowest of them, identify the step that cost the most days, and decide whether onboarding or the codebase caused it.

9.5 Technical Leadership

Staff-plus roles

An organization of 400 engineers needs technical leadership that does not run through management. Staff-plus engineers are engineers at staff level and above whose scope extends beyond one team. Larson’s Staff Engineer (2021), built from interviews at companies such as Stripe, Slack and Dropbox, describes four archetypes. “The Tech Lead guides the approach and execution of a particular team.” “The Architect is responsible for the direction, quality, and approach within a critical area.” “The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward.” “The Right Hand extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations.” The archetypes come from experience, and their use is to make an organization decide which kinds it needs before it promotes anyone into a title.

Tanya Reilly’s The Staff Engineer’s Path (2022) describes the work in three pillars: big-picture thinking, execution of projects that cross teams, and leveling up the engineers around you. A staff engineer who neglects the third becomes a bottleneck with a senior title, the Eagle’s failure in miniature: one person whose knowledge the organization depends on and cannot reproduce.

Encore has 26 staff-plus engineers. Most are tech leads or architects; a few are solvers attached to no team. For Verified Resale two mattered: the architect for the partner surface, a principal engineer whose area spans Public API, Partner APIs and Embeds & Channels, and the solver lent to the Resale team from Orders & Payments, chosen because the reissue path would cut through the purchase saga she knew best.

Working on what matters

A staff engineer’s time is the scarcest technical resource an organization has, and the commonest way to waste it is to spend it well on the wrong things. Larson names the temptations: snacking, easy work that feels productive; preening, “low-impact, high-visibility work”; and chasing ghosts, a new leader’s “strategy shift that fundamentally misunderstands the challenges at hand.” Against these he recommends existential problems, growing others, editing others’ work so it lands, finishing things, because “we only get value from finishing projects”, and work that “simply won’t happen if you don’t do it.”

Reilly offers a way to find that work in three maps. A locator map shows where you stand and what you can see from there. A topographical map shows the terrain: teams, politics, the rivers that are hard to cross. A treasure map shows where the organization is trying to go and what lies between. She pairs them with a frank account of finite time: a week has room for few large commitments.

The Resale team’s solver drew the topographical map before writing anything. She interviewed someone in each of the 12 teams Verified Resale touches and recorded what each owned, what it feared about the bet and what it would need to say yes. Most of the 23 dependencies in the first quarterly plan ran through Inventory and Partner APIs, and the hardest was a question nobody had asked aloud: who owns reissue?

RFCs and design documents

The Architecture book’s Section 15.5 describes the request for comments (RFC) loop: a short proposal circulated in writing, commented on asynchronously, decided visibly and archived, under a name that goes back to the ARPANET in 1969. An organization of forty teams must add the institutional part: when an RFC is required, who must review it, how long comments stay open and how the process ends.

Two public accounts show how large companies answered. Malte Ubl’s “Design Docs at Google” (2020) describes the design document as the main tool for aligning engineers across a large organization, with sections for context and scope, goals and non-goals, the design, alternatives considered, which he calls one of the most important, and cross-cutting concerns; he is as clear about when not to write one, when the solution is obvious or the document would be only an implementation manual. Gergely Orosz’s account of RFCs at Uber (2018, updated 2022) follows a process that grew from tens of engineers to a couple of thousand, from plans sent to all engineers to per-domain mailing lists with templates, and that met new challenges at a few thousand.

Encore’s process is short. An RFC is required for any change to another team’s interface, data or on-call load, and for any decision that is expensive to reverse. The owners of every team it touches and the area’s architect must review it. Comments stay open for 10 working days, an Encore choice with a public precedent in the Rust project’s “final comment period”, and the author then records the decision and its reasons as an architecture decision record (ADR) in the format of the Architecture book’s Section 1.4. Without the time box, an RFC that touches many teams stays open until someone calls a meeting to close it, and the meeting is the slow, attendance-dependent forum the written process was meant to replace.

The reissue-ownership RFC, written by the Resale team’s solver in month five, opened like this:

# RFC-0412: Who owns reissue?
Status: open for comment until month 5, week 3 (10 working days)
Required reviewers: Inventory, Resale, Venue Entry, Orders & Payments, partner-surface architect
Problem: a resale must revoke the seller's barcode and issue the buyer's as one atomic step.
Non-goals: the partner API shape (Products book, 9.4); payout timing (Billing & Payouts)
Options:
  A. Resale issues and revokes barcodes itself, in its own service
  B. Inventory owns issuance and revocation; Resale calls a `reissue` operation
  C. A shared reissue module both teams change
Recommendation: B. One owner for every barcode; reissue stays idempotent by key (Chapter 2)
Decision record: ADR to follow on close

The ADR, recorded three weeks later, chose option B: the Inventory team owns issuance and revocation, and Resale calls it. Option A would have created a second writer of barcodes, and option C would have made two teams jointly responsible for the oldest and most fragile code in the company. Section 11.1 follows what that decision meant for the code.

Strategy from the bottom up

Where does an engineering strategy come from in an organization too large for anyone to see all of it? Larson’s answer is practical: “To write an engineering strategy, write five design documents, and pull the similarities out.” For a vision, take about five strategies and forecast their implications two years ahead. In The Engineering Executive’s Primer he returns to the method in a section titled “Shouldn’t Strategy Be Bottoms-Up?” and qualifies it himself. It works best for discovering what an organization already believes, with a leader’s judgment where those beliefs conflict.

Richard Rumelt’s kernel, a diagnosis, a guiding policy and coherent actions, is taught in the Products book’s Section 2.1, and engineering strategy uses it too. Encore’s partner-surface architect synthesized a strategy from three year-nine documents: the reissue-ownership RFC, the partner-credentials RFC that Security Engineering and Resale wrote together, and the platform group’s RFC for shared webhook delivery. The diagnosis was that each partner-facing capability had been built by whichever team needed it first, so partners met three conventions. The guiding policy was one owner per partner-facing capability, with partners receiving opaque identifiers and never parsing Encore’s internal formats, the lesson of the barcode-prefix breakage in Chapter 2. The coherent actions were the three RFCs, and a rule that the next partner-facing capability starts from the platform.

Decisions without a board

Most decisions at Encore are made by the team that owns the thing decided, inside the guardrails of the Architecture book’s Section 15.3: scorecards, policy as code and a priced, time-boxed exception path. That book’s Section 5.5 warns against a board that approves every service. A few decisions, though, must be consistent across teams and cannot be checked by a machine, such as the public API’s versioning policy. They need a human forum, which must not become that board.

Larson’s “Scaling technical consistency” (2018) gives the design. A centralized decision group needs a charter, saying what it decides, how decisions reach teams and how much time members give, and a membership, saying how members are chosen, how long they serve and whom they represent. “If it’s six or fewer folks, it’s possible for them to gel into a true team”; “If it’s more than ten, you’ll find it hard to even have a good discussion.” Such groups “tend to be domineering, bottlenecks, status-oriented or inert,” he warns, and membership “often becomes an important signal of organizational status.” An escalation path is Encore’s addition: it reuses the Architecture book’s exception path, so a team overruled by the forum can still proceed, in the open, at its own cost.

Encore’s API council has seven members serving one-year terms: the partner-surface architect as chair, the Public API team’s lead, a staff engineer each from Partner APIs, Web & API Paths and Security Engineering, and two rotating staff engineers from teams that consume partner APIs. Its charter lists what it decides: the versioning and deprecation policy, including 12 months’ notice of breaking changes to partners; the authentication model for new partner scopes, including the rule that each partner gets its own scopes, keys and sandbox; and the style guide’s mandatory rules. It lists as explicitly what it refuses to decide: any individual endpoint, any team’s internal interfaces, and anything a linter can check, which goes to Web & API Paths as policy as code. Those refusals keep the council small. A team that disagrees with it may take the exception path, and Encore expects people to disagree and then commit, in the phrase of Amazon’s leadership principle, without the disagreement counting against them. Years of platform engineering inside a large bank taught me to judge such forums by whether the teams that lose an argument still bring them the next one.

Two ladders

If the only way to earn more is to manage, an organization will turn its best engineers into reluctant managers. The standard answer is a dual ladder: a career ladder whose technical track reaches as high as the management track, in pay and standing. Dual ladders are universal at large technology companies, and the research is more sceptical than the practice. Thomas Allen and Ralph Katz surveyed nearly 1,500 engineers and scientists in nine US organizations in the 1980s and found that, with age, a growing share preferred interesting project work to promotion on either ladder, and they questioned the premise that productive engineers were being forced into management for money.

Both findings shaped the ladder Encore wrote in year five, when its first staff engineer said, reasonably, that she would become a manager if that was the only way to be paid like one. It runs from senior engineer through staff, senior staff and principal, paired level for level with engineering manager, senior manager, director and vice president. Fournier’s chapter on writing a career ladder supplied the method, describing each level by scope and impact; Larson’s promotion packets supplied the practice, a written case assembled with a manager; and sponsorship supplied the rest. A staff promotion requires a sponsor at or above the target level who has seen the work, which makes Hogan’s least practiced act part of the system. And because Allen and Katz were right about what many engineers want, Encore’s staff roles are defined by the problems they own.

Recap. Staff-plus engineers lead without managing, and an organization should decide which archetypes it needs. Their time goes furthest on finished, important work found by mapping the terrain first. RFCs with required reviewers, a time box and an ADR at the end align teams; strategy can be distilled from the documents teams already write; and the few decisions that must be consistent go to a small chartered forum with an explicit list of what it refuses to decide. A technical ladder that reaches as high as management keeps the best engineers engineering.

Exercise 9.5. Take one cross-team decision your organization made this year and trace it: who wrote it down, who could object and for how long, how it ended, and where the reasoning is recorded. Name the step that was missing, and say which forum, if any, should have owned it.

Kata: The Second Shift

Your brief: “Pennant.” Pennant is a software-as-a-service (SaaS) platform for freight forwarders and regional carriers in the EU: it books shipments, tracks them across road, rail and sea, generates customs documents and connects to about 300 carriers through electronic data interchange (EDI) and APIs. It has 1,100 customer companies and processes about 40 million shipment events a month, with a hard peak every autumn as retailers stock up for the holidays. Pennant has 60 engineers in seven teams, and it has just raised a round that funds growth to 250 engineers in two years. Its trouble is the trouble of a company that grew up as one team. Two of its seven teams have three people each. The rate engine, which prices every booking, is understood by one engineer. Architecture is decided in a weekly meeting the chief technology officer chairs, which now has a six-week backlog. Interviews are unstructured conversations with whoever is free. New engineers take about 10 weeks to make their tenth merged change, and the board’s plan assumes 95 hires in the first year, starting next quarter, two months before the autumn peak.

Deliverables:

1. Target team map — Draw Pennant’s teams at 120 and at 250 engineers, with team types, owned services and the interaction mode between each pair of neighboring teams, each collaboration with an end date. Show which teams you will grow and split, and in what order.
2. Stock-and-flow hiring plan — Model hiring, ramping, productive engineers and attrition quarter by quarter for two years. State the absorption rule you will apply and show that the board’s 95 hires either fit inside it or must be reshaped, with the autumn peak marked.
3. Onboarding as a product — Name an owner, a curriculum, a buddy rule and the first-week task, and set targets for time to first and tenth merged change per cohort, with the measure you will use to check them.
4. Interview loop — Design a work sample drawn from Pennant’s own code, with a written rubric of four or five criteria and a rule for candidates’ use of AI assistants, stated as emerging practice.
5. Decision process — Replace the weekly architecture meeting with an RFC process (when required, who reviews, the time box, the ADR) and, if needed, one chartered forum with a written list of what it decides and what it refuses to decide.
6. Leadership roles — Write a responsibility chart for a product team’s leadership and a one-page career ladder with a technical track, and say how the rate engine’s truck factor of one will be raised before the peak.

Rubric:

Where you now stand

You can now read an organization’s growth as stocks and flows, and check a hiring plan against the rate at which teams can absorb people. You can draw a team map with a written API for each team and interaction modes that end, form a new team by a named pattern with its FAQ and calibration, and write roles down before they collide. You can design hiring around structured, rubric-scored evidence, run onboarding as a product with a measure, and give technical leadership a ladder, a decision process and a forum that knows what it will not decide. What this chapter has left aside is time and money: how forty well-designed teams plan a quarter together, how they forecast when work will be done, and how an organization funds long-lived product teams. Those are the questions of Chapter 10.

References

• Tracy Kidder — The Soul of a New Machine. Little, Brown, 1981.
• Evan Ratliff — O, Engineers!. Wired 8.12, December 2000 — free online.
• Tom DeMarco, Timothy Lister — Peopleware: Productive Projects and Teams, 3rd ed.. Addison-Wesley, 2013.
• Will Larson — An Elegant Puzzle: Systems of Engineering Management. Stripe Press, 2019.
• Will Larson — Staff Engineer: Leadership Beyond the Management Track. Self-published, 2021.
• Will Larson — The Engineering Executive’s Primer. O’Reilly, 2024.
• Matthew Skelton, Manuel Pais — Team Topologies, 2nd ed.. IT Revolution, 2025.
• Camille Fournier — The Manager’s Path. O’Reilly, 2017.
• Tanya Reilly — The Staff Engineer’s Path. O’Reilly, 2022.
• Heidi Helfand — Dynamic Reteaming, 2nd ed.. O’Reilly, 2020.
• Lara Hogan — Resilient Management. A Book Apart, 2019.
• Paul R. Sackett, Charlene Zhang, Christopher M. Berry, Filip Lievens — Revisiting Meta-Analytic Estimates of Validity in Personnel Selection. Journal of Applied Psychology 107(11), 2022 — free online.
• Frank L. Schmidt, John E. Hunter — The Validity and Utility of Selection Methods in Personnel Psychology. Psychological Bulletin 124(2), 1998.
• Robert S. Huckman, Bradley R. Staats, David M. Upton — Team Familiarity, Role Experience, and Performance. Management Science 55(1), 2009.
• Malte Ubl — Design Docs at Google. industrialempathy.com, 2020 — free online.
• Marty Cagan, Chris Jones — Empowered: Ordinary People, Extraordinary Products. Wiley, 2020.