The Messy Middle: Why Discovery Doesn't Become Delivery

Across 20+ years delivering technology for retirement plan administrators — including launching a $200M HSA recordkeeping platform from scratch and currently leading a multi-module enterprise modernization for a retirement plan administrator — the failure pattern I see most often isn't in discovery. Discovery usually goes well. Stakeholders are engaged, the vision is articulated, the slide deck is convincing, and everyone leaves the kickoff meeting believing the program will ship.

Then the program enters what I've come to call the messy middle — the work between "we know what we want to build" and "it's actually in production." That space is where most retirement digital programs go to die, and the reasons are surprisingly consistent.

What the messy middle actually contains

Discovery produces a wireframe, a requirements doc, and a roadmap. The messy middle is everything in between that and a working production system. Specifically:

• Translating modern UX into legacy-compatible data flows. The wireframe shows real-time contribution data. The data lives in a nightly batch. Bridging that gap requires architectural work nobody scoped in discovery.
• Re-implementing rules that exist in legacy code but not in documentation. Discovery captures the rules stakeholders can articulate. The legacy system enforces hundreds more that nobody remembers until the new system fails to enforce them.
• Resolving organizational ownership of the new components. The new portal needs operations support, security review, compliance sign-off, and a runbook. Discovery doesn't usually allocate that work; it lands in someone's lap during build, and it usually isn't anyone's primary job.
• Adjudicating the gap between what was promised and what's possible. Some of what discovery committed to genuinely isn't feasible on the current platform. Someone has to make the call between "do it anyway and absorb the cost," "rescope," and "build a workaround." That decision usually requires executive air cover the build team doesn't have.
• Handling the regulatory and audit dependencies. New workflows mean new controls. New controls mean new documentation. New documentation means a compliance team that didn't sign up for the program now needs to sign off on its outputs.

None of these are technology problems. They're delivery problems. And they're predictable enough that a program structured to anticipate them will move through the messy middle in weeks. A program that isn't will get stuck for quarters.

Where programs actually stall

In my experience, the messy middle has three specific failure points. Programs that survive all three usually ship. Programs that stall typically stall on one of these.

Failure point 1 — the architecture gap goes uncalled. The team building the experience layer hits the moment where the legacy core can't support what discovery promised. The instinct is to escalate quietly, find a workaround, and keep moving. The right move is to surface the gap, get an executive decision on scope vs. budget vs. timeline, and proceed with explicit alignment. When this conversation doesn't happen, the program either ships something that doesn't match what was promised (sponsor disappointment) or quietly extends its timeline (eroded credibility).

Failure point 2 — the operational ownership question stays unanswered. The new system needs people to operate it. Those people often don't exist yet, aren't trained yet, or are matrixed into other work. The build team isn't structured to solve this. Operations leadership isn't structured to absorb it without a transition plan. Without explicit ownership, the system ships and immediately becomes orphaned — running but not maintained, generating support tickets but with no escalation path.

Failure point 3 — the regulatory dependency arrives late. Compliance review gets engaged near the end of build, discovers something that requires structural change, and either the program slips significantly or the change is deferred until after launch (where it usually doesn't get done). Engaging compliance in week 2 instead of week 32 eliminates this failure point almost entirely.

What gets programs through the middle

In the engagements where the messy middle has been handled cleanly, a few practices show up consistently.

A delivery lead with authority, not just accountability. Someone who can actually make decisions — about scope, about resourcing, about which workaround is acceptable — without escalating every time. The role is more product owner than project manager. In my experience, the wrong person in this seat is the single most common reason programs stall.

Cross-functional team composition from day one. Engineering, operations, compliance, security, and change management all represented from the start of build. Not as reviewers. As contributors. The compliance review at week 32 that derails the program is the symptom; the cause is the program structure that didn't include compliance until week 32.

Explicit decision points instead of implicit drift. When the architecture gap surfaces, there's a meeting, a decision, and a written record. When operational ownership is undefined, it gets named or escalated. Programs that stall almost always have a moment where a decision was needed and nobody made one.

Bias toward shipping something narrow. When the messy middle is hard, the response should be to narrow the scope and ship, not to expand the scope and wait. Shipping a smaller working system buys credibility and momentum. Waiting for the full vision usually buys neither.

An honest re-scoping conversation at the 60% mark. Most programs hit a moment around 60% of the way through where the team knows more than they did at discovery, and the original scope no longer matches reality. The healthy response is to re-scope explicitly. The unhealthy response is to push through and ship something that doesn't quite match either the original vision or current reality.

What we tell clients in the program kickoff

The conversation worth having before any work starts is about the messy middle specifically. Where will the architectural gap most likely show up? Who owns the operational components when they ship? What's the compliance sequence? Who has decision authority when scope and reality diverge? Programs that have answers to these questions in week 1 tend to land. Programs that find out the answers in week 30 tend not to.

The middle is where the work actually happens. Plan for it.