Technology somehow managed to create an assembly line of complexity where the final product is almost irrelevant, and the only metric for success is whether we made it to the next checkpoint. We've replaced the simple question, "Did we solve the business problem?" with the technical noise of "Did we deliver something by the deadline?"
The industry didn't just get fat with dependencies; it got fat with overhead.
The Birth of the Bloat Team
When did developers become insufficient? When did we decide that one person with a Computer Science degree-trained in systems design, data architecture, and problem decomposition-was no longer enough to manage a piece of software?
We went from the individual artisan to the bloated multi-headed team:
- Business Analyst (BA): To translate the business problem into a specification.
- Project Manager (PM): To track the specification, manage multiple work items, and own the delivery date.
- Multiple Developers: Because the tech stack is now so complex, no single person can hold the context.
- Quality Assurance (QA): To find the bugs we created because we prioritized speed and complexity over clarity.
This didn't happened because projects suddenly got harder, but because they got bigger—by design.
The industry embraced the waterfall and then a bloated interpretation of Agile, transforming the work from a craft into a predictable, multi-layered process. The roles of the BA and PM became crucial not to ensure value, but to manage the friction caused by having so many people and so much complexity.
The Math of Diminishing Returns
The research is clear: team efficiency drops exponentially as team size increases. Communication overhead and friction grow faster than productivity.
A typical optimal team size for complex problems is 5 to 9 people (a two pizza team). But how many large corporate projects actually stick to that? We hire more people to speed up a project, but all we do is add more communication paths, more meeting hours, and more code collisions.
This large, complex team structure is a self-fulfilling prophecy of failure:
- Complexity In, Complexity Out: More people mean more handoffs, more documents, and more meetings—all feeding the technical complexity.
- Focus Shift: The team's collective focus shifts from the external business objective to the internal project objective (managing dependencies, hitting sprints, passing QA).
- The Heap Grows: Every role, from PM to dev, contributes to the endless heap of technical trash because their success is often measured on their process adherence, not the final value.
We Celebrate the Date, Not the Value
This is the most dangerous cultural shift we’ve made. We have conflated Delivery with Success.
- Did we ship on time? Yes! (Cue the champagne and praise.)
- Did the new feature generate new revenue? We'll check the metrics later... maybe.
- Did the new system actually reduce human effort? The users are complaining, but we met the deadline!
When project success is defined by a PM's ability to hit a milestone, everyone gets tunnel vision. The business problem that launched the project—the $10 million in revenue, the 30% reduction in user friction—gets twisted into a set of technical deliverables. We build "something" that fulfills the requirements document, even if the requirements document no longer reflects reality or value.
In this environment, Technical Bloat is not a side effect; it's a shield. The complexity justifies the large team, the large budget, and the elaborate delivery process.
The Plumber vs. The Developer
Contrast our industry with other disciplines that prize efficiency and demonstrable value:
- The Plumber / Electrician: They charge for knowledge, speed, and solving a defined problem. If a plumber fixes a leak in 20 minutes with a single tool, you don't complain; you praise their expertise. They don't bring a BA to define the leak or a PM to track their progress. They solve the problem.
- The Technology Team: We take six months to rewrite a simple legacy system, involving too many people and too many meetings, and then celebrate the "successful delivery" of a system that is slower than the one we replaced. We celebrate the effort, not the outcome.
We measure wrong. We measure inputs (story points, lines of code, time on task) and process outputs (sprint velocity, on-time delivery), ignoring the metric that matters most: Value Added.
We live in a giant machine designed to manufacture complexity, and we patted ourselves on the back every time the machine sputtered out a piece of over-engineered junk on time.
The Way Out: Back to the Business Problem
The next great wave of development will not tolerate this organizational bloat. AI is forcing the issue by asking: Why do we need a 12-person team when two people using AI can architect and ship the essential business solution in a quarter of the time?
We need to return the focus to the Business Problem. If the technology stack and the team structure get in the way of answering that single question, they both deserve to be stripped down to the bare bones.
Our priority must shift from "winning praises on delivery" to "accomplishing real, measurable progress" against a business goal. Only then can we finally dispose of the endless heap of trash we’ve accumulated and call technology.
Top comments (0)