It’s October 1944. A P-51 pilot over Europe spots a German Bf 109 fighter on his tail. He shoves the throttle forward, past the stop, and through the safety wire. As the wire snaps, engine power surges from 1,490 to 1,720 horsepower. He races away from danger, but has just a few minutes before the Merlin engine starts eating itself.

That broken wire represents a fundamental engineering reality: nominal systems fail in off-nominal conditions.

The most trustworthy designs don’t just meet the spec, they hold reserve capacity for moments when the spec becomes irrelevant. This reserve isn’t free. Its cost comes in weight, complexity, maintenance, and money. But it’s the difference between a system that survives the unexpected and one that doesn’t.

Three examples — spanning 80 years and three different failure modes — show how high performance systems can be built for the moments when everything goes wrong.

War Emergency Power

In WWII, engine power decided dogfights. More meant a pilot could outmaneuver or outrun the enemy. But what happens when a pilot encounters a threat while already at full throttle? Or stumbles across the enemy’s latest fighter with a bigger engine and higher top speed?

For these situations, American engineers created War Emergency Power.

WEP was a throttle setting beyond 100% of rated power. The throttle interface guarded the activation of this setting. Safety wire across a gate stop physically prevented the throttle lever from advancing. To access WEP, pilots had to sever the wire.

There was symbolism in this action. You were breaking something to get this power.

Boosting power meant cramming more air and fuel into each cylinder. But the challenge was detonation.

In a properly running engine, the spark plug ignites the fuel–air mixture, and a flame front propagates smoothly along the combustion chamber. Detonation occurs when the unburned mixture ahead of the flame front auto-ignites due to excessive heat and pressure.

This causes an extremely rapid pressure rise and shock waves within the cylinder, which can crack pistons and bend connecting rods. Pilots and auto enthusiasts know the tell-tale sound: engine knock.

The simplest way to boost was just opening the throttle wider, cramming more air into cylinders already running hot. This worked, but pushed the engine closer to detonation.

Injecting a water-methanol solution into the supercharger intake offered a clever solution. The water absorbed heat as it evaporated, cooling the intake charge and making it denser. This enabled more oxygen per cylinder. The methanol raised the fuel’s effective octane rating and also provided some cooling. Together, these effects raised the detonation threshold.

The U.S. military continuously developed this approach throughout WWII. By the time the P-51H took flight, WEP boosted power from 1,380 HP to 2,218 HP, an astounding 60% increase.

The Germans did the same with their MW 50 (Methanol Wasser 50) system. It could push a BMW 801 engine from 1,600 HP up past 2,000 HP.

They also fielded the GM-1 (Göring Mischung 1) system for high-altitude operations, where thin air starved engines of oxygen. This system injected liquid nitrous oxide directly into the supercharger intake. As the nitrous oxide decomposed in the heat, it released oxygen, chemically enriching the mixture where the atmosphere couldn’t.

The trade-off was explicit. Activating WEP triggered enhanced inspections and often a complete engine teardown. Technicians pulled the Merlin apart, looking for cracked pistons, scored cylinders, and damaged bearings. Every second of emergency power consumed engine life at a far accelerated rate.

But the designers weren’t trying to build a sustainable system. They were buying pilots a way out. The wire existed so that the cost of using it was clear. But if breaking a wire meant surviving, it was an obvious trade.

Subscribe now

Takeoff Contingency Power

Thirty years later, a similar principle appeared in a very different context. The Concorde carried 100 passengers at Mach 2, powered by four Olympus 593 turbojets. These engines each had a maximum continuous thrust of 28,800 lbf, which generated 736°C exhaust gas. At this power, the engines could run continuously for an unrestricted duration.

As with any aircraft, one of the most dangerous scenarios was losing an engine during takeoff. At this point, the plane was at maximum weight, minimum speed, and had no altitude to trade. With few options, this required a different kind of margin.

The Olympus 593 had two thrust ratings that mattered here: takeoff power and contingency power.

Takeoff power with reheat on (afterburners) generated 37,080 lbf. This was already 28% higher than cruise thrust and drove exhaust gas temperatures to 806°C. Under these conditions, the maximum duration was five minutes.

Contingency power pushed harder still.

This setting existed solely for engine-out scenarios during the takeoff roll. It drove the engines to 38,130 lbf and an exhaust gas temperature of 883 °C. At this pace, the engines had just two and a half minutes before thermal limits became structural limits.

Activation was automatic. When an engine’s N2 — the rotational speed of its high-pressure compressor — fell below 58.6 percent, the system reacted automatically. The takeoff monitor throttled the remaining engines up to contingency power to compensate. The pilots didn’t break a wire. The system detected and responded on its own.

This automation reflected a shift in how engineers thought about off-nominal operations. WEP assumed a pilot making tactical decisions under fire. Concorde’s contingency power assumed a crew managing a crisis with passengers aboard. The cognitive load had to stay low, and the response had to be immediate.

The trade was time-limited by thermal margins. The material selection in the Olympus 593 engines was tailored to handle high temperatures. Yet, at 883°C, the exhaust gas caused many engine parts to approach material limits.

Two and a half minutes were enough to clear the runway, establish a climb, and retract the gear. But they had to be done quickly and deliberately. The system provided immediate survival, not extended comfort.

In Flight Abort

Jumping ahead to modern day, the SpaceX Dragon capsule is the primary ride to space for U.S. astronauts. The vehicle carries two propulsion systems: Draco and SuperDraco. Both use monomethylhydrazine (MMH) and nitrogen tetroxide (NTO), which are hypergolic propellants. They combust on contact, with no spark required, making them highly reliable.

The sixteen Draco thrusters handle orbital maneuvering, with each generating 90 pounds of thrust. They’re designed for long-duration operations: attitude control, orbit adjustments, and deorbit burns.

The SuperDracos exist for a different purpose entirely. Eight engines are built into the capsule’s sidewalls, with each producing 16,000 pounds of thrust. All are oriented facing aft and together generate 128,000 pounds of thrust.

If the Falcon 9 beneath fails, the SuperDracos fire and accelerate Dragon away at about four g’s. The burn lasts roughly five seconds. In this time, the capsule travels nearly a mile, which is enough separation to be survivable. Once clear, Dragon’s trunk separates, the capsule reorients, and parachutes deploy.

Here, the engineering achievement wasn’t just in the engines, it was also in how they integrated into the vehicle.

Traditional launch escape systems on Mercury, Apollo, and Soyuz used solid-fuel towers mounted ahead of the capsule. They worked, but often had to be jettisoned partway through ascent because the tower’s aerodynamic fairing hit limits. This created blackout zones during ascent when the abort system was gone, but the rocket could still fail. In this window, the crew was unprotected.

Dragon’s integrated approach eliminates blackout zones. The SuperDracos are part of the capsule structure, not a jettisoned tower. The abort system remains continuously active from the pad straight through to orbit.

