Delivery Excellence

Red Teaming: how to find the cracks in a "perfect" plan.

Plans rarely fail because teams lack talent. They fail because nobody pushed them hard enough before launch.

Plans rarely fail because teams lack talent. They fail because nobody pushed them hard enough before launch. Red Teaming gives leaders a way to stress-test their strategies, digital modernization plans, and delivery systems before reality does it for them.

Seeing the cracks before they show

Some plans look solid until you start asking the right questions. On the surface everything lines up: goals, timelines, confidence. Push a little harder and the weak spots show.

That is where Red Teaming comes in: putting a strategy, modernization plan, or delivery approach through stress-testing while it is still on paper, before budgets, deadlines, or expectations do it instead. It starts with a few simple but uncomfortable questions. What will actually hold when things get hard? Where does the plan start to bend when constraints change? What are we missing because we are too close to it?

Some time ago, we ran a Red Team session for an application modernization program. Once we looked under the hood, 80% of the total effort and cost came from just 20% of the features. Everyone swore they were essential. When we challenged that, they were not. The team cut the scope and delivered five times faster. The budget pressure disappeared, and the effort went to what mattered.

The real value of Red Teaming: it surfaces blind spots early, while they are still cheap.

When modernization turns into assumption theater

Modernization programs are full of conviction, and often, untested assumptions. Teams pick a direction and run: rebuild everything from scratch. Refactor gradually. Go hybrid and take the best of both.

Each path can make sense in the right context. The risk arrives when nobody asks whether the chosen approach fits the organization's reality: its timelines, its patience, its complexity. A full rebuild can look elegant and crumble under time pressure. Incremental refactoring can drag legacy issues along for years. Hybrid approaches sometimes create twice the coordination load instead of balance.

Red Teaming slows the conversation down just long enough to test which path truly works, before commitment sets in.

When incremental delivery stops feeling like progress

Breaking delivery into smaller pieces is usually the safe move: smaller batches, faster feedback. But teams can start mistaking motion for momentum. They ship, review, and ship again, and the business outcome barely moves.

Red Teaming checks the sequence. Are we prioritizing the right things? Do early increments actually set up what comes next? Will the plan still make sense when priorities shift? It keeps the work aligned with outcomes instead of activity, so progress means more than movement.

When delivery looks predictable until it isn't

Every delivery plan looks predictable at the start. Work flows in neatly, priorities are aligned, estimates look reasonable. Then reality arrives: requests pile up, priorities shift, estimation inflates, and the process that felt solid on slides starts slipping in practice.

Red Teaming exposes those weak points early. What happens when ten urgent requests hit the queue at once? How stable are priorities when everything feels important? Where do timelines start to drift under pressure? Catching this early saves rework later, and protects trust when deadlines get hard.

Delivery Excellence

Would your plan survive a hard push?

Tell us what you are about to commit to. We will tell you honestly where it bends.

Start a conversation →

When architecture looks great on paper

Architectures almost always look right in the design phase. Everything connects, arrows align, dependencies make sense. Execution tells a different story: services buckle under load, hidden dependencies surface, integrations misbehave.

Red Teaming the architecture means testing how it behaves under strain before you build. Simulate failure. Test scale. Ask what happens when one key service goes down. The goal is designing for resilience, not just elegance: systems that keep working when things do not go to plan.

Why it matters

Red Teaming is about confidence. It is how you make sure the plan you believe in can stand up to the pressures that are certainly coming: tighter budgets, shifting expectations, faster timelines.

No plan survives untouched once reality hits. The best ones already know where they will bend, and they have built the strength to stay standing. Start a conversation, or read how we pressure-test plans.

Share this piece

LinkedIn X Email
Chris Smillie

Chris Smillie

CTO & Co-Founder, Build With Assembly

Co-founder of Assembly and CTO. Chris owns Assembly's technical direction, the engineering practices that show up in every engagement, and the architectural standards that govern Assembly's delivery work. He also owns the long-arc decisions that shape how Assembly engagements are structured and delivered. Two decades of hands-on engineering across cloud, applications, and integration at scale.

Chris on LinkedIn →