Why did one person fix in three days what eight people couldn't?
TL;DR — An eight-person SI project ended with its core issues unsolved. Alone, I fixed them in three days. The secret was not talent: with the tangle of communication paths, diffused responsibility, and decision paralysis gone, only pure problem-solving time remained. The same organizational dynamics stall assessments, migrations, and re-architecture when attempted in-house. What's missing is not skill but an owner.
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 and wrong. Organizational behavior explains those three days better than individual ability does. And the same explanation shows why structural work, such as an assessment review or re-architecture, stalls again and again inside the organization that built the system.
Paths grow quadratically
As Brooks laid out in The Mythical Man-Month, the possible communication paths among n people number n(n-1)/2.1 Connect every pair of eight people and you reach at most 28. No real team uses them all, but the direction is what matters: coordination paths grow quadratically with headcount, and one person has zero. On an SI project, coordinating a problem often takes longer than solving it: meetings, explanations, re-explanations, approvals, ownership debates, reviews. Classic findings from social psychology stack on top.
| Dynamic | Team of eight | Alone |
|---|---|---|
| Communication paths | Up to 28 | 0 |
| Responsibility | "Someone will handle it"2 | "My problem" |
| Individual effort | Diluted (social loafing)3 | No one else to carry it |
| Decisions | Four options, call a meeting | Test the strongest hypothesis first |
| Information | Client → PM → PL → developer, losing detail at every hop | Straight from problem to head |
| Shape of a day | Fragments between meetings, mail, and tickets | An unbroken loop of think, code, test |
None of these is anyone's fault. They are structural costs that appear whenever people assemble. My three days were not long development hours; they were problem-solving time with all of that overhead removed.
Three days still needs more explanation
Zero coordination cost means nothing if you can't solve the problem. Method explains the other half. 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. And three days without meetings meant three days of unbroken focus.
Honesty requires one caveat: this story is no proof that solo always wins. Working alone won because four conditions coincided.
- 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, in large feature builds, long-term maintenance, or quality assurance, teams still win.
Why organizations that build well stall at improving
So far, a familiar war story. It gets interesting when you apply the same dynamics to the next phase of a system's life. Systems move through Build, Operate, and Transform. Development firms are strong at Build. Yet at Transform, at assessment reviews, migrations, and re-architecture, many stall. Not from lack of skill, but because everyone is faithful to their own KPIs.
| Dev partner | Client | |
|---|---|---|
| First priority | The deadline | The launch date |
| Boundary | The contract | The budget |
| End state | Defect closure | Start of operations |
For a dev firm to dig into structural problems, it must question, and sometimes repudiate, its own design. That work sits outside the contract, and as the end nears, the organization's attention shifts from solving problems to closing the project. The client faces the same pull. The budget is spent, the schedule is fixed, the service must open; "launch first" is a rational call. Nobody decides badly, and yet the owner of structural improvement disappears.
Three reasons assessments stall in-house
"Can't our own team run the review?" is a natural thought. It usually hits three walls.
- Objectivity. Evaluate a system you built, and you will defend the existing design and treat symptoms before root causes. This is not a skill problem; it is a cognitive bias that works on everyone.
- The politics of questions. "Why did the structure end up this way?" and "Can this component be removed?" translate, inside an organization, into judgments about people. The questions soften and the discussion stays shallow.
- Time. The ops team lives in today's incidents; the dev team lives in the next sprint. A multi-day effort to re-understand the whole system from scratch finds no room.
Migration stalls for the same reason: you must keep the old system running, build the new one, verify the data, and plan the cut-over, all at once, and to the ops team every bit of it is extra work. Re-architecture goes a step further. It is not fixing code; it re-examines premises, starting from "why does this service exist?", and that takes systems thinking before development experience.
Filling the gap
The position we take, then, is not a replacement for the dev firm. We are a third party that analyzes the system objectively on the client's behalf and designs the improvement path together with the dev firm. The efficiency comes from the same dynamics as before: with no stake in past design decisions, we defend nothing; unbound from sprints and project schedules, we see the whole rather than the parts. We deliberately engineer the very structure that made one person faster than eight.
Our program moves in this order.
- Assessment Review: diagnose the structure, technical debt, operations, and bottlenecks; derive improvement priorities.
- Architecture Review: test whether the current architecture can absorb coming business and technical demands; design the scenarios.
- Migration Strategy: map the risks of moving clouds, platforms, databases, and applications; stage the transition.
- Re-Architecture: redesign structure, not refactor code — service boundaries, data flows, and the operating model included.
- AX: rather than bolting AI on as a feature, redesign processes and system structure to be AI-native.
Judgment
Most projects fail to improve their structure not for lack of skill. Because the dev firm and the client each stay faithful to their own goals, no one remains to re-evaluate the structure objectively and design it for the future. The distance between eight people and three days measured the size of that gap.
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.
References
Footnotes
-
Frederick P. Brooks Jr., The Mythical Man-Month (1975). Group intercommunication paths n(n-1)/2 and Brooks's law. https://en.wikipedia.org/wiki/The_Mythical_Man-Month ↩
-
John M. Darley, Bibb Latané, "Bystander Intervention in Emergencies: Diffusion of Responsibility" (1968). The classic study of diffused responsibility. ↩
-
Bibb Latané, Kipling Williams, Stephen Harkins, "Many Hands Make Light the Work: The Causes and Consequences of Social Loafing" (1979). ↩