The time scales here are different from anything that came before. WEP gave pilots five minutes of emergency power before the engine needed a teardown. Concorde’s contingency rating allowed 2.5 minutes at elevated thrust. Both assumed human operators would recognize the problem, make a decision, and take action.

SuperDraco operates faster than human cognition. The transient from ignition to full thrust is 100 milliseconds. The system monitors Falcon 9 telemetry and, if parameters exceed limits, automatically fires. The entire chain of fault detection to separation happens faster than a pilot could process something going wrong.

Dragon carries the entire SuperDraco system purely for emergency off-nominal scenarios. At one point, SuperDracos were meant to double as propulsive landing engines. SpaceX dropped that in 2017, though recent filings suggest it may return for contingency landings. But generally, during a good mission, the system is never activated.

The SuperDraco system adds mass, complexity, and cost to every mission. But when you’re sitting on a million pounds of propellant, it’s the only way out.

The Trade

Every off-nominal system is a bet about which components you can afford to lose.

WEP destroyed engines. Concorde’s contingency rating shortened the time between overhauls. Dragon’s SuperDracos add mass to every mission. None of these reserves is free. They represent decisions to accept penalties during normal operation in exchange for capability in extraordinary times.

This is the hardest kind of engineering: paying every day for something you hope never to use.

Such systems are easy to cut. They add cost without adding capability — until the day they’re the only capability that matters. When written down and considered in detail, the value is obvious. Yet in design reviews, someone always asks: do we really need this margin? Every flight where the reserve goes unused looks like evidence that it wasn’t needed.

This works until it doesn’t.

The P-51 pilots, Concorde crews, and Dragon astronauts all know. When the failure cascade starts, reserve capacity is the only margin that matters.

Subscribe now

Photo Credits

• P-51 Throttle Quadrant / WEP Diagram: U.S. Army Air Forces, Pilot Training Manual for the P-51 Mustang (AAF Manual 51-127-5), 1945. Public Domain, via t6harvard.com

• P-51 Mustang: Courtesy of To Fly and Fight / CE “Bud” Anderson (toflyandfight.com)

• Concorde at Mach 2: Adrian Meredith / Royal Air Force, via PetaPixel

• Olympus 593 Engine: Heritage Concorde (heritageconcorde.com)

• SpaceX Draco and SuperDraco: SpaceX, via Spaceflight Now and SpaceNews

• Apollo Launch Escape System: NASA

A cut wire. A flooded connector. A misbehaving device that spams the network. Any one of these can bring down the system.

The best network architectures make failures irrelevant. Critical functions keep running even when components have failed. This essay explores three strategies to make this happen:

1. Traffic Separation: Isolating critical and non-critical systems

2. Redundant Paths: Multiple channels carrying the same data

3. Self Healing Topologies: Networks that route around failures automatically

Combined, these approaches keep a system functioning through conditions that wouldn’t otherwise seem survivable.

Traffic Separation

The simplest network connects everything to everything else. A single bus carries all messages between all nodes. This works well until one component acts up.

Consider a car’s Controller Area Network (CAN) bus. Bosch introduced CAN in 1986 to simplify automotive wiring, and by the mid 1990s, it was standard equipment on most vehicles. The protocol allows electronic modules to communicate without a central computer. Any node can transmit, and an arbitration scheme establishes message priority.

Modern cars can have upwards of fifty control modules transmitting data.

But a single network has a weakness.

A faulty node can monopolize the bus by transmitting continuously, drowning out messages from others. This is known as the babbling idiot failure. One malfunctioning component can silence an entire network.

This can create real risk. If the controller that operates the door locks starts spamming, the brakes might not be able to communicate with the antilock system.

The solution is separation. Don’t put non-critical traffic on the same network as critical traffic.

Modern vehicles use multiple networks, each with a different mission:

• The powertrain network handles the engine and transmission.

• The chassis bus manages steering, brakes, and suspension.

• The body/comfort bus coordinates windows, locks, and seat controls.

• The infotainment network handles audio, video, and phone connectivity, often using MOST (Media Oriented Systems Transport), a protocol designed for high-bandwidth media.

A central gateway routes messages between buses when needed. But if a Bluetooth module goes haywire on the infotainment bus, the powertrain bus keeps running.

Some cars also include a reserve network. If any one network fails, its traffic can failover to the backup. I’ve often heard this called the party bus, where everyone’s invited when things go wrong.

Even More Separation

Aircraft take a different, more separated approach. Starting in the 1970s, ARINC 429 became the standard. Unlike CAN, it is unidirectional. Each bus has exactly one transmitter that can talk to up to twenty receivers. If you need bidirectional communication, you use two buses.

This architecture is deliberately simple. There’s no arbitration because there’s nothing to arbitrate. Only one device can ever transmit. A babbling idiot can only corrupt its own bus, and since each transmitter has a dedicated bus, a failure affects only the receivers on that specific wire.

ARINC 429’s cost was weight. All those dedicated buses added up to significant wiring. The standard remains onboard older aircraft, but newer designs have shifted to approaches such as AFDX, which combine determinism with network efficiency.

Redundant Channels

Separation protects critical functions from non-critical failures. But what about failures within the critical systems themselves?

For safety-critical applications — brakes, steering, fly-by-wire controls — a single bus isn’t enough. The solution is redundancy: run two or more independent channels carrying the same data.

FlexRay, introduced in 2006, was designed specifically for this purpose. Where CAN offers a single shared bus, FlexRay provides dual channels that can operate independently. The protocol was developed to enable “x-by-wire” systems: brake-by-wire, steer-by-wire, throttle-by-wire.

In a FlexRay brake-by-wire system, brake commands could travel on both Channel A and Channel B simultaneously. If Channel A fails — a cut wire, a shorted connector, a dead transceiver — Channel B continues operating. The brake controller receives identical data on both channels during regular operation and continues on the surviving channel after a failure.

The first production vehicle with FlexRay was the 2006 BMW X5, which used it for an adaptive damping system. Today, FlexRay remains common in premium vehicles for safety-critical applications, even as newer protocols emerge.

FlexRay also includes a bus guardian, which is dedicated hardware that monitors each node and disconnects it if it starts transmitting outside its assigned time slots. A faulty node can’t monopolize the bus because the guardian physically prevents it from transmitting.

Military aircraft have used this dual-channel approach for decades, and spacecraft do the same. These systems often go further with cross-strapping, which configures multiple redundant pathways between nodes so a backup link takes over if the primary fails.

Subscribe now

Self-Healing Rings

Dual channels protect against link failures. But if a node dies, everything downstream loses connectivity. Ring topologies can elegantly address this problem, creating self-healing networks that can survive a break in the chain.

Consider a linear four-node network. A break anywhere could sever communications.

Now, imagine four nodes connected in a circle, with data flowing clockwise. If the wire between Node A and Node B breaks, Node A can no longer reach Node B directly. But it can still reach Node B by going the long way around, through Nodes D and C.

