Trap 4 - The people

Nine women, one month

The program is three months late. The sponsor has an idea, and it sounds like common sense: “Let’s double the team.”

Twenty new people arrive over six weeks. They need laptops, access, onboarding and someone to explain the system to them. That someone is, of course, one of the few people who actually know it. Meetings get longer. Questions multiply. The most experienced engineers stop coding and start explaining.

Three months later, the program is five months late.

Fred Brooks saw this at IBM in the 1960s and wrote it down in The Mythical Man-Month: adding people to a late software project makes it later. His image has stayed with every generation of engineers since: a baby takes nine months, no matter how many women are assigned to it.

Fifty years on, I still see the same decision made in steering committees almost every year. Not because people haven’t read Brooks, but because adding people is the one lever everyone knows how to pull.

People are not capacity

Look at how most programs talk about people. “We need four more FTEs.” “Capacity is short in Q3.” “Can we borrow two developers from the other stream?” The vocabulary says it all: people are counted like units of production, movable and interchangeable.

But a program isn’t built by headcount. It is built by a small number of people who understand the problem, trust each other and know who to ask. That knowledge, trust and context take months to build and minutes to destroy.

The people involved in this trap are rarely careless. Sponsors are under real pressure. Managers are asked to deliver with the people they have. HR processes are built for steady state, not for a program ramping up in three months. Each decision makes local sense. Together, they turn a team into a staffing spreadsheet.

That is the people trap: managing people as capacity to allocate, rather than as teams to build, grow and keep.

The ten faces of the trap

In 25 years, I have seen it take ten shapes, in three families: who joins the program, how they are organized, and how they are led. Most struggling programs show four or five of them.

Who joins

• Nine women, one month. People added late, when the program is already behind. Each newcomer slows down the experts before speeding anything up.
• Staffing by availability. The team is made of whoever was free, not whoever was needed. The program gets the people nobody else asked for, and is then surprised by the results.
• Hiring in a hurry. The ramp-up plan needs thirty people by June. Interviews get shorter, the bar quietly drops, and onboarding becomes “read the wiki.” A bad hire made in a week takes a year to undo.
• Outsourced thinking. The integrator designs, builds and understands the system. The internal team manages the contract. When the contract ends, the knowledge leaves with it, and the company owns a system it can’t explain.

How they are organized

• Conway ignored. Melvin Conway observed in 1968 that systems mirror the communication structure of the teams that build them. Draw the teams one way and the architecture another, and the org chart wins every time.
• The hero. One person knows how the critical system really works, answers every escalation and works every weekend. Everyone admires them. Nobody notices that the program now depends on one person’s health and goodwill.
• People sliced into percentages. Thirty percent on this program, forty on that one, the rest on run. Two managers, three stand-ups, no real team. Each slice pays the full cost of switching context.

How they are led

• Culture change by memo. An agile transformation is announced, values go up on posters, new job titles appear. The budget process, the approval chain and the leaders’ behavior stay exactly the same. People believe what leaders do, not what they say.
• The best engineer becomes a manager. The program loses its strongest engineer and gains a manager with no training, no support and no time. Both jobs suffer, and so does the person.
• Management by pressure. Deadlines are pushed down, mistakes are punished, and questions are seen as resistance. People stop raising problems, stop proposing ideas, and eventually stop caring.

Building a team is like marrying ten people

These ten faces are only the most common. People traps come in a myriad of other shapes, because a team is a set of relationships, not a list of skills.

Think about marriage. Two people who chose each other, share the same values and want the same future still need years to learn to live together. Now imagine marrying ten people at once, chosen by someone else, with the wedding date already set and the separation planned for go-live. That is what a program asks of its team. Ten people make 45 relationships, and every one of them has to work.

Yet we pick team members on CVs and skills grids, and invest almost nothing in making the relationships work. The psychologist Bruce Tuckman described in 1965 how groups move through four stages: forming, storming, norming and, finally, performing. Every reshuffle sends the team back to the start.

A few more faces I have met along the way:

• Culture fit, done badly. Done well, culture fit means shared values: honesty, care for users, ownership. Done badly, it means hiring people who look, think and talk like us. The team feels comfortable, and its blind spots grow. Hire for values fit and culture add, not for clones.
• The wrong mindset for the moment. Explorers who love building from scratch, placed in a program that needs a careful migration. Or guardians of stability, placed in a program that needs to invent. Neither mindset is wrong; it is in the wrong place.
• The forced marriage. Internal staff, two integrators and a group of freelancers under one program badge, each with their own contracts, incentives and loyalties. A partner paid by the day and an employee judged on delivery don’t feel the same deadline.
• Never past storming. People rotate every quarter, so the team spends its whole life getting to know itself and never reaches the performing stage.
• The brilliant jerk. A high performer whose behavior drives others away, tolerated because “we can’t afford to lose them.” The program loses three people instead.
• Local incentives. Each team is rewarded on its own objectives. Nobody is rewarded for the integration, the shared risks or helping a neighbor.
• The team that never met. Spread across sites and time zones, with no moment to build trust in person. Every disagreement becomes a ticket.
• The end-of-program cliff. Six months before go-live, the best people start looking for their next role, because nobody has told them what comes after. The knowledge leaves exactly when it is needed most.
• The moving finish line. The go-live date moves, then moves again: every quarter, sometimes every month, each new date announced with the same conviction as the last. After the first slip, people push harder. By the third, they stop believing any date. They stop sprinting toward the deadline and start pacing themselves for a race with no end. Engagement doesn’t die in one announcement; it erodes a little with every deadline nobody chose and nobody explained. The best people, who need a goal they can actually reach, leave first. (The planning trap covers the cure on the plan side: ranges instead of dates.)

None of these needs a perfect hire to fix. They need someone who treats team building as real work, with time, attention and budget, like any other deliverable: shared rituals from day one, a clear answer to “what happens to me after go-live?”, and the courage to part with people whose behavior breaks the team.

The arithmetic of people

Brooks’s insight rests on simple arithmetic. In a team of $n$ people, the number of possible communication paths is:

Ten people have 45 paths. Twenty have 190. Fifty have 1,225. Work grows with headcount; coordination grows much faster.

The second cost is knowledge. A program’s real know-how isn’t in its documents. It sits in the heads of the people who made the decisions, debugged the incidents and remember why things are the way they are. Every departure takes a piece of it away, and every newcomer needs months before they become fully productive.

The third cost is the one programs notice last: attrition. Good people leave programs that treat them as capacity, and they leave first, because they have options. When they go, they take their knowledge and part of the team’s morale with them. The program then hires replacements in a hurry, and the cycle starts again.

The cruel part: none of this shows up in the budget. It shows up as “productivity issues,” “skills gaps” and “delivery risks,” long after the decisions that caused it.

Early signals

You can feel the people trap long before it shows in the numbers:

• People are discussed in FTEs and percentages, rarely by name.
• The answer to every delay is “we need more people.”
• One name comes up in every escalation.
• Newcomers take more than a month to ship their first change.
• Nobody on the internal team could run the system without the vendor.
• Most people belong to two or three programs at once.
• The transformation has a slogan, but the approval process hasn’t changed.
• New managers were promoted on Friday and managing on Monday, with no training.
• People stopped asking questions in meetings.
• The best people are leaving, and the exit interviews say “opportunity elsewhere.”
• The go-live date has changed three times in a year, and nobody reacts when it changes again.
• Agents produce more changes than the team can review, and review time keeps shrinking.

How to build teams that deliver

The answer isn’t a new HR process. It is to treat the team as the product you build first, and protect it as the program’s most valuable asset.

Staffing and recruitment

1. Staff early, or not at all. Build the core team before the build starts, and keep it stable. If a late program needs help, add a few experts to remove a specific bottleneck, never a crowd.
2. Staff for the work, not from the bench. Name the five or six roles the program can’t succeed without, and fight for the right people in them. The rest can follow.
3. Hire slowly, onboard deliberately. Structured interviews, a realistic work sample and at least two independent opinions. Then a buddy, a ready laptop and access on day one, and a first change in production within the first week or two.
4. Keep the thinking in-house. Partners can build, but internal people must own the architecture, the key decisions and the knowledge. Pair internal engineers with the vendor’s, and write knowledge transfer into the contract, with milestones.

Organization

5. Design teams and architecture together. Shape teams around the system you want, not the org chart you have: the “inverse Conway maneuver” described in Team Topologies. Stable teams that own a capability end to end beat project squads assembled for each release. With agents in the team, decide on purpose who frames the work and who verifies it.
6. Retire the hero, kindly. Thank them, then spread what they know: pairing, rotation on call, written runbooks. Aim for at least two people who can handle every critical system.
7. One person, one main team. At most two assignments per person, and one of them clearly primary. Focus is a management decision, not a personal virtue.

Leadership and culture

