PILLAR · BOUNDED

Team Structure Beats Talent: Why Great People Still Fail

Team structure, not talent, is what breaks good teams. The four questions every boundary must answer — and what they cost a real person when a manager gets them wrong.

BY EVAN HICKOK · JULY 16, 2026 · 19 MIN READ · FILED IN TEAM PERFORMANCE

When I took over the department, the program they were working had been red for two years in three dimensions: it was late, over cost, and understaffed.

The staffing issue became mine.

The first day on the job, somebody forwarded me a job interview. I asked who the hiring manager was. They said it was me. A little surprised, I went to the interview — Matt was fresh out of college, sharp, eager. He was more interested in working in the space industry than defence, but we both thought he’d learn a lot and contribute a lot before he jumped. So I hired the kid. A couple of weeks later he drove up to town with his father and his sister, and I took the three of them out for coffee, because I wanted Matt’s family to know this was going to be a warm landing.

He would be the first of thirty-two people I’d hire in the next thirteen months.

I needed someone to help onboard all these new people starting with Matt. I had held one-on-ones with my entire team getting to know everyone and the choice was obvious. It was going to be Steve.

I had been acquainted with Steve for twenty years. We had started in the same rotational development program together — he was a year or two behind me — and I had always wanted to work with him. I was excited we finally had the chance. He had been on this project from jump street. He knew exactly what we were trying to build and exactly how to build it. He was warm. He was welcoming. He was the prototype for the culture I wanted in the department: this is who I want people to emulate.

So I turned him into a cultural ambassador and tasked Steve with onboarding Matt. Within two weeks Matt could articulate the project’s goals and was in the lab on critical system testing, paired with another engineer on Steve’s team named Pete.

Pete was a brilliant engineer who had beaten testicular cancer at twenty-five. The chemo had taken his blond hair that crowned his six foot frame, making his story unavoidable. Anyone who met Pete met resilience, optimism and survival. He and I rode our bikes 300 miles across Massachusetts together every year for cancer research. Pete would raise thirty thousand dollars to my six. Everybody loved that guy and supported the hell out of him.

So Matt was in great hands. Steve had what he needed — a mini-Pete to keep things moving. Stuff was moving.

About two months into the job I was driving to Cape Cod for a weekend and I got a call from a number I didn’t recognize. I answered. It was Steve’s wife whom I had never met.

She helped me understand what the project-status meetings had been missing. Steve was not doing well. In fact, she told me Steve was being absolutely crushed by the project. COVID had sent everyone home, and Steve was a people person — he felt isolated. His young kids were attending school at the same kitchen table he was trying to run his thirty-person team from. She told me I wouldn’t hear from him for sixty days as he had already entered some sort of facility to help with his stress. I set up Steve’s leave-of-absence immediately.

I was quite shaken by this call. I’ve never had someone’s wife call me out of the blue like that. I was worried for his health, for the stability of his family and his two young children, 3 and 6, the same age as my children at the time.

And now I had an IPT lead role to fill.

I learned in my one-on-ones that Steve’s role was originally offered to Tom, who declined. I had learned in my first one-on-one with him is that he believed he was the best IPT lead in the department. I was surprised by this assertion and I tried to prove him wrong in my first two months, but I couldn’t. He was hands down the best. If anyone already on my staff could turn this team around, I thought it’d be him. And I thought his ego would jump at the chance to show his strength.

I gave him a call.

I tried to this huge, visibile opportunity for which I offered him a promotion. But he was resolute: it didn’t matter how much I paid him, and that was because “It doesn’t matter how good the lead is in front of his team. This isn’t a Steve problem. He’s a victim of the team structure. The team itself is designed wrong. Nobody could do this, not even me. Steve may not be as good as me, but his only mistake here was not declining like I did.” I was surprised by this humility, which was not something Tom usually expressed. And I was confused by the partial prognosis.

“What does that mean — the team is designed wrong?” I asked.

He said the original reasons he declined were all still true.