A simple ring provides exactly one alternative path. But what if two wires break?

The solution is the dual counter-rotating ring. Two rings run through the same nodes, but data flows in opposite directions, clockwise on the primary ring, counterclockwise on the secondary.

During normal operation, you can use both rings for bandwidth, or keep one in reserve. When a single break occurs, traffic routes around it on either ring. When two breaks occur in different places, the rings wrap at each break point, forming a single loop that still connects all surviving nodes.

Fiber Distributed Data Interface (FDDI) pioneered the dual counter-rotating ring in the 1980s for local area networks. FDDI itself is largely obsolete, but the architecture lives on in telecommunications backbones, electrical grid networks, and automotive systems.

Tying it All Together

Modern aircraft such as the A380 and 787 have adopted AFDX (Avionics Full-Duplex Switched Ethernet), which combines many of the strategies explored above.

• Virtual links: Dedicated logical channels with guaranteed bandwidth and bounded latency, creating the determinism that safety-critical systems demand

• Redundancy: Dual networks with sequence numbering so receivers can detect and discard duplicates, similar to FlexRay’s dual-channel approach

• Traffic policing: Switches enforce bandwidth limits, acting as bus guardians that prevent any device from flooding the network

The result combines the best of both worlds. AFDX gets the wiring simplicity of a multi-transmitter network, while maintaining fault isolation. Switches contain babbling idiots to their local segment. Redundant networks ensure a single cable failure doesn’t bring down the system. And bounded latency guarantees that brake commands arrive when they need to, every time.

It seems straightforward on paper. But it took decades of careful systems engineering to create such an elegant approach.

Looking Ahead

So far, we’ve explored how systems absorb failures to stay nominal. But sometimes nominal isn’t enough, and a system needs to go beyond its design limits to survive an emergency.

Next, we’ll look at how systems can exceed their 100% operating point to overcome extraordinary conditions, sometimes at the cost of the hardware itself.

a sub-discipline of systems engineering that emphasizes the ability of equipment to function without failure.

This framing relegates it to a specialty. A box to check. A task for a dedicated team. But reliability engineering is just engineering.

It’s the entire point.

Complex systems operate with razor-thin margins, under demanding conditions, and for extended durations. They’re also designed under considerable uncertainty. This creates thousands of ways to fail.

Good designs are able to both avoid failure modes and tolerate them. Reliability means the part works. Redundancy means there’s an alternative if it doesn’t. Working these concepts directly into a system’s architecture can make it inherently trustworthy.

This series of As Built essays is about doing just that. We’ll explore a variety of approaches and architectures that enhance system confidence. The end product will be a menu of tried-and-true methods that can be adapted to any design.

Most operational systems carry a myriad of sensors. Some of these are engineering sensors to characterize performance and improve the design. Others are control sensors that the system actually uses to make decisions.

If a control sensor fails, it could end the mission. So we rarely rely on just one.

Are two better than one?

Consider the embarkation door on a cruise ship. It is relatively low on the hull, and passengers board through it at the dock. When the ship is at sea, this door must be sealed to protect from large waves.

The door has a contact switch that gives a binary reading: open or closed. The captain relies on this data to keep the ship safe. But what if the sensor fails?

We could add a second contact switch to achieve dual modular redundancy. On its surface, we've solved the problem—now we have a backup. If one switch completely fails and stops sending data, we could trust the remaining sensor.

But this architecture has limits. But what if one sensor reads open and the other says closed? Which do we believe?

While dual modular redundancy provides a backup if one sensor fails, it doesn’t enable error correction. If the two sensors contradict, the captain faces a difficult situation.

Three voters

By adding a third contact switch, we can accommodate contradiction through majority voting. Each sensor casts a vote: open or closed. A voting apparatus tallies these votes and outputs the majority value.

If two sensors read closed, but one reads open, then the voting system will output that the door is closed. Today, this is typically a small piece of software, but for Boolean values, it can also be created with analog circuits.

This is a triple-modular-redundant system, and it allows us to be one fault tolerant. In other words, one of the three sensors can fail, and we can still function normally.

For our ship door, this arrangement works well. But what if the data streams were more complicated than just open or closed?

Non-Boolean values

Let's consider another part of the ship: the steering system. As the vessel navigates the Pacific, it uses hydraulic rams to turn the rudder. The rudder weighs 100 tons and encounters significant hydrodynamic pressure as it turns. To overcome these loads, the piston rams are powered by hydraulic fluid at 2000 psi.

Unlike the door contact switch, there are two failure modes here: low and high. If the hydraulic pressure is low, the system can’t steer the ship. If the pressure is high, the system bursts.

Therefore, the captain must have an accurate understanding of the hydraulic pressure, which we collect with three redundant pressure sensors.

Our triple modular redundancy voting system works, but requires slightly more logic. Assume we have three pressure sensors. Our algorithm would be:

• First, establish which two sensors are in closer agreement.

• Second, take the average of the two sensors in close agreement.

For non-Boolean values, we need this second averaging step to address the variance between the two sensors that agree. They won’t read the exact same value due to calibrations, sensor drift, and general uncertainty. To achieve precision, we take the average.

Can it be simpler?

The frameworks listed so far achieve single fault tolerance, but require the sensor layer, the voting layer, and, for non-Boolean values, the final averaging action.

We can simplify by taking the median.

Consider the three hydraulic pressure sensors. Instead of voting, we read all three data streams and at each sample point, take the median. The composite median time series is displayed to the ship captain.

The beauty of this arrangement is how it passively handles a variety of fault conditions.

During nominal operation, we'd expect to see three pressure traces, tightly grouped. In this example, Sensor B is in the middle and is therefore reported as the median value.

However, maybe an exhaust leak starts to cause Sensor B to heat up. This results in the sensor drifting upward and taking a 200 psi offset. In this case, the median is Sensor B until it crosses above Sensor A, then Sensor A data is reported as the median. All of this happens automatically and transparently to the ship captain.

This arrangement also accommodates failed sensors. Maybe a big wave rocks the ship and breaks the wires to Sensor B, causing it to drop to 0 psi. The system seamlessly responds to now report Sensor C as the median.

In this setup, we don’t require voting or averaging. We simply always take the median of our three sensors, and in doing so, remain single fault tolerant. The best architectures don't detect failures. They absorb them.

Flagging faults

While the median operating system seamlessly handles failures, the issues still need to be reported to the ship captain. If we’re single fault tolerant and we’ve taken a fault, we can’t take another one.

It can be helpful to act on the median and flag any sensor that deviates from it. In the hydraulic pressure case, perhaps the system flags if any one pressure is more than 50 psi away from the median.

With this insight, the captain can take an action. This might be going down to repair the sensor, operating the ship more cautiously, or even returning to port.

Common mode failures

These setups all protect against one fault. We can architect systems to accommodate multiple faults by adding sensors and logic, but the effort can yield diminishing returns and increased complexity.

