Everyone knows the legacy systems are a problem, but when you ask for $2M and 18 months the answer is always no because it’s too risky, too expensive, and how do we know it’ll work anyway?
Jason Birmingham, when he was head of capital markets and finance at Fannie Mae, got the same response when he wanted to kill 150 legacy systems, and leadership didn’t think his team could pull it off. Jason says 90% of transformation projects fail so the skepticism made sense, plus your executives have watched other companies bet big on modernization and lose. Meanwhile the tech debt compounds and eventually you hit a burning platform.
What a steel thread is
The term comes from bridge building where engineers throw a steel cable across the valley and then use it to move progressively heavier loads until the full bridge is built.
In software you pick one workflow and build just enough to make it functional end to end, so not all the features or edge cases, just the absolute minimum that demonstrates your new architecture handles real work.
A common example for steel thread implementation goes like this: if you’re building a Slack clone your first steel thread might be any unauthenticated person can post a message in a hardcoded general room and messages persist through page refreshes. No authentication, no user accounts, no multiple channels, just the core path proving messages flow through your system.
The difference from typical MVP development is that most teams build features horizontally by designing all the APIs and building all the components and then trying to integrate everything at the end, but steel threads force vertical integration from day one so the slice is narrow but it touches every part of your stack.
How to build one
Pick your slice in the first two weeks, and it needs to be narrow enough to build fast but important enough to prove your architecture, plus it has to cut through all system layers like frontend, business logic, database, and integrations because if it doesn’t touch a layer you haven’t validated that layer.
Spend the next eight weeks building the minimum by asking the same question for every feature request, which is whether this is required to prove the core workflow, and if not it’s out. Hardcode what you can, skip error handling unless it breaks the demo, and use the simplest possible implementation.
Deploy to production in the final two weeks, but not staging because you need actual production with real data even if it’s 1% of traffic behind a feature flag, and you’re proving your architecture works where it has to live.
One engineering leader delivered a critical feature in four weeks using this approach after the dev team had been blocked for a year, and it went live days before an iPhone launch, which was the first time that telco’s commerce site didn’t crash during a major product release.
How Jason used this
He broke things into chunks and got value going early and validated architecture before making the big bet.
Before asking leadership for full funding he had systems live in production that aligned with where Fannie Mae needed to go, and that built confidence because without something running in production he says they never would have gotten the greenlight.
He says, “There’s a lot of people who do want to change, but they don’t maybe want to be the first ones to do it. You’ll have people jump on the bandwagon and really help you start to push it, which is exactly what you need to drive change.”
Once people saw it working the skeptics came around and the full funding approved itself.
Why it works
Your CFO cares about political risk and not your architecture, so a $2M modernization project that fails is a career problem while a $200K proof of concept that fails is a rounding error.
The steel thread changes the ask from trust me this will work to look it’s already working, so instead of betting on your judgment they’re funding something already proven in production.
The 90 day timeline matters because it’s long enough to build something real but short enough that finance approves it without executive review, and by the time leadership realizes what you’re doing you have working code they can see.
What happens if you skip this
Jason watched Fannie Mae put off the transformation decision for years because people knew the legacy systems were killing them but nobody wanted to tackle it, and maybe they didn’t think the team could do it which is fair since most people can’t pull off transformations.
Putting off the decision compounds the debt, and by the time you realize the hole is too deep you’re in trouble, so get comfortable with small wins that aren’t scary.
Where to start
Find one workflow that cuts through every layer of your target architecture, something important enough to prove the concept but simple enough to build in 90 days, then build it and ship it to production and show stakeholders and then ask for the real budget.
Jason Birmingham is CTO at Broadridge Financial ($6B company, $10T in daily trades) and he led transformation at Fannie Mae where he retired 150 legacy systems using the steel thread approach, and before tech he worked in finance and management consulting.
The Steel Thread Framework, from Sonatafy’s Engineering Intelligence Hub. Insights drawn from over 170 engineering leader interviews on Software Leaders UNCENSORED. Practical tools for technical leaders navigating engineering budget planning and team justification. Explore more at sonatafy.com/software-solution-directory/
