Steel threads are the missing link in your system design

Estimated reading time: 5 minutes

Preventing the cone of uncertainty and creating a dependable approach. 

A few years ago, someone told me about a book called Art & Fear, by David Bayles. In it, we hear the story of a ceramics teacher who splits the class into two groups. One group is graded purely on quantity – 50lbs of pots gets you an A, 40lbs a B, and so on. The other group is graded exclusively on the quality of a single pot.

Here’s the kicker: the “quantity” group not only made the most pots, they also made the best ones. While the “quality” group argued endlessly about what “perfect” even meant, the other group just got their hands dirty – trying, failing, learning, improving. 

After 20+ years in this industry, I’ve realized the same lesson applies to building complex systems. The best software architecture doesn’t come from hours locked in a room with a whiteboard. It comes from building something small – your minimum viable architecture (MVA) – running it, stumbling into problems, and fixing them fast. 

This approach is the steel thread. It is the thinnest possible, production-grade end-to-end flow through a system that exercises the riskiest integrations. Functioning as it should, a steel thread is the durable base on which the rest of the system is built. 

Why choose the steel thread approach? 

When building complex systems, many engineers have to work with “the cone of uncertainty”: architectural decisions that have a broad range of possible outcomes due to limited information. Early on, everything is fuzzy: where the boundaries are, how the product might evolve, even which services you’ll depend on. 

I’ve watched teams spend months on pristine architecture docs only for the whole thing to wobble the moment we tried to integrate it. To top it all off, any problem discovered during the stitching process became costly, time-consuming, and politically challenging to resolve.

Fig.1. Architectural view of the cone of uncertainty. 

Instead of this uncertain approach, I’m moving towards an idea of lean architecture. It’s a set of lightweight practices that help reduce risk, validate assumptions early, and keep teams aligned. There are several ways to get this in motion, but the steel thread approach is the most foundational. 

The theory behind the steel thread approach is much like building a suspension bridge. You don’t pour the road first. You start with a single cable – thin, but strong enough to carry the weight of everything else that comes later.

A steel thread is that cable in software: It’s not a proof-of-concept you toss away, but it’s also not your final product. It’s the first production-grade path in a system that:

• Cuts across the whole stack (UI → backend → database → external services).
• Runs in a real or near-production environment.
• Is observable – metrics, logs, traces, the works.
• Can be demoed to stakeholders.

While it may not be the finished “bridge,” it’s strong enough to prove the architectural design can hold.

Gregor Hohpe nails it in The Software Architect Elevator:

“The lines are more interesting than the boxes… Where does stuff usually go wrong? In the integration between two well-tested pieces.”

The lines – the handoffs, the contracts, the integrations – are where systems break. Steel threads force you to run through those lines early, before you’ve built an entire feature.

Here are their biggest technical advantages:

• Shorter feedback loops: you uncover ugly truths in days, not months. For example, when we built a steel thread for a search revamp, the first end-to-end flow already exposed a caching issue that added hundreds of milliseconds to latency. We didn’t need a full search stack to see it – just one stitched path was enough. 
• Early risk surfacing: that “it’ll scale fine” API? Now you know for sure. For example, in a server-driven UI thread, even the simplest slice – one config driving a single homepage module – revealed the need for versioning schemas. If we’d waited until the full system was live, these risks would have been buried deep and harder to fix. 
• Stakeholder trust: Nothing builds confidence like something you can engage with. Whiteboard drawings and slide decks are easy to nod along with – until stakeholders realize too late that their mental model doesn’t match reality. A steel thread changes that conversation. Instead of “imagine how it’ll work,” you hand them a working flow and they see the system behave, even if it’s rough around the edges.

The steel threads approach is a  leadership tool

As a staff+ engineer, I’ve come to see steel threads not just as a technical practice, but as an effective leadership tool for securing buy-in, aligning teams, and showing visible progress. The difference is subtle but important: you’re not just de-risking code, you’re guiding people.

Here’s how I’ve been able to use it advantageously as a leadership tool:

• To align teams: Because a steel thread touches everything, no team can hide in a silo. A thread forces collaboration across disciplines; product defines the goal, design commits to usable layouts, security validates rules, and platform engineers manage rollout. Each group contributes to a tangible outcome, shifting the conversation from abstract opinions to concrete decisions.
• To show progress: Instead of waiting months to show progress, you can share a working demo to teammates or execs within weeks. I have shown steel threads two weeks into a project and watched the room light up – not because it was flashy, but because it was real. And most importantly, early learnings prevent costly late-stage rework.

How to build steel threads

Here’s the playbook I follow:

• Pick a flow that matters, preferably tied to a business goal. Ask: if this flow works, will it prove the system is viable?
• Find the scary parts – the untested services, “should work” assumptions. Look for: new services, brittle integrations, scaling assumptions, and regulatory constraints. Ask: What could fail in production and impact our business?
• Draw the path. Sketch the path end-to-end, including all services and handoffs the flow touches. If you can’t map it clearly on paper, you’re not ready to build it.
• Stub ruthlessly. Build only what’s needed for this flow to run. Decision point: if it doesn’t directly support the flow, cut it for now.
• Deploy in a real environment. The closer to production, the better.
• Measure, fix, repeat. Keep that thread alive and build on it. Track metrics that expose risks (latency, cache hits, error rates), and expand the thread as the foundation for future features.

Download the PDF framework for more detail and an example.

Takeaway for leaders

Steel threads aren’t just about testing ideas early. They’re about creating a shared source of truth.

Once you have one, the conversation shifts from “I think” to “we know.”

So before you dive into your next big build or refactor, ask: “What’s our steel thread?” Then actually build it. Ship it. Let it guide the rest of the way.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.