Steve’s team was delivering two major subsystems. Together those two subsystems comprised about seventy percent of the project, taking more than thirty people to execute. The remaining thirty percent was distributed across three other leads, each carrying about ten percent. And when we pulled the thread, we found something that really didn’t sit right with me:

There was no technical reason the two subsystems had to be developed by the same team.

Not “they could be split with effort.” Not “we would save time with a reorg.” No technical reason at all. The architecture of the team did not match the architecture of the system they were developing. We had built a thirty-person team boundary for no good reason. And inside that boundary, a person we all admired was being crushed by the load and his family as collateral damage. A for a load he never should have been asked to carry.

I left feeling like Tom’s intuition had been right two years before any of this. But nobody listened to him, because nobody had the language for what he was seeing. And I left that conversation with more questions than answers. And these questions felt familiar — I had heard them asked before.

How do we set the size of a team? When we have a large body of work, how do we properly build a team of teams? Where do we draw the boundaries of each team? And how do we ensure collaboration between teams when required?

If I was going to point at this problem, I’d have to have some better ideas of solutions. I needed to be able to answer these questions.

The lexicon: bounded

A team is bounded when you can answer four questions about it: who the leader is, who is on it, what it owns, and which other teams it needs to interface with. Bounded is an imperative structural condition of a team — the foundation of any sound team structure. This made so much sense to me. I’d seen so many email distributions and meeting invites miss people simply because the roster was not defined. You just look around and say “Where is Tim?” “Oh, we forgot to invite him,” or “We didn’t think to invite him.” But now I know that’s a sign the roster is ambiguous. That means the team is not bounded.

There were a lot of ICs in my staff of 32, and many of them couldn’t answer what team they were on in our one-on-ones. IPT leads would email them with a task and they’d do it to the best of their ability, usually lacking context of how it fit into the larger thing. I realized that’s another red flag – if you cannot say what team you’re on, there is a Bounded problem. If you cannot say who is on the team you are leading, you have a Bounded problem.

This is the side of the line we work on in this pillar: who, how many, and what they own. The condition next door — Interdependent — is the other side of the same line: how the work crosses team boundaries once those boundaries are drawn. On this side, you draw the boundary. On that side, you design the work that runs across it.

Part of what we’re doing when we draw boundaries is reducing the interactions between people. The architecture compartmentalizes technical complexity and organizational complexity at once.

The Bounded framework

Tom had given me his impression of the problem but, without the technical language or a clear alternative to consider, it was hard for me to communicate with others without just pointing at the person who drew the wrong structure — someone I admired, who had once granted me the stock options that helped me buy my dream home a decade earlier.

So first I had to do considerable research to develop some basic principles. And I found some great resources — a 1968 paper, two American tech companies, and a 19th century French agricultral engineer. Each one names a question every team boundary has to answer. Together they became what I now call the Bounded framework — the four questions behind any team structure.

Conway’s Law

In April 1968, a computer scientist named Melvin Conway published a paper in Datamation called “How Do Committees Invent?”[1] Its central claim has carried his name ever since as “Conway’s Law”: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.” Conway called this homomorphism. The corollary is what Tom was reaching for the day he turned the role down: if you want the system to take a particular shape, draw the team boundary to match that shape first. In other words — the team structure should be aligned with the system architecture.

When we are drawing a system architecture, we are also defining a team structure.

Steve’s team structure failed Conway’s Law in two ways.

False adjacency

Steve’s team was developing an integration broker — a server that takes data from several upstream subsystems, combines it, transforms it, and finally routes it to several downstream consumers — and a KVM, the operator workstation’s keyboard-video-mouse architecture. The integration broker and the KVM have no interaction in the actual system. I call this false adjacency[2]: two subsystems with no shared technical interface get force-fit onto one team.

Conway notes that coordination between teammates is not free:

“Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.”[3]

Mel Conway, How COmmittees Invent

With this false adjacency, we are creating additional coordination burden without value because the effort of these two subsystems does not need to be consolotated into a unified system design. The subsystems may be in the larger system together but they do not have a technical interface between each other.

