ADRs, not status decks

A certain kind of large program runs on slides. Every week, each vendor produces a status deck. The decks are green. The program is, somehow, also late. Everyone has been reporting progress against a plan that stopped describing reality months ago, and because the artifact of the program is a recurring slide rather than a durable record, nobody can quite say when the divergence started.

We've led the technical side of multi-vendor government and enterprise programs, and we don't run them on status theater. We run them on two artifacts that hold up: architecture decision records, and a schedule built backwards from production cutover.

The decision record beats the status slide

A status deck answers "how do we look this week." An architecture decision record answers "what did we decide, why, and what did we give up." The second question is the one that matters when a program runs for years and people rotate on and off it.

On a multi-vendor program, the failure mode is rarely a single bad decision. It's a decision made in a meeting, understood three different ways by three different vendors, never written down, and then quietly relitigated every few months because no one can point to what was actually agreed. An ADR ends that. It's a short, durable, versioned record that lives in the repository: the context, the decision, the alternatives, the consequences. When the prime contractor's new architect joins in year two and asks why the integration uses a queue instead of direct calls, the answer is a file, not a folk memory.

Decisions written down are decisions that stay decided. That single property removes an enormous amount of the friction that makes big programs slow.

The schedule runs backwards from cutover

The other artifact is a schedule that starts at the end. We fix the production cutover — the real one, the date something has to be live and working for actual users — and we work backwards from it. Every integration, every dependency, every vendor hand-off gets placed relative to that fixed point, not relative to a wish.

A schedule built forwards from "let's start and see" accumulates optimism at every step and discovers the slip only at the end. A schedule built backwards from cutover surfaces the impossible commitment early, while there's still time to renegotiate scope instead of the date. It's less comfortable in the first month and far more comfortable in the last.

Coordinating across the seams

The hard part of a multi-vendor program is the seams — the points where one vendor's system has to meet another's. That's where the technical lead role earns its keep. We sit in the integration layer: not owning every vendor's work, but owning the architecture decisions that span them, the interface contracts between them, and the realistic schedule that accounts for the fact that vendor B can't finish until vendor A ships.

In our own engagements this often looks like Ironwire leading the cloud, infrastructure, and AI work while a partner like Watkyn carries the client agreement, with primes and domain vendors in their own lanes. The structure varies. What doesn't vary is the discipline: the decisions are recorded, the schedule is honest, and the integration points are owned by someone whose job is the whole, not a slice.

What you get instead of a green deck

A program run this way is less reassuring in the short term and far more reliable in the long term. There's no weekly performance of progress. There's a repository of decisions anyone can read, a schedule that tells the truth, and integration points that hold. When something is going wrong, you find out from the schedule, early, instead of from the slide, never.

Status decks make a program look managed. ADRs and a backwards schedule make it actually be managed. We'd rather do the second.

---

Running a multi-vendor program that needs a serious technical lead? Start a conversation.