Common mode failures are also a consideration. This would be an event that damages more than one sensor. Maybe that exhaust leak in the engine compartment heats all three sensors, causing them to all drift high and trigger a false alarm.

For this reason, sometimes it’s beneficial to separate the sensors, moving them physically apart or routing the wire harnessing along different paths so it’s less likely that all get impacted by the same event.

Tying it all together

The most basic aspect of reliability is getting good data, and I’ve always viewed the triplicated median approach as one of the most elegant ways to do so.

The next part of this series will step up a level from sensors to networks. We’ll look at network redundancy and how to manage failovers when a component hits an issue.

In nearly every case study, we’ll see the same thing. Simplicity always wins—the fewer systems, the fewer possible failures. The simpler the logic, the easier it is to prove every case will work. And that’s the entire point.

Complex hardware systems occupy a unique category of technology development. Think satellites, reactors, autonomous boats, and launch vehicles. Unlike software that ships in sprints or simpler hardware that iterates in months, these systems have multi-year development horizons.

Such extended timelines come with a fundamental problem: the world refuses to stand still while you build.

The market assumptions that justify starting a complex hardware program rarely survive to its completion. Customer needs evolve, emerging technologies present better offerings, and new entrants leverage resources that didn’t exist when you began.

Meanwhile, regulations shift, investor appetite can swing from euphoria to terror (and sometimes back), and public opinion can turn big accomplishments into political liabilities. What looked like a goood fit in year one can be eroded by year five.

The challenge extends beyond just timing.

Hardware programs must maintain alignment across multiple stakeholder groups: customers, regulators, investors, government administrations, the public, and others. This goes beyond product-market fit, to a complete program-market fit. Lose support from any critical stakeholder, particularly around funding milestones, and the program stumbles, regardless of technical merit.

While the market can shift quickly, hardware programs tend to accumulate substantial inertia. Changing course is a process. Teams lock into architectures, supply chains crystallize, and regulatory pathways narrow.

Success requires anticipating not where the market is, but where it will be throughout the course of development. While perfect foresight is impossible, the best programs come close—as the hockey adage goes, skating to where the puck will be.

Multiple Cycles Matter

Consider a six-year development program. Along the way, there might be three key financing milestones. At each, you must demonstrate market alignment and a path to profitability. At year six, the hardware is operational and it’s time to start scaling up actual profits.

Yet, the challenge is that each stakeholder group operates on its own cycle, and they all rarely synchronize.

Customers

First, is our offering relevant? In other words, do customers want to buy what we’re selling? At the start of the project, hopefully the answer to this question is yes. If you waved a magic wand and the product appeared, there would be people waiting to use it.

However, maybe you’ve peered into the future and recognized that the market today doesn’t yet know what it needs. You’re betting that customer need will intensify—or emerge entirely—by the time you deliver.

Or, you’ll forge the fit yourself. Shape market expectations during development, educate customers on problems they don’t yet see, create demand where none exists today.

In the worst case, deep into your development program the offering becomes irrelevant. For example, the best Loran receivers became markedly less useful as GPS become more available (though they could be making a comeback).

Technology Stack

Is your technology stack state-of-the-art? Again, it most likely is at the beginning of the project. But your stack could take so long to develop that newer, more advanced technologies can emerge and maybe even mature faster.

I saw this happen with metallic 3D printed parts. When we started printing, Inconel 718 was the most mature high-performance alloy used for space-grade engine parts. But by the time the engines were developed, GrCop84, a copper alloy, had matured to the state-of-the-art. Just as printable, but higher performance.

We’d optimized our architecture around yesterday’s material.

Subscribe now

Competitors

Do you have a durable advantage over your competitors? This might come in the form of team, technology, relationships, readiness or other moat.

If there are mature incumbents, you likely start with no advantage. You might have a potential edge—speed, technology, or cost structure—but that potential isn’t real yet.

In the best case, this advantage grows throughout your development program, hitting an all time high when you enter the market.

But new entrants that come behind you present a unique challenge: they’re shiny and new.

While you’re in year five—battle scarred from setbacks and delayed by regulatory hurdles—a new competitor launches with fresh funding and zero baggage. They haven’t accomplished much yet, but their unblemished story looks more attractive. Your hard won experience becomes indistinguishable from failure.

The longer you take to develop, the more vulnerable you become to someone starting the same journey with newer tools and a cleaner narrative.

Capital Markets

Is what you’re doing investable? This is a fundamentally different question than whether the technology works, or even if there’s customer demand.

At the most basic level, the potential value must justify the investment required, given total risk exposure. It also must look attractive on a relative basis. If an investor doesn’t invest in your company, but instead in another company doing something else (or similar), can they get a better return for less risk?

Entry point also matters. The price an investor buys at must be sufficiently low to achieve their target return. For early funds, this might be 25x or 50x. At the later stage, maybe 5x-10x. This creates a trap. Raise at too high a valuation early, and the company needs to grow into it before becoming investable again.

Additionally, general market cycles and sentiment matter. If public markets are at local lows when you fundraise, it’s a headwind (depending on the investor you’re targeting). If sentiment for your sector is high, you can ride the tailwind.

Regulatory Framework

Generally, regulatory frameworks are slow moving, if not fully static. This is both good and bad.

If the regulatory environment supports your business model at the onset, you’re in good shape. Unless something drastic happens, you should be okay by the time you come to market. And if something is going to change, you’ll see it coming over an extended period of time.

It’s not uncommon to seek regulatory changes during your development path, but it can add risk. For example, currently, the Nuclear Regulatory Commission takes 6-10 years to certify a new reactor. Their target for microreactors is 1.5-2 years, which is likely a key factor in many nuclear startups’ business models.

Political Will

Separate from regulators, many high profile projects benefit from favorable political will. This can change every four years with different administrations. Projects that take longer than a single presidential term can face real political risk.

The higher profile and politically polarizing an endeavor is, the more care must be taken if the project is going to cross administration cycles. Further, it’s not possible to predict the next administration four years out. At best, insights can start to be drawn one year out from a potential shift.

For example, in the current administration, electric vehicle and renewable energy investments are more challenged than just eighteen months ago.

Public Support

Big projects live in public view. Rocket launches close beaches and roads. Nuclear reactors create safety risks—part perceived and part real. Factories create jobs.

All of these nudge the public’s perception of the program in different ways.

Public support operates as a force multiplier. Strong public backing accelerates permits, attracts talent, and provides political cover. Public opposition does the opposite—every milestone becomes a battle, every setback becomes ammunition, every delay compounds.

Public opinion forms early and hardens fast. A single early incident can define perception for years. Programs must invest in public trust from day one, not as an afterthought when opposition emerges.

The Composite Challenge

All of these alignment profiles combine into a composite curve of program market fit. It’s easiest to consider this qualitatively, as exactly how they combine mathematically isn’t straightforward.