The coordination burden belonged elsewhere, as we’ll see.

False separation

The KVM Steve’s team was developing didn’t do anything without the keyboard and mouse being selected by an adjacent team. And the keyboard/mouse team selected their hardware and disbanded before it was ever connected to Steve’s KVM. When the two subsystems were connected, they did not work.

Nobody had owned the integration.

Our requirements make that a little harder than a trip to Best Buy, but our team structure made it impossible. This is an embedded system running on single-board computers with a real-time OS. And nobody had been set the task of writing the device drivers which did not become evident until the Keyboard and Mouse had finally been connected to the KVM. So we went to the Software Team and interrupted their work so they could write the device driver. And once we had a device driver we found that the keyboard shortcuts built into our software also trigger hotkeys in the KVM hardware. And then we found the mouse speed was too fast after the KVMs were shipped to sites in multiple countries and we had to ship new KVMs out with upgraded firmware all over. These problems were fatal on a system of this criticality — and since the project was already late and way over budget, the failure was not easily framed as a learning opportunity when we went back to the well for more money and more time on what everyone agreed should be the easiest part of the design: selecting a mouse and a keyboard.

Conway’s Law predicts exactly this. The KVM team and the keyboard/mouse team never talked. And their products did not talk either. The system adopted the communication patterns of the teams. Conway’s homomorphism incarnate.

I call the failure mode false separation: two subsystems that must integrate live under two different teams that never talked.

That wasn’t the only major structural issue with Steve’s team. It was much, much too large. Not for Steve’s skill. For anyone.

Ten people

I found several recommendations for team size of 7–10 in the wild. Jeff Bezos says of Amazon, “We try to create teams that are no larger than can be fed with two pizzas.”[4] And the official Scrum Guide says, “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.”[5]

Bezos and the Scrum Guide both land on the same number — ten — but a number is not a reason, and Scrum falls in and out of favor like the tides. And I work in a world with more consequence than developing the Kindle. I needed something a manager could sink their teeth into: why does the tenth person cost more than they add? I found two answers, written sixty years apart, and it turns out they are the same answer.

The first came from a French agricultural engineer named Maximilien Ringelmann. Sometime before 1913, Ringelmann set out to measure the relative efficiency of horses, oxen, men, and machines at farm work. To measure the men, he had them pull horizontally on a five-meter rope wired to a dynamometer, and recorded the force.[6]

Alone, a man pulled with a mean force of 85.3 kg. You would expect seven men to pull seven times as hard — call it 595 kg. They pulled 455. That is 65.0 kg apiece. Fourteen men managed just 61.4 kg apiece. The more people on the rope, the less each one pulled.

Ringelmann had an explanation: he blamed coordination, not laziness — “the lack of simultaneity of their efforts.” Seven men cannot all hit peak pull in the same instant. He noticed the other cause, in an aside about prisoners turning a flour mill: “the result was mediocre because after only a little while, each man, trusting in his neighbor to furnish the desired effort, contented himself by merely following the movement of the crank, and sometimes even let himself be carried along by it.”[7] But he writes this as a bit of a footnote. He pointed strongly at coordination.

Ringelmann was not a trained scientist, and he never recorded his methods. So in the 1970s a team at the University of Massachusetts rebuilt the experiment properly. Participants — volunteers from an introductory psychology class — pulled on a rope in a standardized stance, tied to a calibrated load cell, with randomized treatment orders and proper rest periods, and a clear cadence of commands to induce a simultaneous effort: take the strain, pull, rest.

In this first study, despite simultaneous effort, real groups on a rope consistently reproduced Ringelmann’s decline almost exactly. One person pulls at 100% of their max. Two, and each pulls at about 91%. Three or more, and it settles near 82%. The returns fall off steeply at first, then flatten — exactly the curve in the figure. They weren’t convinced they had removed the coordination challenge as a cause. Could it be that people were actually pulling less hard just because they knew others were pulling?