8. Change culture through systems and behavior. Culture is what leaders do and what the organization rewards. Change the budget model, the approval chain and the way leaders react to bad news, and the culture follows. Start small and make the first wins visible.
9. Grow managers on purpose. Offer a real technical career path, so the best engineers don’t have to manage to progress. Those who choose management get training, a mentor and regular one-on-ones with their own manager.
10. Build psychological safety. Google’s Project Aristotle found it was the strongest predictor of team effectiveness. Leaders go first: admit mistakes, ask for disagreement, run blameless post-mortems, and never punish the messenger.

And measure team health like delivery: attrition, time to onboard, number of people per critical system and a short, regular pulse survey. What gets measured gets protected.

What to avoid

• Adding a crowd to a late program.
• Lowering the hiring bar to meet a ramp-up date.
• Letting the vendor own the knowledge of your core systems.
• An org chart drawn without looking at the architecture.
• Celebrating heroes instead of fixing the system that needs them.
• Announcing a culture change that leaders don’t live.
• Promoting people into management without preparing them.
• Treating questions and bad news as resistance.
• Announcing a new deadline without saying what changed and what the new date rests on.
• Cutting reviewers and testers because “the agents write the code now.”

The AI twist: smaller teams, new shapes

AI doesn’t only add capacity to a team. It changes what a team is: who does what, how many people it takes, and how the work flows between them. Programs that bolt agents onto last decade’s org chart will fall into the people trap faster than ever.

Roles are compressing

The borders between jobs are dissolving. Product managers prototype working screens. Designers ship front-end code. Engineers write the specification, the tests and the documentation with their agents. In a Figma survey, more than half of respondents said they were taking on tasks outside their usual scope.

The good news is real: fewer roles means fewer handoffs, and the relay race from The waste trap gets shorter. But compression without redesign creates three new faces of the trap:

• Everyone can, nobody owns. When anyone can touch any part of the work, nobody is accountable for its quality, security or accessibility. Shared tasks still need named owners of outcomes.
• Wide but shallow. A generalist with good agents reaches 80% of the answer almost anywhere. The last 20% (performance, security, data, regulation) is where programs fail, and it still needs depth. Keep specialists, and share them across teams as references rather than gates.
• Three jobs, one title. One person now carries the decisions that three roles used to share, with the same title, the same pay and no training. The work gets faster; the person burns out.

From two-pizza teams to sandwich teams

Amazon famously sized its teams to be fed by two pizzas. With agents doing much of the building, the team that delivers a capability can be smaller still, and it takes a new shape. I call it the sandwich team: humans on both sides, agents in the middle.

The idea builds on the “AI sandwich” workflow, where humans frame a task, AI produces, and humans review. The sandwich team applies it to the team itself, and it comes with one rule: the filling can grow, but the bread has to hold it. It goes wrong in three ways:

• Too much filling. Agents produce more changes than the bottom slice can truly verify. Review becomes a rubber stamp, and the risk moves silently to production. (Code review at AI pace covers how to match scrutiny to risk.)
• No bottom bread. Reviewers are the first cut, because “the agents write the code now.” Quality and security then run on hope.
• Thin top bread. Vague intent, fuzzy specs, unstated constraints. Agents don’t resolve ambiguity; they amplify it at machine speed.

Conway’s law applies to the sandwich too: the system will mirror where the humans sit. If nobody sits in the bottom slice, nobody owns production.

What doesn’t change

Brooks’s law applies to agents as well. Ten agents writing code create ten streams of changes to review, integrate and understand. The bottleneck moves from writing to judging, and judging still depends on the few people who truly know the system.

The bottom slice also has a hidden supply problem. Junior engineers learn by doing the simpler work that AI now does instantly. Verifying well takes experience earned by building. If juniors never debug, never struggle with a design, never own a small system, where will the reviewers of 2035 come from? Programs that care about the long term will give juniors real responsibility on purpose, with AI as a tutor rather than a replacement.

And there is real help. AI can shorten onboarding dramatically: a newcomer can question the codebase, the decision records and the runbooks on day one. It can also capture what heroes know, if someone takes the time to ask them.

Programs are people

The best programs I have worked on did not have the biggest teams. They had stable teams that knew each other, leaders who protected them, and enough trust that bad news traveled fast. Every success I am proud of is really a team I am proud of.

So next time someone suggests adding people, ask one gentle question first: who will they be learning from, and what will that person stop doing? The answer usually changes the decision.

What is the best team you have ever been part of, and what made it work? I would genuinely love to hear your story.

All situations described here are composites, drawn from many programs over 25 years.