Yet by mapping these cycles together, we can start to predict what the future might look like, when to time critical milestones, and whether we’ll have momentum when our product reaches market.

Moreover, these cycles don’t operate independently. They interact and amplify.

When capital markets turn bearish, investors scrutinize technology risk more harshly. When public opinion sours, political will evaporates. When new competitors emerge with shinier stories, customer excitement wanes. A misalignment in one dimension cascades into others.

The opportunity lies in seeing this clearly. While others react to each cycle independently, the best programs anticipate the interactions, time their moves to catch multiple tailwinds, and build resilience where headwinds are inevitable. They don’t just survive the cycles. They use them.

Subscribe now

I always started with a snowfort. I’d spend hours building a perfect one. I’d turn the snowpile at the end of the driveway into a fortress equipped with tunnels, walls, and hidden snowball stockpiles.

But by the time I was fully ready to fight, my dad had long gone back inside. 

The risks of being unprepared are easy to understand. We all know what that failure mode looks like.

But being overprepared—as I learned every snowfall—can be just as damaging. The risks are just better hidden. 

The trap is that overpreparing feels like making progress. You’re doing lots of work (building the fort), but you’re not advancing toward your goal (having the fight). You can get so caught up in crafting the perfect plan that you miss your chance to act. Worse, you can get stuck building the wrong thing.

Maybe you need a shield, not a fort. But you’ll only find out by getting into the fight

Running a business or hardware program demands momentum. You have to stay in motion, make decisions, and move while the window’s open. 

Early in the company, we began using “snowforting” as a codeword for when we were too deep in planning mode — a quick, shared cue to shift towards execution.

Of course, certain things demand extensive preparation. Its all a balance and sometimes you do need a great fort. 

But frequently, you don’t lose because your fort wasn’t perfect. It’s because you never made it into the fight.

It's natural to focus on the technical challenges: the math, models, and mechanical design. They are the core foundation of our solution. Yet, making that solution reliable, delivering it on a relevant timeframe, and at a competitive cost depends on something different: program management.

Running a strong program can be as tricky as the technical solution itself. Many interdependent pieces move simultaneously, and we must operate with incomplete information over long feedback cycles. There’s path dependency, and small changes cascade into big impacts. This all creates fundamental uncertainty.

Trying to eliminate this uncertainty through brute force—throwing people and resources at the problem—works briefly. But as those who've done it know, it's not sustainable or scalable. Instead, we need a framework that thrives on uncertainty rather than fighting it.

If we had infinite time and resources, none of this would be a problem. For decades, the waterfall approach assumed we did. Activities were serialized, and requirements were fully defined before execution started. This worked during the Cold War, when programs were government-led with unlimited budgets. But the world has shifted.

Modern hardware programs face new realities. Many are privately funded. Markets move faster than development cycles, and capital is selective. Even government programs feel these pressures as threats evolve faster than traditional development can counter.

These conditions demand high speed, high quality, low cost, and small team execution. Yet, achieving all four simultaneously is a significant challenge. Combined with the hardware's inherent uncertainty, teams often resort to brute force.

The solution hides in the problem. Rather than fight uncertainty, spiral development makes it the organizing principle. By treating risk as the primary unit of progress—not schedule or features—spiral development transforms hardware's greatest liability into its engine of improvement. Each loop teaches us what matters and what doesn't, replacing guesswork with evidence.

Subscribe now

Barry Boehm introduced spiral development in 1986 for software programs. He asserted that scope cannot be fully defined at the start of a project, and risk must be incrementally reduced through iterative cycles. The approach proved powerful. Teams studied it, creating an abundance of papers and frameworks to implement it successfully.

When applied to hardware programs, the method has had success, but also bumped into limitations.

The first key issue is that the details of spiral development often aren’t fully explained to the team. This is a pitfall I’ve fallen into and the motivation behind this entire essay.

Without practical guidance on how spiral development will be implemented, confusion ensues. Engineers express concern about moving ahead without precise requirements. Managers see uncoordinated iteration. Hazardous spiral look-alikes emerge, such as multiple waterfalls linked in a circle, or the same work repeated endlessly until solutions emerge or teams burn out.

Compounding the issue, hardware faces unique constraints that software doesn't:

• Physical considerations: Complex machined parts might take weeks to cut on the mill, driven by the physical metal removal rate. Bad weather can bring outdoor operations to a standstill.

• Stakeholder expectations: Customers, regulators, and employees often still expect detailed upfront requirements, well-structured design reviews, predictable milestones, and comprehensive documentation.

• One-way doors: Large purchase orders commit a program to a supplier. Architectural decisions might take years to prove flawed, often discovered only during integration or testing.

While real, these issues are surmountable. To do so, we'll start with Boehm's core spiral concept and overlay hardware-specific constraints, milestones, and artifacts. Next, we'll create a common language for hardware teams to speak about spiral development.

The playbook we create will be most applicable for programs that are mission oriented, high performance, cross domain, safety critical and highly regulated—for example, satellites, reactors, ships and similar systems where the stakes justify the rigor. However, elements can be adapted to any program.

The spiral map

Spiral development needs a visual framework, and the spiral map provides it.

Our path starts near the center of the spiral at the Project Kickoff Review (PKR). We move clockwise and outward through four different quadrants:

• Scoping (upper right): Define what we're building and why.

• Actualization (lower right): Transform ideas into physical reality.

• Confidence Building (lower left): Systematically reduce risk through analysis and testing.

• Documentation (upper left): Capture decisions, enable reviews, and facilitate handoffs.

As we move around the spiral, the primary goal of each revolution is to get us to the next one. Each lap has clear goals that progressively increase the program's maturity. Formal reviews serve as checkpoints that define the start and end of each revolution:

• Project Kickoff Review (PKR): Initiates the program, introduces the problem space, organizes the team, and establishes a preliminary plan.

• Conceptual Design Review (CoDR): Reaffirms a refined understanding of the problem, reviews early derisking work, and presents multiple conceptual solutions for evaluation.

• Preliminary Design Review (PDR): Examines detailed engineering, including mechanical and electrical design, system sizing, and analysis. Complex projects often have tiered PDRs to review subsystems. PDRs are the workhorse of spiral development.

• Critical Design Review (CDR): Validates the design in a near-final state after significant iteration, confidence, and independent review.

• Initial Operating Capability Review (IOCR): Certifies the completed system and concludes development, marking the transition to initial operating capability. This often overlooked review appropriately concludes the development phase of the program.

Our illustration shows just one pass through each level, but it’s common to take multiple passes. We may discover issues during testing or modify the design after the PDR. In these instances, we repeat laps around the spiral, conducting a second or third delta-PDR until we're ready to proceed.

Key elements

To illustrate the spiral approach in action, we’ll zoom in on ten key elements. The first half of these focuses on rapidly shaping the project in its early phases, while the second half increases rigor as we approach field deployment.

