The Inefficiencies Were Always There. We Just Looked Away.

I watched a video this week from a former Amazon manager explaining why she quit before the layoffs hit her team. Seven years inside. She watched the company double its headcount between 2019 and 2021. She watched smart engineers spend two-thirds of their time in alignment meetings and political theater. She watched bugs sit open for two hundred days. She quit because she felt she wasn't worth the money the company was paying her, and the company wasn't worth the life she was giving it.

That last sentence has been sitting with me since I heard it.

Not because it was new. Everything she described in that video, I have seen across thirty years in this industry. The doubled headcount that didn't double output. The meetings that produced nothing. The bugs that nobody fixed. The politics that consumed the time that should have gone into building. I saw it as a young engineer at a defense contractor. I saw it leading teams. I saw it from inside companies and from the outside as a consultant. I saw it across industries, across stacks, and across three decades of working in this business.

What was new was that she said it out loud. Most people in this industry have learned not to. The arrangement only works as long as nobody names it.

So I want to name some of it here, because I think the video is part of a larger story that the layoff headlines, the media coverage, and the industry conversation are mostly missing.

The hard truth

The tech sector was oversaturated. Not with unqualified people. The hiring bar at most serious tech companies was high and getting higher. Interviews ran longer. Loops got more rigorous. The companies were hiring brilliant, capable, accomplished people. That was never the problem.

The problem was that brilliant, capable, accomplished people in the wrong structure cancel each other out. You can put ten Einsteins in a room and they will not produce ten times the work. They will argue. They will defend their positions. They will reframe each other's proposals until the original question is unrecognizable. They will hold meetings to align on the meeting that aligned on the previous meeting. I have watched this happen many times. Smart people, good intentions, sophisticated process, no shipped product.

The industry kept hiring because more smart people felt like more capacity. The math was wrong, but the math felt right. And the alternative, admitting that the team was already too big and that the structure itself was the bottleneck, was a conversation no executive had any incentive to start.

This was always going to end. Interest rates would have ended it. A recession would have ended it. AI ended it first, and AI gets the blame, but AI is just the trigger. The structure was already collapsing under its own weight.

The pattern across thirty years

I started in this industry in 1997, fresh out of college, working for a defense contractor on an Army project. My first real meeting accomplished nothing and nobody seemed to mind. Not long after, I joined a small software firm where two of us built and shipped a working travel booking site before the category had a name. Across the decades since, I have led teams, run a company, served as CTO and architect, and been called in to rescue projects that were six months late. Different industries, different stacks, different decades. The pattern has been the same.

Small teams of qualified people, with deliberate roles and a clear answer to the question "what are we building," consistently delivered. Bloated teams almost never did. As headcount grew past a certain size, the probability of delivering the product dropped toward zero. Throwing more people at the problem never fixed it. Throwing more money at the problem never fixed it. The math has been known since Frederick Brooks wrote The Mythical Man-Month in 1975. Adding people to a late project makes it later. The industry kept ignoring the math for fifty years because the system rewarded the appearance of scale, not the reality of it.

Every executive I worked with at scale eventually asked me whether we could hire more people to ship faster. The honest answer was almost always no. More people would not make it faster. More people would make it slower. But the honest answer was not always what the room wanted to hear, and it was not always what the moment allowed. Sometimes I gave it. Sometimes I read the executive across from me, recognized that they wanted reassurance more than truth, and agreed to the hire. The team grew. The project shipped late, or didn't ship, and nobody traced the failure back to the headcount decision. I imagine most managers in this industry were making the same calculation in their own meetings, and the cumulative weight of those decisions is most of how the oversaturation happened.

The other half of the dynamic was that requirements were never clean. Building a bridge has engineering drawings. Building a car has tolerances measured in fractions of millimeters. Software claimed to be engineering and never developed the same kind of clarity. Nobody would buy a TV that needed six months of patches to work, or a car that randomly refused to start one morning a week. We built entire careers around tolerating that exact defect rate in software, and we called it the nature of the medium when it was actually a failure of discipline.

What AI actually changed for me

The reason I am writing this now and not five years ago is that AI changed the conversation I am able to have with customers.

Before AI, asking a customer to fully specify what we were building before we started was almost impossible. The discovery would take weeks. The documentation would take more weeks. By the time we had clean specs, the budget was half spent and the customer was impatient to see code. So we started building with incomplete specs and called it agile. The bugs that resulted were called the nature of software.

Now, with AI in the workflow, the discovery and documentation phase is no longer the bottleneck. We can move from a conversation to a working specification in a fraction of the time it used to take. The customer sees the spec, reacts to it, refines it, and we end up with something concrete before any production code is written. The estimates that come out of this process are honest because the unknowns surface during the spec phase rather than during the build.

For every engagement now, I produce four documents before serious development begins.

Product Definition. What are we building. Not what the platform is. Not what the technology stack is. The actual product, in plain language, with the customer's problem stated clearly and the solution stated clearly. If we cannot write this document, we are not ready to build.

Tech Stack. What we are going to build it with. Languages, frameworks, services, infrastructure choices. Stated explicitly so that nobody three months in is asking why we chose Postgres or whether the front end should have been React.

Roadmap. How we are going to deliver. Phasing, milestones, dependencies. The order in which the work happens and what the customer sees at each stage.

Technical Specification. How we are going to build it. The architectural decisions, the integration points, the data models, the interfaces between services. The level of clarity that physical engineering has always demanded and that software, finally, can produce.

These four documents are not new. I have seen them done well before. When a project manager had the discipline and the budget to produce them in detail, with the time investment they required, the project delivered. Almost without exception. The documents worked. The problem was that they only worked at scale. Producing them properly took weeks, sometimes months, and that level of upfront investment was only economically viable on large engagements. For smaller projects with smaller budgets, the documentation phase was a luxury nobody could afford. Teams shipped without it, and the bugs and missed deadlines and unclear scope were the cost. AI changed the economics. The documentation that used to require a dedicated discovery phase can now be produced in a fraction of the time, at a fraction of the cost. The discipline that was previously reserved for the biggest projects is now available to every engagement.

What this is really about

The inefficiencies were always there. Smaller teams were always faster. Cleaner specs were always better. Bigger orgs almost always produced worse software than the small teams quietly delivering things. We knew all of it. The industry knew all of it. We chose, collectively, not to act on it because the alternative was uncomfortable for everyone.

AI did not invent any of this. AI made it harder to ignore.

The companies cutting headcount right now are not getting more efficient because of AI. They are getting honest about a level of efficiency that was always available to them. The employees being let go are not being replaced by machines. They are being released from arrangements that should have been corrected years ago.

The question, for those of us still building, is not whether we can survive the AI era. It is whether we are willing to do the work that was always available to us. Specify what we are building before we build it. Keep the team small enough to know what each person is doing. Refuse to ship products with chronic defects we would never tolerate from a TV or a car. Treat software like the engineering discipline it has always claimed to be.

The bloat is ending. That is the good news. The hard part is what we choose to put in its place.