Skip to content
Documentation

Engineering Intro to Deployed Teams

Engineering Intro to Deployed Teams

Why this team exists

Maya is a senior software engineer embedded with a state benefits agency on a twelve-month deployment to improve how they operate. Two weeks in, she’s read the codebase and found the bleeding. Deploys are manual. There’s no test suite. Nobody can tell when the nightly batch job fails until a caseworker calls. She writes it up cleanly: adopt CI/CD on GitHub Actions, add observability with Datadog, automate the deploy, and backfill tests on the batch job. Every word of it is correct. The agency’s lead engineer reads it, agrees with all of it, and asks her four questions:

  1. Datadog isn’t on our approved software list. How long does that take?
  2. We don’t have budget for it this fiscal year. Can it wait until the next planning cycle?
  3. Our security review process is six months. Who owns getting it through?
  4. Our existing vendor contract says they own the pipeline. How do we change the SOW?

Maya doesn’t have those answers, because none of them are engineering questions. None of these are problems in private industry, where she’s from. So she does what good engineers do. She builds a proof of concept on a sandbox account, writes the perfect runbook, and offers to walk anyone through it. The PoC is great. Everyone nods and agrees to move forward at the start of the fiscal year.

Then the fiscal year turns:

  • The Datadog request enters the approved-software queue behind forty others. Security review opens a ticket.
  • The vendor asks for a contract modification to touch the pipeline, and since it requires their support, they want additional money.
  • By month nine, Maya’s contract is winding down and we’re no closer to fixing the issue.
  • Month twelve, she rotates off. The runbook is still in the repo. Nothing she recommended is running in production.
  • By next year, the next embedded engineer opens the codebase, finds the same bleeding, and writes the same memo.

The bottleneck was never engineering capacity or knowledge. It’s the path from we should use this to running in production — and that path runs through a system engineering doesn’t control: procurement, ATO, contracting, the institutional layer that moves at its own speed.

The hard truth is that a small engineering team that will eventually leave cannot personally fix every agency, vendor, and system it touches.

How we think it should work

A year after Maya rotates off, picture a different engineer.

Priya walks into a new agency on a twelve-month deployment. She does what Maya did — two weeks of discovery, reads the codebase, finds the same bleeding. Manual deploys, no tests, batch jobs failing silently. The agency lead asks the same four questions Maya got.

The difference isn’t Priya. The difference is what’s in the central Deployed Team repository before she ever shows up.

She knows what’s in the central Deployed Team repository before she ever shows up:

  • The approved-software inventory is one click away, so she knows which observability tools are already cleared and which aren’t.
  • Named contacts for procurement for contract-mod language, PORFP, or RFI
  • Proven SOW templates that’s gotten through twice already, ready to adapt for this project
  • Slides from a previous lunch-and-learn the team can run themselves.
  • Reusable templates from prior discovery she can build on instead of recreating.
  • Short videos walking the agency engineers through the parts that are hardest to learn from a doc.
  • The MDDS point of view on build vs. buy vs. existing tool — so when the agency raises the Salesforce question, she’s not arguing from scratch.

Priya files the procurement request the same week she finishes discovery. Because she knows the procurement timeline, she can tell the agency lead — honestly and specifically — that the pipeline won’t be live until month five. That changes what the agency plans around. It also changes what she plans around: she now knows she has three months of waiting time on this engagement.

While Priya waits for the cog to turn, she starts a two weeks of discovery at another agency. Same pattern, mostly the same recommendation, different specifics. Files the procurement, sets the realistic timeline, moves on. By the time the first agency’s pipeline goes live, she’s already two months into the second engagement and starting discovery on a third.

This is what scaling engineering actually looks like in government. Not an engineer at every step of the way. An engineer who can run three engagements in parallel because the central repository has paid down the cost of every step that used to require her full attention. The slow parts are still slow. They’re just no longer blocking the engineer’s time.

That’s how engineering scales here: not by adding engineers at every step, but by making sure the engineers and embedded staff we already have walk into every engagement with the hard parts already mapped. The work that used to take a year of one engineer’s time becomes three years of capability built across three agencies in the same calendar.

What the team has been saying

The names may change, but the problems don’t. Maya and Priya’s stories are fictionalized examples. This is a real-life readout of the issues we see across current deployed-team engagements:

  • We start every engagement at zero. The maps, diagrams, decisions, and contacts from the last engagement at the same agency aren’t somewhere we can find them. The first three to six months of every new deployment go to rebuilding context that already existed.
  • The agency partners we’re working with often aren’t permanent. The person we’re training is sometimes detailed from another division for the same duration we are. There’s no plan for what happens after both of us leave, and the agency isn’t writing new job descriptions to absorb the work.
  • We hit the “Salesforce will fix everything” wall and have no shared way to push back. Each engineer makes the same argument from scratch, against agency leadership who’ve usually already decided. There’s no documented MDDS point of view on build vs. buy vs. existing tool that someone new to government work can lean on.
  • Procurement is so painful that the agency gets attached to whatever solution it can already pay for — even when it’s the wrong one. Without a clearer rubric and faster paths, program teams act in their own interest, get the money, and lock in a solution that’s then frozen in time.
  • The engineer is embedded for a year, but the agency has no way to plan around the exit. The capability we’re trying to build has no home when we leave. Premature load bearing is happening to engagements while we’re still in them.
  • We need to introduce the Deployed Team the same way every time, and we don’t. Every new engagement reintroduces the model to agency leadership from scratch. The pitch is good. It’s just being given for the tenth time.