This is just a select list that serves to illustrate the philosophy. We deliberately stop short of prescribing every detail. Ultimately, each program must adapt the spiral to its specific needs. Taking some elements and leaving others. This essay presents plans for framing a house, but the particular color of the interior wall paint is up to the program runner.

1. Early scope

Programs begin with a simple directive.

We need a new isolation valve for an electric tugboat.

That's enough to kick things off and assign an owner. But the job isn't to immediately start engineering. It's to scope.

Begin by developing a comprehensive understanding of the big picture. Take an outside perspective and question why this hardware matters and how it fits into the world.

• Understand the system: What does this valve do? Why is it needed? What happens if it fails? Map all interfaces, upstream and downstream.

• Validate the prompt: Will a new design actually solve the problem? Are we treating symptoms or the root cause? Sometimes the problem could be solved procedurally instead of with hardware.

• Consider alternatives: Could we modify existing components? Find an off-the-shelf solution? Address it operationally? Even if we proceed as planned, exploring alternatives sharpens our understanding.

This early scoping work establishes the foundation for everything that follows.

2. Requirements and constraints

Understanding the requirements comes next, but flexibility is important at the very beginning of the program.

The valve must open within 50 milliseconds after a command while the ship is underway.

This example illustrates two common missteps. First, preliminary performance requirements often default to theoretical maximums without considering cost, reliability, or actual operational needs. In other words, since we're not sure what we need, we set the requirement aggressively.

Second, the requirement focuses on the primary operation while overlooking other critical states. Hardware often operates, or at least exists, in many different states. The valve might be transported to the ship by train. The shock loads from train cars colliding during coupling could exceed anything seen at sea. These requirements often drive the design as much as the primary ones.

Instead of listing every requirement at this point, map out all the states and environments the hardware will experience. This creates a framework we can fill in as we gain more information, ensuring we design for the complete lifecycle.

Immediately adjacent to requirements are constraints, which can be both hard and soft. Hard constraints come from physical limitations, such as interface geometries, mass budgets, and vibration or radiation environments.

The valve must be less than 6 inches wide to fit on the engine.

Regulatory regimes also impose hard constraints.

The valve must be one fault tolerant to meet the Coast Guard's safety criteria.

Meet with regulators early to develop a clear understanding of the frameworks and to what extent they're tailorable. They often shape how we structure the entire program, and we need early visibility into the processes.

Soft constraints reflect operational realities and organizational preferences. To start, consider the hardware operations. Who builds it and with what tools? Will it be serviced in the field during winter? If so, will the technicians be wearing heavy gloves?

The valve will be serviced by the ship's crew, who have basic mechanical training.

Institutional preferences matter just as much, and often come from difficult lessons learned. The team might favor in-house builds over COTS solutions, or there could be legacy vendor relationships to honor. Scar tissue from previous issues is also always a significant factor.

The team avoids Philips-head screws after a stripped head turned a two-hour maintenance operation into a two-day fiasco.

3. Architecture and supply chain

Architecture and supply chain decisions can be one-way doors. These choices have a high degree of path dependency and can be difficult to change in the future.

The valve actuation architecture can be electronic, pneumatic, or hydraulic.

Each architecture has different benefits and drawbacks. Pneumatic systems need compressed gas infrastructure. Hydraulics requires fluid pumping systems. Electronic architectures rely on reliable power and control circuits. Once chosen, the architecture drives countless downstream decisions, including which suppliers can support it.

There was only one hydraulic valve vendor, but many pneumatic valve vendors. Going pneumatic eliminated sole-source risk.

Look deeper than just primary vendors. What's their supply chain look like? Do they have sufficient access to raw materials? Is their equipment specialized or commodity? What’s their capacity, and how easy is it to increase? Map the entire chain from raw materials to finished parts, asking these questions along the way.

Vendor visits are particularly powerful. Watch the actual processes. Talk with machinists and shop managers. Show them sketches and they'll spot manufacturing challenges immediately. In these discussions, spend time on two key future scenarios. First, what are the ways in which the supply chain can be disrupted? Second, how quickly can production scale, and what are the limits? Expect disruptions and ramp-ups to both present at some point, and have plans for each scenario.

The valve body has a twelve-week lead time but a low unit cost. We'll hold three ship sets in inventory to buffer disruptions and enable quick scaling.

4. Seeing is believing

Hardware teams that don't see the same system don't build the same system. Maintain up-to-date system visuals accessible to everyone in the program. These should convey both how the system looks and how it operates.

Start this practice early. As programs progress, design work concentrates in CAD models that only a few engineers see daily. Without deliberate effort, technicians, program managers, and even other engineers lose sight of the latest and greatest design details.

Consider this canal lock system from 1800. One page of illustrations conveys both the mechanism and its operation. This type of visual becomes the program's North Star—a shared reference that keeps everyone aligned.

5. Street fighting math

Before firing up simulation software, use Street Fighting Math, MIT Professor Sanjoy Mahajan's toolkit for rapid estimation. The linked text and its examples are worth a read, and key elements include:

• Dimensional analysis to infer relationships between quantities and approximate solutions.

• Boundary cases to expose what we expect to happen at the extremes of the operating envelope.

• Successive approximation to make a rough estimate and refine it step by step.

• Reasoning by analogy to relate an unfamiliar problem to something we know well.

• Picture proofs to use diagrams to reason through a complex analysis visually.

Beyond delivering early insights, this method helps us to develop a sense of the problem and its sensitivities. If we jump straight to a detailed simulation, we bypass the critical step of refining our intuition. This can be problematic when larger models fail to perform as expected.

When the valve opens instantly, what does the pressure spike to? When it creeps open over minutes, how does flow establish? Sketch both cases before modeling.

6. Boxy monsters

Boxy monsters are my favorite. These are hardware prototypes designed for rapid manufacturing and iteration. They're usually ugly and heavy, but deliver high impact insights by getting us into test quickly.

They're not mockups. The key parts of the system being validated need precision and full engineering attention. But everything else is optimized for simple manufacturing and ease of future modification. When changes are identified during the test, the boxy monster can be retrofitted on the fly without needing to make a new one from scratch.

Our first valve prototype uses a boxy aluminum housing that any shop can machine in a day. But the internal flow passages and sealing surfaces are production quality.

Even with non-final geometry, these prototypes provide crucial build experience. How do parts fit? What tools do technicians need? Does the test infrastructure work? This knowledge feeds directly into production design and work instructions.

The best boxy monsters are built to be rebuilt. They're not pretty, but they derisk the program faster than any other investment.

7. Independent review

Programs develop blind spots, and deviation becomes normal. Problems hide in plain sight. An Independent Review Team (IRT) breaks this cycle by bringing fresh eyes and hard questions with deep and relevant experience.

The valve IRT: two retired valve designers who've seen every failure mode, one former regulator who knows what matters most, and the Head of Engine Maintenance who runs field repair operations daily.