FIG. 01 Per-capita pulling force collapses as the group grows — steep from one to three, then nearly flat. The same ceiling the two-pizza rule and the Scrum Guide land on by feel.

So they ran another study. In this one, they only varied whether the subjects thought they were pulling on the rope with a group. They blindfolded each subject under the pretext of “testing visual feedback,” except the others lined up behind the subject were only pretending to pull. All they actually did was make grunting sounds while swaying the rope an inch or two to give the impression they were helping.

But all the time, the test subject was pulling alone. And still the subjects pulled about 15% softer than when they knew they were alone. In the debrief they “laughed with great surprise” on learning no one behind them was actually pulling. That missing 15% could only be motivation. What Ringelmann had glimpsed in his prisoners, the UMass team had now isolated in the lab.[8]

A few years later, Latané, Williams, and Harkins gave the motivation loss a name — social loafing: “the decrease in individual effort when performing in groups as compared to when they perform alone.”[9]

So the motivational tax is real. But so is the coordination tax.

Frederick P. Brooks Jr. — a Harvard PhD who studied under computing pioneer Howard Aiken and is widely credited with coining the term “computer architecture” — managed the development of IBM’s OS/360 and distilled that experience into his 1975 classic, The Mythical Man-Month.

In The Mythical Man-Month, Brooks asks why the Tower of Babel failed and answers, communication. And he shows that coordination cost doesn’t rise with headcount linearly, it explodes geometrically:

“The effort [of coordinating n team members] increases as n(n−1)/2.
Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.”

Dr Frederick P. Brooks Jr. The Mythical Man-Month.[10]

This look like this – watch what happens when we go from three people and three relationships to four people. Add a person and you don’t add a link — you add a link to everyone already there. I go deeper on this in Team Size and the Architecture of Interdependence →.

Bezos says a team should not be larger than can be fed with two pizzas. Steve’s team needed about ten pizzas, and one guy is insisting on anchovies. This team is not just three times too large, it has nine times too many relationships than any team should have. And he was managing this all at the same kitchen table his kids were attending school

10 people

30 people

FIG. 02 Ten people, forty-five relationships. Thirty people, four hundred thirty-five. Same rule — n(n−1)/2 — a very different room to hold in one head.

I brought this data back and it was agreed this should be a team of teams. But, unfortunately, it’s not how the project was proposed and it’s not how the Work Breakdown Structure was created. The program guiding documents cemented the structure. So Steve’s replacement, Christopher, had to wear two hats — one as a leader of leaders, and another that untangled what the leaders below him did into an earned-value system that put everything into a single bucket of tasking and funding.

The DRI and the single-threaded leader

So we know how large each team should be and why. And Mel Conway has shown us to divide the team along the lines of the system architecture. The last question is the one with a human in it: who runs the piece?

Apple ships every project with a name attached: the Directly Responsible Individual.[11] One person; one accountability line; the buck stops here.

Amazon arrived at the same idea: the Single-Threaded Leader — every initiative has exactly one leader who owns that initiative and nothing else.[12]

I just call this a manager. As Intel’s founding CEO Andy Grove put it:[13]

“The output of a manager is the output of the team under his or her supervision or influence.”

— ANDY GROVE · HIGH OUTPUT MANAGEMENT

The DRI and the STL are the same conviction in different vocabularies: one outcome, one owner. Steve was the DRI of two unrelated outcomes. That is a math problem, not a character problem.

The four questions

This is the Bounded framework — not a checklist, but the four questions every team structure has to answer before the work starts:

What does it own? One whole subsystem — not a slice of two. (Conway)
Who does it talk to? Draw the boundary along those interfaces, not against them. (Conway)
How big can it get? Ten or fewer — where the rope flattens and two pizzas stop feeding the room. Past that, you already have two teams. (Ringelmann and Brooks, simplified by Bezos as "two-pizza teams")
Who owns the outcome? One name. If you cannot say it, the boundary is wrong before the work starts. (Apple, Amazon, Grove)

Steve’s team failed all four.

Applying it to Steve’s team

Tom had given me half the diagnosis. The framework gave me the rest.

