The Delivery Service Model

Digital Service Operating Model

Look at the operating modes below with the government technology context in hand. We hire engineers, embed them in agencies, and measure ourselves by engagements completed - then act surprised when agency capability doesn’t catch up.

Mode	Use it when	Main risk
Embedded delivery	A system is failing users now and needs direct help	The central team becomes permanent staff for another team
Enablement	The goal is repeatable capability across many teams	Value shows more slowly and is harder to measure

Notice that both modes carry the same failure risk from opposite directions: staying too long, or never transferring at all.

The model is solving for the wrong constraint, and saying so out loud is how we start solving for the right one.

Failure patterns to avoid

These appear across forty years of state-capability research and a decade of federal digital service experience. They are not character flaws. They are predictable results of engagement designs that reward heroic delivery over transfer.

Pattern	What it looks like in engineering	What proves the capability transferred
Premature load bearing	A team adopts CI/CD, GitOps, or an expert-led process before it can operate it alone. When we leave, it collapses.	The receiving team has run, debugged, changed, and recovered the practice during real work without the central team leading.
Performative modernization	The team has modern tools and success stories, but daily behavior didn’t change. The success narrative reduces pressure to build the real thing.	Daily practice changed: code review, release checks, incident review, backlog triage, and ownership decisions happen the new way when no outside expert is in the room.
Islands of excellence	One high-profile project improves while the wider organization stays stuck.	The pattern has spread beyond the showcase project through reusable artifacts, shared ownership, and a documented path that another team can follow.
Capacity substitution	External experts fill the gap instead of building the local skill. The “fill” is invisible until they leave.	A named local owner can explain the practice, operate it, train another person, and handle first-line questions before escalating.

Notice the right-hand column never describes a deliverable - it describes the receiving team doing the work without us in the room.

Outcome-based exits

Assessments Are Not Outcomes is the discipline this page exists to enforce. A polished assessment, a well-cited report, a working runbook - none of those are the work. They are the start of it. The work is whether the team can still do it twelve months after we leave.

Don’t define the exit by activities completed. Define it by what the receiving team can still do without us:

• Keep the practice running in production.
• Explain and teach the practice locally.
• Navigate procurement and operational ownership path without external support.
• Sustain it after we leave.

Exit check	Evidence the handoff is real
The work still runs on the receiving team’s side	The practice is in production and the team has operated or changed it in real work.
The team owns the work, not the central group	A named local owner can explain it, guide another person, and answer production questions.
The institutional path is actionable	Procurement, security review, licensing, and SOW ownership are documented with clear owners and next steps.
The work is resilient after handoff	A named owner, review cadence, and follow-up check were defined before the team is exited.

Notice that an engagement missing any one of these rows isn’t complete - it has a transfer gap, even if every deliverable shipped.

Maya’s runbook cleared the Technical and Capability rows on paper - the recommendation was right and the PoC ran. It missed the Institutional row entirely, and with no owner or review cadence it failed Decay resistance too. That’s the whole transfer gap in one engagement, and it’s why nothing she recommended is in production today.

When there’s a gap, the honest move is to extend with a written plan, redesign the exit, or name the engagement as a partial transfer. Don’t declare success because the calendar ran out.

Here’s the test for whether an outcome is well-written. Imagine the worst-realistic version of this engagement, the one where the team doesn’t actually grow capability. Would your outcomes catch that failure? If yes, they’re well-formed. If no, they’re activity in disguise.