A strong IRT stays engaged throughout, not just at milestones. They can embed with the team to tackle specific challenges or conduct formal reviews at natural inflection points. Even preparing for their questions raises the bar. Teams find and fix issues rather than defend them.

At ABL, we conducted a multi-day Independent Review Board after our first launch failed. This was a company-wide event, held at an off-site conference center. Ten external experts, including customer representatives, spent three days dissecting decisions and designs.

The process helped us address the specific failure mode, as well as a variety of proximal issues. It surfaced a variety of other improvements and drove transparency into the program. It was a process I wish we'd started years prior.

8. First article build

The first article build marks a critical transition from prototype to operational hardware. This isn't a boxy monster anymore. It's fully engineered hardware that closely resembles production units. Treat this build with production-level rigor, as it becomes the template for all subsequent builds.

• Write comprehensive work instructions before starting, but plan for significant updates during and after the build, as assembly sequences are refined.

• Perform complete acceptance testing on the unit, subjecting it to the same standards that production hardware must pass. This validates the design, as well as our test procedures and infrastructure.

• Document everything with copious notes, photos, and videos throughout the build process. Record assembly sequences, tool requirements, fit-up issues, and technician feedback.

Most importantly, finish the build. When parts don't fit or features are missing, find temporary workarounds. Document the issues, but keep going. It's critical to complete all operations; otherwise, problems hide until the next unit is built.

The valve cap was too short to fit on the body, so we machined temporary spacers to complete the first article build.

9. Development, confidence, and qualification testing

Testing is the ultimate confidence builder, but not all tests are equal. Success requires deliberate choices about what we're testing and why.

First, think about configuration. Some tests characterize specific phenomena on simplified test articles. Others qualify complete hardware in exact flight configuration (test-like-you-fly, in aerospace terms).

To measure valve timing, we built a test rig with just the internal poppet and sensors—no need for the whole assembly.

Next, consider the overall test objective. Some tests validate the overall design (i.e. qualification). Other tests verify that a specific unit is healthy, which is essentially a screen for workmanship or other issues (i.e. acceptance testing).

With our configuration and objective set, we need to consider our approach. I tend to think about this in two ways: spear fishing and casting a net.

• Spear fishing targets known objectives—validating seal integrity, confirming pressure ratings, and measuring actuation speed. We test specific requirements and previously identified risks.

• Casting a net hunts for all possible problems, known and unknown, through broad environmental tests, extended duration runs, and extreme edge cases. This is intended to find the failure modes we didn't anticipate—the unknown unknown mission killers.

Finally, decide whether to validate or destroy. Validation tests to analytical limits while preserving hardware. Destruction tests push beyond predicted failure points to find actual physical limits.

Analysis predicted the valve would burst at 3000 psi. We tested one unit to 2500 psi, and it survived. We pushed another until it failed at 3200 psi, indicating about 200 psi of conservatism in our analysis.

These considerations combine to create three main categories of tests.

Development testing characterizes specific behavior and targets particular risks. It's inherently spear fishing. The goal is to gather specific information that we can use to refine the design and inform decisions on the next spiral cycle. Does the actuation force match our calculations? How does seal performance degrade with temperature? What are the actual frequency response characteristics? Often, the test plan evolves as results reveal where to focus.

Confidence testing casts wide nets using complete systems. The hardware should be in near-final configuration so we're building confidence in something relevant. Push environmental limits, run extended durations, and test multiple units for variation. Destroy some units to find true margins. Keep one life leader unit available for future testing. This pseudo-qualification campaign builds internal confidence before official testing.

Qualification testing is the official run-for-record campaign to meet internal standards and regulatory requirements. Test articles must be in the exact production configuration. Plan for multiple units, again keeping one as a life leader for delta qualification if design changes emerge. If confidence testing was done well, qualification should feel routine. We should be verifying that the design works as intended and documenting this proof, rather than discovering new failure modes.

10. Documentation artifacts

Good documentation is the institutional memory that enables spiral development. Unlike in waterfall approaches, where documentation captures final decisions, spiral artifacts must evolve continuously while maintaining traceability.

Effective documentation falls into four essential categories:

• Work completed: Hardware history logs, test reports, failure analyses, lessons learned

• Technical state-of-affairs: Active risks, open issues, current designs, bills of materials

• Program state-of-affairs: Inventory levels, material planning, unit costs, build status

• Future plans: Goals, schedules, staffing, budgets, resource allocation

Implementation varies by program, but the principle remains constant: documentation should serve the program, not bureaucracy. Each artifact must enable better decisions, faster iteration, or reduced risk. If it doesn't actively support spiral development, eliminate or simplify it.

Select strategies

Along the spiral path, hardware programs encounter predictable challenges. Teams struggle with incomplete information, evolving requirements, and unexpected setbacks. These select strategies help to navigate such recurring situations.

1. Make the best decision we can

Decisions can't wait for perfect information. We'll never know everything—the supplier's actual lead time, the exact vibration loads, or how regulatory frameworks will evolve.

At each decision point, make the best decision we can with the information on hand. Document reasoning—what we knew, what we assumed, and what remained uncertain. When new information emerges, this record enables intelligent updates. The spiral framework expects this. We'll make thousands of decisions as we progress, with opportunities to revisit them on future laps.

2. Eyes inward

Previous work becomes stale without revalidation. On each revolution, look inward to verify earlier work and ensure it remains applicable in light of new knowledge. This isn't about second-guessing previous decisions. It's about systematically assessing earlier work as our information set evolves. This ensures the program doesn't move forward with outdated assumptions.

As an example, hardware programs can take years to execute, during which the world changes. Events may render requirements that were relevant two years ago no longer applicable.

Since the PKR, a new engine configuration was introduced, which changed valve timing requirements and drove program-wide updates.

3. Taking a lap

When problems hit, go forward, not backward. Often, we need to take an extra lap around the spiral. This shouldn't be seen as a failure, but rather a natural part of the program. We might have a qualification test failure, uncover a design flaw, or encounter a supplier issue. When these happen, resist the urge to reverse course. Going backward is disorienting and can create configuration chaos.

Instead, chart a path forward from your current position around the spiral and back to the last major review. Pass through every documentation gate. Update all artifacts, and conduct a repeat review to synchronize the team. This maintains stability while incorporating new learning.

After confidence testing revealed valve seal degradation, we conducted a delta-PDR to update the design with improved materials.

4. Recognizing convergence

The spiral is working when we see convergence and metrics trend in the right direction. Issue tickets close faster than they open. The risk register shrinks at each review. Design changes decrease with each lap. Test failures become rare exceptions.

When these trends sustain across multiple spiral cycles, we're narrowing in on mission-ready hardware.

Applying the framework

This framework is a starting point. Every program must tailor it to its specific context. When elements don't fit, modify or eliminate them. When gaps emerge, fill them with program-specific approaches. The framework itself should spiral, growing with each application.