Steve’s team needed to be changed entirely. We needed to get it right-sized, which meant breaking the false adjacency — hive off the people developing the integration broker into their own team with their own manager.

And we needed to get it correctly structured — which meant breaking the false separation by bringing the keyboard and mouse development, and their associated software drivers, in with the KVM in a single Workstation Team.

And that consolidation buys the new team something the fragments never had: a meaningful common goal. Selecting a keyboard was a task. Selecting a KVM switch was a task. Owning the human input path — from the operator’s hands at the workstation all the way back to the servers, and with a KVM that can give any-function any-where — is a goal with consequence and a clear user. A boundary drawn along the interface doesn’t just make the integration someone’s job; it gives the team a reason to care whether it works.

And once we had things correctly structured, the diminishing returns came into view — we could see we didn’t need thirty people across these two teams at once; we needed twenty. Past a certain size the extra bodies were adding coordination cost faster than they added output — exactly the flattening the UMass team found on the rope. Those ten now-redundant engineers were spread to other teams that needed their talents.

The teams are now right-sized.

THE ARCHITECTURE RULE RETURN 1 / 2

The architecture of the team must match the architecture of the work.

— STATED PLAINLY

Structure it like a pizza shop

The framework tells you where to draw the boundary. The next move is the implementation question — once you have the right boundary, how do the sub-teams work together? The pizza shop answers that.

In a working pizza shop there is a pizza station, a salad station, a pasta station, wait staff, delivery drivers, and a cash register. Each station owns a subsystem of the customer order. The cash register is the integration point — the place where the contributions from the other stations get assembled into one order and handed off to a customer or a driver. The pizza station focuses on perfect pizzas. The salad station focuses on crisp salads. The integration point makes the focus possible.

That pattern scales. The James Webb Space Telescope ran ten thousand people across four continent-scale organizations — each instrument its own subsystem; an Integrated Science Instrument Module mounted all four. The New York and Erie Railroad ran four thousand seven hundred fifteen people across four geographical superintendencies to maintain four hundred thirty-five miles of track — the first organizational chart in human history. The cash register, the Instrument Module, the geographical superintendent. Different scales. Same architectural primitive.

I structure every team as though it’s this pizza shop.

The move that turns a team of thirty into a working team of teams is not the headcount split. It is the deliberate naming of where the work integrates — and the deliberate placement of the integration point inside one team’s ownership.

→ The full case, scaled from one 1997 restaurant to the JWST, is in How to structure your team: Like a pizza shop.

Team structure beats talent

The other thing the framework gives you is a defense against the most common managerial mistake.

Watch six-year-olds play soccer. The ball moves; every child chases it. There is no defense. There is no one running ahead to receive a pass. There is no one in goal. The kids are not failing for lack of effort — they are running the entire game. They are failing because nobody has positioned them.

Now watch a professional soccer team. Same ball, same field. The difference is not raw skill. It is structure — clear roles, coordination, adaptability. Every player has a position and knows when to leave it.

Most teams in trouble are running the kids’ game with professional players. The conversation in the room is “we need to get the right people on the bus,” but the players already on the bus are skilled, experienced, and trying hard. Their results are still bad. The diagnosis is wrong. It is not a people problem. It is a structure problem.

Most organizations don’t fail because of bad people — they fail because of bad structure.

Once the structure is right, the manager’s job shifts. The manager’s work is no longer to do the work — it is to enable the work. To ask, at each layer of the org, what can I do to enable the people below me? How do I make them successful? The answer changes the calendar. The answer changes the meeting agendas. The answer changes what the manager owns.

→ The full case — including the Triple-Loop Learning framework for what enablement actually requires of a manager — is in Why Organizational Structure, Not Talent, Defines Business Success.

The reframe

Come back to Steve.

Steve was not weak. Pete was not disengaged. Matt was not underprepared. Tom was not wrong. The thirty-two people I hired that year were not the wrong thirty-two. Steve’s wife was not over-reacting.