None of this is anyone’s fault. These are predictable results of running a small central team across many agencies without an inheritance model — without anything the next engineer can pick up from where the last engineer left off.

What engineering can offer right now

Hiring more engineers takes time, and government hiring takes longer than most. While the Deployed Team scales up, there are lightweight ways the engineering function can already help deployed teams get unstuck — without adding heavy process or another standing meeting.

These are pilots, not permanent commitments. Each one is meant to be low-effort to offer and high-return for the team using it.

  • Engineering intakeA simple way for deployed teams to describe a technical need: the risk, the urgency, and the type of support needed. The intake itself becomes signal for what to hire for next.
  • Engineering office hoursA standing block where deployed teams can bring questions, with agency stakeholders invited when it helps. Async-friendly when scheduling doesn’t work.
  • Lightweight architecture reviewsA technical second opinion on a project that needs one. Not a gate, not a sign-off: a working session with another set of engineering eyes.
  • Reusable technical question setsStandard questions to bring into agency or vendor meetings: the ones an experienced engineer would ask if they were in the room.
  • Internal engineering documentation on maryland.devMore of how engineering operates, published openly, so agency engineers and deployed team members have reusable guidance to point to.
  • Technical sounding-board hoursA standing block where engineering serves as a sounding board for teams working through technical ambiguity. Sometimes the value is just talking the problem through with someone who’s seen it before.

None of these are a substitute for embedded engineering work. They’re the connective tissue between deployments — the thing a team can reach for in the moment, without waiting for a new engineer to be hired and onboarded.

If one of these would help your engagement right now, reach out. If something we haven’t listed would help more, that’s worth knowing too — the menu should match what teams actually need, not what we assumed they’d need.

How we choose what to take on

Saying yes to everything is saying yes to doing nothing well.

Even the largest philanthropies face this. The Gates Foundation has spent the past few years actively narrowing its priorities rather than expanding to meet every request, because saying yes to everything is the worse trade. The Deployed Team faces the same math.

Even with the repository paying down institutional cost, we can’t personally fix every agency, vendor, and system we touch. We make trade-offs on where we invest. Before accepting work — and periodically while we’re already in it — we run it through four questions:

  1. Is this an engineering gap we can actually move? If the wall is procurement, staffing, or political will, our engineering help won’t fix it — and pretending otherwise burns out the engineer and burns our credibility. Building another prototype won’t help. (This is Maya’s wall: the recommendation was right, the gap wasn’t engineering.)
  2. Does it unblock more than one team? A runbook that serves twenty agencies beats an engagement that serves one, even if the one is louder.
  3. Are we the team best positioned to help? If research, design, or another team has it covered, we redirect rather than duplicate.
  4. Will the work carry forward without us? If not, we redesign the engagement or decline it.

Saying yes to work we can’t sustain weakens every other yes we’ve already made. It creates more problems than it solves.

The four questions aren’t only for intake. They’re worth re-asking at month three and month six of any active engagement, because the answers change. What looked like an engineering gap at the start can reveal itself as a procurement gap by mid-engagement. The discipline of revisiting the questions is what keeps us from quietly sliding from enablement into capacity substitution.

What this looks like in twelve months

The first agency gets a working pipeline. The second is six months behind the first. The third is just starting. The central repository has three more procurement notes, two more runbooks, one more named owner, an updated build-vs-buy rubric, and a refreshed ecosystem map than it did a year ago. The next engineer walks in further forward still.

That’s the Deployed Team — not because every problem got solved, but because the cost of solving the next one keeps going down.

The Mission

The goal isn’t to save the agency. It isn’t to save the project. It’s to make sure our work outlasts us — not as an individual project, but so the next engineer at MDDS, five years from now, doesn’t have to start where we started.

Additional Reading

On the structural bottleneck

  • Jennifer Pahlka, Recoding America — the cultural-and-structural critique of government technology delivery from the founder of Code for America and the United States Digital Service.
  • Matt Andrews, Lant Pritchett & Michael Woolcock, Building State Capability — premature load bearing, isomorphic mimicry, and Problem-Driven Iterative Adaptation.
  • Marcus Cox & Gemma Norrington-Davies, Technical Assistance: New Thinking on an Old Problem — displacement vs. capability building, and “islands of excellence.”
  • Oxford Policy Management, Reimagining technical assistance — the doers / partners / facilitators framework.

On outcomes vs activity

  • Joshua Seiden, Outcomes Over Output — the canonical tech-industry definition of an outcome as “a change in human behavior that drives business results.”
  • SoPact, Output vs Outcome — the operational distinction between output indicators and outcome indicators.

On prioritization under scarcity

  • Centre for Effective Altruism, Core principles — the Importance / Tractability / Neglectedness framework.
  • Bill & Melinda Gates Foundation, 2026 Annual Letter — active narrowing and catalytic interventions when capacity is finite.

See also