Ch4 03: How a 160,000-Person Company Learned to Move Like a Startup#

General Motors has roughly 160,000 employees. Its product development process, refined over more than a century, is one of the most sophisticated on the planet. It is also one of the slowest.

That’s not a slam. GM’s process was built to minimize risk at massive scale — and at that job, it’s world-class. Every design decision passes through multiple review gates. Every engineering change gets scrutinized by specialists across dozens of departments. Every component is tested, validated, and re-tested before it gets anywhere near production. The system churns out reliable vehicles. It just takes a very, very long time to do it.

So when GM decided to develop the Hummer EV — an electric truck that would announce the company’s pivot from internal combustion giant to electric vehicle contender — they faced a fork in the road. Run the Hummer through the standard process, which would eat four to five years. Or try something radically different.

They went radical. Josh Tavel got the keys. And the first thing he did was break almost every structural rule in GM’s playbook.

Tavel’s team was small — deliberately, almost provocatively small by GM standards. Instead of the hundreds of engineers that normally staff a major vehicle program, the core squad was a fraction of that headcount. They were co-located, sitting elbow to elbow in the same physical space rather than scattered across GM’s sprawling campus.

And most critically, they had a direct line to the top. GM’s standard development process layered on multiple tiers of management review. Tavel’s team leapfrogged most of them. When they needed a call made, they didn’t draft a proposal that crawled up through five levels of vice presidents. They walked down the hall and talked to the person who could say yes.

The result: the Hummer EV was developed in roughly half the time of a comparable GM vehicle program. Not by working twice as hard — nobody was pulling double shifts. They were working differently, inside a structure that stripped out the overhead normally consuming most of a big organization’s calendar.

What Tavel grasped — and what most large organizations struggle to accept — is that organizational speed is primarily a function of architecture, not effort.

Do the math. If a decision needs sign-off from five management layers, and each layer averages three business days to review and respond, that single decision burns fifteen business days. In a development process with hundreds of decisions, the cumulative drag is staggering. Even if every individual reviewer works hard and replies promptly, the structure itself slaps a massive time tax on everything.

I think of this as the architecture tax — the hidden toll that organizational structure charges every activity passing through it. Every management layer, every required sign-off, every cross-functional review board adds time. Not because the people are slow or lazy, but because the mechanics of shuttling information up and down a hierarchy are inherently time-hungry.

The architecture tax has three components:

Delay tax. Each layer piles on calendar time — the hours spent sitting in someone’s queue, the time burned scheduling a review meeting, the effort sunk into building a slide deck for the next level up.

Fidelity tax. Each layer degrades information quality. A nuanced engineering trade-off becomes a bullet point on a slide. Context vanishes. Subtlety flattens. The executive at the top gets a simplified sketch of reality that may not support the best call.

Risk-aversion tax. Each layer injects conservatism. Middle managers are rarely rewarded for bold bets and routinely punished for failures. The rational move at every level is to hedge, qualify, and delay — which means the organization’s collective appetite for risk is far lower than any individual’s.

A five-layer org doesn’t just decide five times slower than a two-layer org. It decides slower, worse, and more cautiously. The compounding effect of the architecture tax isn’t linear — it’s geometric.

The fix isn’t flattening the entire organization. That’s neither practical nor smart for a company of GM’s scale and complexity. The fix is carving out protected spaces inside the larger body — what I call “special operations” teams — that run on a fundamentally different architecture.

The traits of an effective special ops team are strikingly consistent across industries:

Small. Two to eight people hits the sweet spot. At that size, everyone knows what everyone else is doing. Communication is ambient — it happens through proximity, not through meetings. Coordination cost is nearly zero.

Cross-functional. The team packs every skill needed to execute the mission without leaning on outside departments. Engineering, design, manufacturing, supply chain — whatever the project demands, it’s in-house. External dependencies are the number-one killer of small-team speed.

Direct access. The team reports straight to the highest relevant decision-maker, vaulting over intermediate management. This is the most controversial piece, and the one that triggers the most organizational antibodies. Middle managers understandably feel sidelined by a team that operates outside their span of control. But it’s also the most critical piece, because it zeroes out the architecture tax at its source.

Empowered. The team owns the authority to make decisions within clearly drawn lines — including calls that would normally require multiple approval layers. The three-condition filter from Chapter 2 works well here: if a decision doesn’t risk lives, break laws, or trigger catastrophic loss, the team makes it and reports afterward.

There’s a pushback I hear constantly: “That works for a special project, but you can’t run a whole company that way.” True. An entire organization of autonomous small teams with no coordination mechanisms would be chaos.

But that’s not what I’m suggesting. The special ops model is for specific, high-priority initiatives where speed outweighs process compliance. The rest of the organization can — and should — keep running with the structures and controls that ensure consistency, safety, and scale.

The real insight is that speed and control aren’t global toggles applied uniformly across an organization. They’re dials that should be tuned differently for different types of work. Routine operations need tighter control and can absorb slower tempo. Breakthrough initiatives need more speed and can tolerate looser control.

GM got this with the Hummer EV. They didn’t demolish their existing development process. They built a parallel track — a protected lane where a small crew could move at startup velocity while the mothership kept cruising at enterprise speed.

Guidance#

If you’re inside a large organization and need to move fast on a critical initiative, try this:

1. Assemble a small, cross-functional team. Eight people or fewer. Make sure every capability needed to execute lives inside the team — no external dependencies.

2. Lock in direct access to the decision-maker. This is the non-negotiable. If the team’s calls still have to travel up the regular hierarchy, you’ve gained nothing. The reporting line must be short — ideally one level.

3. Draw the boundaries. The team needs to know where its autonomy ends. Use the three-condition filter: anything that doesn’t risk safety, legality, or catastrophic loss falls within the team’s authority. Everything else escalates.

4. Shield the team from the mothership. Large organizations have powerful immune systems. They will try to pull the small team back into standard process — adding review gates, demanding status decks, dragging the team into cross-functional steering committees. Fight this. The team’s speed depends on its structural independence.

The biggest drag on speed in large organizations isn’t talent, technology, or budget. It’s the architecture through which talent, technology, and budget get channeled. Rewire the architecture, and the same people with the same resources will deliver dramatically different outcomes.

The Hummer EV story has a coda worth noting. In early 2026, Reuters reported that GM took a $6 billion writedown on its EV operations, even as the company insisted it wasn’t pausing development of its next-generation electric trucks. The Hummer’s rapid development proved that a legacy giant can learn to sprint. But sprinting in the wrong direction still costs billions. The Algorithm’s lesson is clear: acceleration is Step Four, not Step One. Question the requirement first. Then run.