The team boundary was wrong before any of us walked into the room.

That is the reframe. The cast at the top of this essay was not decoration. It was the proof that the failure could not be a character failure — because every character in the story was working. When the structure is wrong, the people inside it run out before the work does. They run out because the people inside it are working.

Teams must be right sized, and we divide and conquor along the lines of the system architecture. When we do not, the cost gets paid by the person who thought they had a great career opportunity but then found themselves in the wrong cell of the org chart.

The practitioner’s guide

Diagnosis — how to tell your team structure is wrong

Run the team through the four lexicon questions. If any of them lands a hesitation, the architecture is wrong.

Who leads. One lead’s scope on the team is more than two times another lead’s scope on the same team. Or someone deeper in the org carries more scope than the person above them. The org chart says one thing; the work says another.

Who is on it. The team, without subdivision, is larger than ten. Or the team roster is not clear. Or — the cheaper tell — ask the ICs what team they are on, and the answer is not the same answer twice.

What it owns. If they cannot say in one sentence what outcome they are responsible for, we may have not defined the boundary correctly. Or if the team is named for a department instead of a product. False adjacency, in both forms.

What it interfaces with. A required interface between two subsystems sits across two teams that have no recurring meeting. Or escalations to resolve cross-team blockers routinely take more than two hops up the org chart. False separation, naming itself.

And one meta-tell that does not fit any single question: the Tom test. Ask the senior IC who turned the team-lead role down why they turned it down. If they have a coherent diagnosis, the diagnosis is real — and they have been carrying it without authority for longer than you have.

Installation — how to redraw a team boundary mid-project

Knowing how to structure a team from scratch is one problem; redrawing a boundary mid-project is a harder one. You cannot create an organization without creating silos — and silos also facilitate focus. So put the silos in the right place (organized by architecture), keep any one team under ten without subdivision, and build the communication and coordination processes between the teams that share a technical interface.

Run the new structure for thirty days with old reporting still recorded in parallel, so the team can find the bugs in the new boundary before you commit. Then commit: declare the old boundary dead, redirect every status meeting, every calendar invite, every deliverable-ownership statement. The boundary is real when the calendar agrees with it.

This was nearly impossible for us to do on R1 (and the follow-on R2, which is currently a dumpster fire as well) because of Earned Value rules. Once the WBS was built, budgets aligned to it, and CAMs assigned, it’s impossible to restructure the work without replanning everything. And if the bad structure is in the proposal, the program managers will have a very difficult time signing up to a cost structure we did not propose…

Navigation without authority — how to be the Tom in someone else’s project

Tom had no power to redesign the team that wasn’t his. He had a clear diagnosis and the willingness to decline the role on its current terms. Both matter.

Have the data — a vague “this feels off” is dismissible; “the seventy-ten-ten-ten split has no technical justification” is not. Decline if you have to — the role is the leverage you have once. Offer the alternative — “I will take this team on the day the integration broker sits on a different team from the workstation cluster.” If the alternative is refused, document the offer and date it. The document becomes the receipt when the structure later fails. And wait. Sometimes the diagnosis only lands after the structure has broken what was already obvious. Tom was two years early.

The manager’s real job

The manager’s real job is to draw the boundary the work asks for — not the boundary the org chart inherited.

On this side of the boundary, you are designing who the work belongs to. On the other side — where Bounded ends and Interdependent begins — you are designing how the work crosses the boundaries you just drew. The two conditions are different problems. Most managers conflate them. Bounded is structural: it fails as a missing or wrong boundary. Interdependent is operational: it fails as a broken handoff or an unforced conversation. → Interdependent pillar — Psychological Safety

Run the Bounded framework — leader, members, owns, interfaces — and a team is Well-Structured when you can answer all four without hesitation, and when the answers are aligned with the work the team has to do. That is what a sound team structure buys you. Get it, and the people inside the team can keep being human to each other. Get it wrong, and even the best people in the room will get crushed by a load that was never theirs to carry alone.

THE ARCHITECTURE RULE RETURN 2 / 2