When U.S. Special Operations Command CIO Lisa Costa addressed a government symposium, she reached for an analogy her audience would instantly recognise: tactical shooting. “What do you do in tactical shooting?” she asked. “You remove all extraneous movement, and that’s how you get efficiency.” Her team applied the same logic to software delivery—stripping away years of accumulated process drag to let development move faster. “I don’t think anything is going to change our culture more,” Costa said of DevOps.
Her observation captures both the promise and the challenge. DevOps—a software delivery methodology that collapses the traditional wall between development and operations—can accelerate delivery, reduce risk, and improve collaboration. But the technology only works when the organisational culture is ready for it. Whether your agency is at the very beginning of its DevOps journey or already partway through, the strategies below address the cultural and structural conditions that determine success.
1. Move Beyond Current Metrics
A DevOps environment demands different processes, feedback loops, and success indicators than a traditional waterfall or siloed operation. Trying to map old metrics directly onto new workflows is both resource-intensive and misleading—the baseline simply does not translate.
Instead, agencies should audit what they measure today and pair those data points with explicit qualitative goals. The right questions are: What outcomes actually matter to the mission? What does “done” look like at each iteration? Input should come from all stakeholders—IT teams, security staff, and end users—so that the metrics chosen reflect real-world impact rather than just process compliance.
Because DevOps is iterative with no fixed endpoint, communication around metrics matters as much as the numbers themselves. Managers who share progress data openly—and who invite teams to challenge or refine those measures—create the psychological safety that fuels continuous improvement. Measure, share, adapt, repeat.
2. Stay Focused on End Goals, Not Just Outputs
DevOps promises agility, reduced risk, and greater collaboration—but agencies often track these benefits only at a surface level. Measuring a release date, for example, says nothing about whether the features that shipped actually serve the mission, or whether scope was quietly dropped to hit a deadline.
The distinction between outputs and outcomes is critical. An output is “we released on schedule.” An outcome is “end users can complete the target workflow 40 percent faster.” Think of it like a 5K race: crossing the finish line faster is not simply a matter of running harder—it reflects training discipline, form, recovery, and dozens of other contributing factors. Similarly, a successful software release reflects code quality, test coverage, security posture, and user readiness, not just velocity.
Agencies that decompose their development pipeline into measurable sub-processes—and track how each affects the end goal—gain the insight needed to improve continuously rather than just move quickly.
3. Earn Workforce and Executive Buy-In
DevOps is fundamentally about people. In most agencies, developers and operations staff have historically operated in separate silos with separate incentives: developers want to ship code; operations teams prioritise stability, compliance, security, and cost control. Neither is wrong—but the friction between these priorities is exactly what DevOps is designed to resolve.
Breaking down those silos requires deliberate effort at every level of the organisation:
- Start small. Pilot projects with clearly scoped, achievable goals demonstrate the value of cross-functional collaboration before a full rollout. Early wins build momentum and credibility.
- Communicate the “why.” Team members who understand how DevOps supports the agency’s mission—not just its IT roadmap—are far more likely to embrace the change.
- Address fear directly. Shifting roles and new responsibilities create uncertainty. Providing honest descriptions of what jobs will look like post-transformation, along with concrete training paths, reduces anxiety and attrition.
- Secure executive mandate. Grassroots enthusiasm helps, but the most successful DevOps transformations also carry a clear top-down signal: this is the direction the organisation is moving, and participation is not optional. Leaders who visibly model collaborative behaviour reinforce that message daily.
4. Build the Right Infrastructure
Culture and process improvements stall when the underlying infrastructure cannot support them. Automation, continuous integration, continuous delivery, and real-time monitoring all depend on an architecture that is flexible, observable, and scalable.
Cloud computing is particularly significant here. Research from the DevOps Research and Assessment (DORA) organisation has highlighted that teams which fully adopt core cloud principles—on-demand self-service, resource pooling, and rapid elasticity—significantly outperform those that do not on key DevOps metrics. Agencies should audit their current infrastructure against these principles and identify concrete gaps before committing to a migration or modernisation plan.
On-premises environments can also support strong DevOps practices, provided they are architected for automation and integration rather than manual, ticket-driven change management. The goal is an environment where deploying, testing, monitoring, and rolling back changes can be done rapidly and reliably, regardless of where the compute lives.
5. Build Security In from the Start
Security is often treated as a gate at the end of the development pipeline—a final review that, by definition, can only slow delivery down. In a DevOps culture, that model breaks down quickly: frequent, small releases cannot absorb the delays that end-of-cycle security reviews impose.
The answer is to shift security left—integrating checks directly into the development workflow rather than appending them afterward. Practical examples include:
- Static application security testing (SAST) that runs automatically when a developer commits code, flagging insecure patterns before they reach review.
- Software composition analysis (SCA) that scans third-party dependencies for known vulnerabilities.
- Binary analysis that checks compiled artifacts for issues that source-level scanning may miss.
- Automated bug filing when suspicious patterns are detected, so issues enter the same backlog as functional defects rather than a separate security queue.
Framing security tooling as a productivity aid—catching bugs early when they are cheapest to fix—rather than a compliance burden helps developers accept it as part of their normal workflow rather than an interruption to it.
DevOps Is a Culture Problem First, a Technology Problem Second
Implementing DevOps is substantially harder than procuring and installing new tooling. The technology is the easy part. The hard part is persuading people with different incentives, different vocabularies, and different definitions of “done” to collaborate continuously on shared outcomes—and then sustaining that collaboration under the pressure of real deadlines and real consequences.
Agencies that treat DevOps as a cultural transformation—one that requires new metrics, honest conversations about end goals, deliberate change management, modern infrastructure, and integrated security—are far better positioned to realise its benefits than those that treat it as a tool deployment project. As Lisa Costa’s analogy suggests: remove the extraneous movement, and efficiency follows. The hard work is figuring out what “extraneous” actually means in your organisation.