This article is based on remarks made at an FCW DevOps workshop held on June 21, 2017, as reported by gcn.com. Quotes are attributed to the original speakers.
DevOps Is Not One-Size-Fits-All — Even Inside Government
Federal agencies face a unique challenge when adopting DevOps: they must balance speed of delivery with rigorous security, oversight requirements, and mission-critical reliability. Panelists at a June 2017 FCW DevOps workshop made clear that the most productive path forward is a deliberate, case-by-case approach — applying DevOps practices where they deliver measurable value rather than mandating a wholesale transformation overnight.
SEC: Relationships Before Process
At the Securities and Exchange Commission, one of the most effective early DevOps enablers was surprisingly simple: a weekly cross-functional meeting. SEC Branch Chief Michael Fairless described a cloud implementation team that brings together staff from security, applications, and network teams to surface and prioritize pressing issues.
“We are thinking in an agile way, but not necessarily working from an agile process. It is building relationships that pay off down the road.”
— Michael Fairless, SEC Branch Chief, FCW DevOps Workshop, June 21, 2017
The practical payoff from those meetings is faster problem resolution. When a security issue surfaces, Fairless noted, team members can immediately turn to a colleague they have been collaborating with for weeks rather than escalating through formal channels. That accumulated trust compresses response time significantly.
Fairless was also candid about the SEC’s constraints. The agency cannot operate on the near-continuous deployment cadence of consumer software products. Instead, the realistic DevOps win is compressing the time required to identify bad actors in financial markets — from the traditional three-to-five-year cycle down to six-to-twelve months.
DTRA and JIDO: Be Selective About What You Automate
Leonel Garciga, J6 Chief and CTO at the Joint Improvised Threat Defeat Organization (JIDO) within the Defense Threat Reduction Agency (DTRA), echoed the need for speed — particularly in getting new tools to warfighters faster. But he was equally clear that automation is not universally appropriate.
“My honest answer is that we need to look at the capabilities that we are deploying and make a conscious decision about what we are doing today. Three to five years from now it could look very different… but we need to be really smart on the software that we are pushing to DevOps.”
— Leonel Garciga, J6 Chief and CTO, JIDO/DTRA
For systems that require mandatory human review — particularly those with direct operational or safety implications — fully automated pipelines may introduce unacceptable risk. Garciga’s advice: audit your portfolio, identify which systems genuinely benefit from automation, and prioritize those first.
He also offered a practical delivery heuristic: release the first 20 percent of an IT solution to users as soon as it is ready, rather than waiting for a complete feature set. Pushing partial but functional capabilities out earlier validates assumptions and builds momentum.
DHS: From 2.5 Months to 2.5 Minutes
Department of Homeland Security Deputy CTO Rob Palmer framed DevOps automation around one concrete metric: deployment time. The goal, Palmer said, is compressing deployment windows from roughly 2.5 months to 2.5 minutes through automation.
“We are midway through building a foundation. We started with a particular cloud vendor to prove out the use case, and we are actively working through the process with our stakeholders.”
— Rob Palmer, Deputy CTO, Department of Homeland Security
Palmer’s approach reflects a proven strategy for large organizations: start with a single cloud vendor and a well-scoped pilot to validate the model before scaling. This reduces early risk and generates concrete evidence to support broader adoption with stakeholders.
USCIS: Government Oversight Structures Work Against Small Batches
Citizenship and Immigration Services CIO Mark Schwartz identified a structural tension that affects virtually every federal DevOps initiative: government program oversight is designed around large, multi-year projects — the opposite of the small, frequent delivery cycles that DevOps requires.
“There is a strong imperative to get the cycle time down in general, which requires working with smaller pieces. However, government’s oversight and program structure is completely built around bigness, which is the important conflict that stops us from getting the value out of DevOps.”
— Mark Schwartz, CIO, U.S. Citizenship and Immigration Services
Schwartz’s observation is a well-recognized challenge in public-sector DevOps adoption. Budget cycles, acquisition frameworks, and reporting requirements tend to favor large, monolithic contracts — making it structurally difficult to fund and govern a stream of small, iterative deployments. Addressing this conflict often requires changes at the policy and procurement level, not just the engineering level.
Engaging Vendors at a Technical Level: The Containers Example
Garciga highlighted another practical lever for accelerating DevOps in defense environments: direct technical engagement with commercial vendors. He described productive conversations with Docker around container technology, noting that vendors who deeply understand DoD’s operational constraints can build supporting capabilities directly into their core products.
“We need to be more aggressive on the government side to really engage these companies on a technical level and have mature discussions. They understand our constraints and what it means to be an insider at DOD, so they can start working on their products and adding new capabilities to support DOD into their core capabilities.”
— Leonel Garciga, J6 Chief and CTO, JIDO/DTRA
This shifts the relationship from passive procurement — where government agencies simply buy commercial products — to active co-development, where vendor roadmaps incorporate government requirements from the start.
Key Takeaways for DevOps in Regulated and Mission-Critical Environments
- Build relationships first. Cross-functional trust, established through regular collaboration, reduces the coordination friction that slows incident response and deployment approvals.
- Audit before automating. Not every system is a good DevOps candidate. Human review requirements, safety implications, and operational criticality should all factor into the decision.
- Start small and prove the model. Pilot with a single cloud vendor or a single system before attempting agency-wide adoption. Evidence from a working pilot is the most effective tool for winning stakeholder support.
- Ship the first 20 percent early. Partial capabilities delivered quickly generate real feedback and build momentum, rather than waiting years for a complete solution.
- Address structural barriers explicitly. If program oversight, budgeting, or acquisition rules are incompatible with iterative delivery, those systemic issues need to be part of the DevOps conversation — not treated as fixed constraints.
- Engage vendors technically, not just commercially. Deep technical dialogue with software vendors can result in government-specific capabilities being built into commercial products, reducing the need for costly custom development.
Original reporting by gcn.com. Quotes sourced from the FCW DevOps Workshop, June 21, 2017.