Boundaries are necessary. That’s not the argument.

Every engineering project starts with bounding — what you’re solving, what the solution has to do, what’s out of scope. Without that, you’re not engineering, you’re wandering. The boundary is how you make the problem solvable.

The modern corporation learned the same lesson at scale. Adam Smith’s insight wasn’t complicated: split work into elements, run them in parallel, and you can deliver what no individual craftsman ever could. From Renaissance capital markets to the factory floor to the aerospace prime contractor, that logic held. Boundaries enabled scale.

When I joined the workforce in 1982, the logic was still holding — and you could feel why. I had a notebook and an HP calculator. A shared secretary supported the division manager, and before any report left the building it needed sign-off from both my branch manager and his. Not bureaucratic obstruction — that was the information architecture. Reports were dense, slow, and gatekept because they had to be. Management structure existed in large part to curate that flow — to compress what mattered, pass it up the chain, and keep the organization pointed in the right direction. The stovepipe wasn’t a bug. It was load-bearing.

Between 1982 and 2002 two things happened simultaneously that should have changed the equation. First, information handling exploded. The PC, networks, sensors — generating and moving information became cheap and fast. Second, process culture arrived. The US had watched the Japanese manufacturing renaissance and brought back a set of ideas about quality and process that got bolted onto the existing corporate hierarchy. At exactly the moment when individual engineers could span across an organization and get at information directly, the process culture locked the structure down harder.

The result in many companies: more capability to move information, less permission to use it. The stovepipes stayed. The rationale quietly expired.

I ran three programs across my career that show the delta. At SatCon on the AIPM program — Advanced Integrated Power Module, a DOE/Navy cost-share — I was simultaneously program manager and lead engineer, spanning manufacturing, electrical design, mechanical design, and simulation. We went from concept to demonstrated production-ready modules in three years on a modest budget. That approach, the sub-module test-before-integrate architecture we developed, is now standard inside automotive power electronics. Tesla uses a version of it.

At DRS, working with Allison Transmission on an integrated generator for military vehicles, we built a successful solution and demonstrated it to the Army. General officers asked why they couldn’t have more. It took ten years for the technology to gain traction — not because the engineering was wrong, but because the organizational and procurement structure couldn’t move.

At Wolfspeed, deep stovepipes. Marketing, sales, test engineering, module design, device fabrication — separate organizations, separate priorities, separate permission structures. Getting a new product from concept to release meant handing information off at each boundary and then jawboning it forward, because you couldn’t do their job for them and they had to queue the work against their own priorities. Fifteen products out the door. Every one of them harder than it needed to be.

The stovepipes were there to protect quality. They also stopped momentum.

What’s changed now isn’t the human desire to span boundaries — engineers have always wanted to do that. What’s changed is that the tools exist to actually do it. Companies that have built their information architecture from scratch rather than inheriting it — the Teslas, the newer defense tech firms — have demonstrated what happens when low-level actors have access to the full context of what the organization knows. Engineers and technicians can interrogate data, surface patterns, propose action. The information that used to require a management layer to curate is available directly. The span of control moves down the org chart.

For incumbent organizations with data already siloed, this is genuinely hard. The stovepipes aren’t just structural — they’re also where the institutional knowledge lives, and dismantling them requires executives who are willing to accept that the curation function they’ve been performing can be partially replaced. That’s not a technical problem. It’s a political one.

Christensen’s Innovator’s Dilemma describes what happens to incumbents who don’t solve it. A smaller firm with narrower scope but faster movement finds a niche. The niche gets cheaper and easier to serve. The incumbent can’t see it clearly because their whole architecture is optimized for something else. The niche expands. You know the rest.

The boundary isn’t the problem. Bounding a problem is still part of the engineering job. The question is whether, once the problem is bounded and the work begins, you’re working inside a structure that moves — or one that fills up and waits to overflow into the next pipe.

While many organizations are ‘implementing AI’ most are not working through the changes from first principles and often implementing all or nothing. The ones that don’t get around to making sure they break the stovepipes logically are going to run out of time.

---

This post accompanies the video Why Stovepipe Organizations Stop Working — The Unretired Engineer, April 2026.