This approach requires teams embrace uncertainty rather than fight it. Change is inherent, and rework is expected. Refining our understanding and reengineering our solution to match is forward progress, not toil.

These ideas emerged from years of hardware development, watching various approaches succeed and fail. I've been fortunate to learn from steely-eyed operators, meticulous engineers, and skilled technicians. Yet, many others have deeper experience and hold wisdom that this framework doesn't yet capture.

Every application of the spiral helps to mature and refine the approach. Each program brings together people with deep, specialized knowledge that can strengthen the framework. We're still on an early revolution of understanding hardware spirals. The best insights are yet to come.

Subscribe now

General References

1. Civil engineering: diagrams of canal locks. Coloured engraving by J. Pass, 1 March 1800. Wellcome Collection. https://wellcomecollection.org/works/vexamm82/images?id=bj3naadn

2. Barry W. Boehm, "A Spiral Model of Software Development and Enhancement," Computer 21, no. 5 (May 1988): 61-72, accessed July 15, 2025, https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf.

Yet scientists do it. They know the mass, spin, and age of a black hole with remarkable precision. They achieve this not by studying the object, but rather its effects. They point telescopes just outside the black hole's event horizon—the point of no return where objects are permanently drawn in.

They capture superheated gas spiraling into oblivion, stars whipping around at millions of miles per hour, and gravitational waves rippling through spacetime. Every observation on the outside helps to build an understanding of the inside.

Complex problems share this same opacity. The production bottleneck that defies identification. The teams that inexplicably can't collaborate. The component that behaves differently on the bench than on the vehicle.

Staring directly at these problems yields nothing but frustration. Add in a bit of pressure, and the situation can feel overwhelming.

When I hit this point, I've learned to stop staring at the void. Instead, shift focus to the periphery, just like astrophysicists do. A playbook emerges.

1. Find observable effects. What characteristics show up at the boundaries? What might we infer about the inside from these?

2. Shock the system. Change the inputs. Slow the production rate. Replace a component. Shift team composition. Watch how the system responds—or doesn't.

3. Track the patterns. What makes things better? What makes them worse? Map the trends to the stimuli. Be patient. The downstream effects often take time to present.

Step by step, patterns will emerge. It may not be possible to solve the problem fully from the outside. However, we can at least reduce the opacity enough to start seeing what we’re working with. At that point, we have options — to solve the problem or navigate around it.

Very quickly, the situation will feel surmountable. We can, in fact, address problems that we can’t see fully. Just don't get too close to that event horizon in the process.

Subscribe now

Photo: Event Horizon Telescope Collaboration

NFL training camps mark the beginning of each season. Teams reconvene after months off, bolstered by draft picks and trades. They spend weeks conditioning and practicing. Players learn to communicate and work together as a cohesive unit. Coaches evaluate talent to set the roster.

Under Bill Belichick, the New England Patriots did something different. They stripped names and numbers off jerseys during early camp sessions. No identifiers. Just plain uniforms running drills.

This leveled the playing field.

The moment something is named, it becomes anchored. Reputation and expectation follow. That's the senior guy. The first-round pick. The Alabama product. The one who fumbled in the playoffs.

Our brains crave shortcuts—easy ways to categorize and pattern match. But these shortcuts blind us to current reality. We focus on pedigree instead of performance.

Blank jerseys forced raw evaluation. Every player existed only as today's effort. Not college stats. Not contract value. Not fan expectations. You may have finished last season at the Pro Bowl, but today, you're just another guy in a uniform.

It wasn’t just about the coaches’ evaluation. This approach was also targeted at on-field communication. Offensive and defensive units coalesced around performance, rather than pedigree. The best players revealed themselves.

When names and numbers returned later in camp, the right players were in the right positions. Many were unknowns who emerged as stars—and went on to build the most dominant dynasty in NFL history.

Subscribe now

The line between healthy subcultures and toxic cliques is razor-thin.

Subculture is an integral part of a strong organization. At the beginning, when companies are small, there's typically one culture. This is the foundation as the organization grows. But growth creates specialization. Not everyone has the same job. Some folks work in the field. Some in the shop. Others on corporate teams. Everyone's in the trenches working to make the company successful, but the trenches are all different.

This is where subculture comes in.

Each group both needs to and will naturally develop its own subculture. This stems from shared experiences and common work scope. It coalesces the team. Ideally, there's a culture-carrying leader that spearheads the subculture and unites the group. The team’s ties to this leader often match or exceed their ties to the overall company.

Healthy subculture is prosocial. It creates something bigger than any one person, that all can be a part of. It includes common language, team mottos, and swag. Trust and pride underpin it all. Subculture enables cultural reach that a top-down whole company culture can't achieve without feeling forced.

Teams use inclusive language when discussing challenges. Lots of "we" and "us." Groups actively collaborate across domain boundaries with other teams. Much work gets done. Subculture is good for business.

On the bad side of the line are cliques.

Cliques in organizations are basically the same as in high school. In their most basic form: exclusionary, critical of others, and ripe with gossip. At their worst: disrespectful and immature. They focus more on internal colleagues than external challenges. Cliques draw borders between teams and build identity through shared enemies. They demotivate and destabilize the organization.

The bad news is that once they form, cliques are hard to reverse. After a team flips from subculture to clique, usually the only option is a surgical removal of the entire group. You can try to address it with just the foremost clique leaders, but often the behavior and mindset quickly become deeply rooted. Leaving even the slightest bit can cause it to grow back.

This poses a practical challenge. It's understandably difficult to remove an entire team without losing functionality in the business.

The good news is that cliques aren't usually contagious. If Team A makes the unfortunate swap from subculture to clique, it doesn't necessarily trigger a chain reaction that causes Team B and Team C to follow. Team A might be an acute problem impacting the entire organization, but at least it's isolated.

Maintaining the balance is both straightforward and difficult.

First, don't let fear of clique ever hold back the healthy variant. Encourage subculture. It makes the entire organization stronger if everyone has deep, direct ties to their immediate peers. Find the right culture carriers, give them resources, and watch teams coalesce around them.

The best way to address cliques is to prevent them from forming in the first place. Create opportunities for cross-team interaction. Perspective is an excellent defense against clique. Bring groups together that wouldn't normally cross paths in their usual work.

It’s also essential to ensure the foundational organizational structure is strong and present. This can be difficult with distributed teams and during periods of high tempo. However, the organization’s core culture and values must always be present as a North Star for all subcultures.

At the same time, watch for the warning signs: inside jokes that become weapons, team meetings that devolve into gripe sessions about other departments, or culture carriers who build loyalty through shared negativity rather than shared mission. In summary, lots of "us vs. them."

If they do form, cut out cliques faster than you think you should. If you're inclined to try coaching first, set a firm deadline. In every instance I've dealt with this, I wish I'd moved to the scalpel faster. The loss of functionality we all so deeply fear rarely materializes, and if it does, it's never that bad.

Someone always rises to the occasion, especially when the clique is gone.

Subscribe now