Why did one person fix in three days what eight people couldn't?

An SI project staffed with eight people ended with several core issues unsolved. I took them on alone and fixed them in three days. When I tell this story, the usual response is "skill gap." That reading is convenient but incomplete. Individual ability matters, but so do the coordination structure and conditions for focused work. This lens also helps examine why structural work, such as an assessment review or re-architecture, often loses priority inside the organization that built the system.

Paths grow quadratically

Brooks observed in The Mythical Man-Month that adding people can increase communication costs.¹ If every member connects one-to-one with every other member, n people have n(n-1)/2 possible paths; eight people have at most 28. No real team uses them all, but the number of possible paths can grow quadratically with headcount. On an SI project, coordinating a problem can take longer than solving it: meetings, explanations, re-explanations, approvals, ownership debates, and reviews all add cost. The social-psychology studies below do not prove what caused this project outcome, but they offer useful analogies for interpreting how responsibility and contribution can change inside a team.

These effects are better understood as structural costs that may appear under certain conditions, not as individual failings. My three days were not longer development days; they were problem-solving time with much of the internal coordination overhead removed.

Three days still needs more explanation

Low coordination cost means little without a way to solve the problem. Method is another important part of the explanation. Instead of examining modules in isolation, I traced one flow across users, API, load balancer, database, and cache, and narrowed the candidate causes. Instead of reading every log, I formed the strongest hypothesis and eliminated candidates by experiment. Three days with almost no scheduled meetings also provided longer stretches of focus.

Honesty requires one caveat: this story is no proof that solo always wins. Four conditions made solo work advantageous here.

• The problem was small enough for one person to trace end to end.
• I had sufficient access and authority.
• The problem rewarded deep analysis over parallel work.
• Coordination cost, not technical difficulty, was the bottleneck.

Where parallelism and mutual review matter, such as large feature builds, long-term maintenance, or quality assurance, teams are generally better suited.

Why organizations that build well stall at improving

So far, this is one project's retrospective. For this analysis, divide system work into Build, Operate, and Transform. This is an ownership lens, not a universal lifecycle. In the SI organizations we have seen, contracts and accountability were clear for Build, while Transform work such as assessment reviews, migrations, and re-architecture more often lacked a dedicated owner. This is not only a skill problem; each side's KPIs can compete with structural improvement for priority.

A dev firm may need to re-examine its own design to investigate a structural problem. If that work is outside the contract, it can lose priority as the project approaches closure. The client organization can also choose "launch first" under budget and schedule constraints. Each decision may be rational on its own, yet when those conditions overlap, ownership of structural improvement can become unclear.

Three constraints an in-house assessment can face

"Can't our own team run the review?" is a natural thought. Three constraints are worth checking first.

1. Distance. An internal team knows the design context best. It can also lean toward preserving current choices because they form the starting point. Explicit evaluation criteria and an independent reviewer can help counter that tendency.
2. The politics of questions. "Why did the structure end up this way?" and "Can this component be removed?" can be received as judgments about people. The questions may then soften and the scope of discussion may narrow.
3. Time. The ops team prioritizes today's incidents; the dev team prioritizes the next sprint. A multi-day effort to understand the whole system from scratch can lose the competition for time.

Migration faces similar constraints: the team must keep the old system running, build the new one, verify data, and plan the cut-over at the same time, adding work for operations. Re-architecture goes beyond fixing code and re-examines premises, starting with "why does this service exist?" It requires a systems perspective alongside development experience.

Filling the gap

The position we take, then, is not a replacement for the dev firm. We work with the client to analyze the system at arm's length from past design decisions, then design the improvement path with the dev firm. The opportunity for greater efficiency comes from reserving a clear role and time for the review. As a party outside the original design, we can compare alternatives more easily; when the diagnostic scope sits outside sprint and closure pressure, we can examine the whole as well as the parts. The approach deliberately reduces coordination load and clarifies ownership, the conditions highlighted by the eight-person project.

Our program moves in this order.

1. Assessment Review: diagnose the structure, technical debt, operations, and bottlenecks; derive improvement priorities.
2. Architecture Review: test whether the current architecture can absorb coming business and technical demands; design the scenarios.
3. Migration Strategy: map the risks of moving clouds, platforms, databases, and applications; stage the transition.
4. Re-Architecture: redesign structure, not refactor code — service boundaries, data flows, and the operating model included.
5. AX: go beyond bolting AI on as a feature and redesign processes and system structure to be AI-native. During implementation, use AI PoC production-transition gates to manage release evidence.

Judgment

In many projects we have seen, delayed structural improvement was not explained by technical capability alone. Between the dev partner's goals and the client organization's goals, ownership of re-evaluating the structure and designing the next stage remained unclear. The eight-person and three-day comparison is not a universal law; it is one case showing how problem-solving conditions can change when coordination load falls and ownership becomes explicit.

If you are weighing the journey from system diagnosis through re-architecture to AI transformation, start with AX Consulting; for migrations and infrastructure transitions, see Cloud & Infrastructure. For assessment and phased transformation across legacy code, data, and integrations, see Application Modernization.

References