Driving Operational Relevance Through Feedback Loops and Continuous ATO

Original broadcast 8/20/25

Presented by Carahsoft

George Lamb, Director of Cloud and Software Modernization in the Office of the CIO at the Department of Defense, has spent years working to make DevSecOps not just a development methodology, but a complete operational reality for the nation’s largest and most complex organization. For him, the key to success lies in collapsing the traditional gap between development and operations, ensuring that software is not only built well but delivered to the field quickly and in a form that is immediately useful to its intended users.

Lamb begins by reminding us that in government, DevSecOps is more than a buzzword—it’s a promise to deliver software that directly supports mission outcomes. In too many cases, he explains, legacy processes meant that it could take years to define requirements, months to secure authority to operate (ATO), and even longer to get a system into production. That delay often meant that by the time the software arrived, its relevance to the mission had diminished.

His team’s focus has been on the “Ops” side of DevSecOps, where the real-world challenges of putting technology into service play out. Lamb emphasizes that it’s not enough to have great development platforms—though programs like Platform One have proven their value on the “Dev” side. The harder part, he says, is ensuring that operational requirements are addressed early and continuously, so that by the time software is deployed, it’s already been tested under real-world conditions.

One of the key shifts Lamb advocates is moving operational testing and validation to the front of the development cycle. Traditionally, testing occurred at the very end, often uncovering problems that could have been avoided if addressed earlier. By embedding operational tests earlier—well before production—teams can confirm that software will work in the field, reducing the likelihood of last-minute surprises and delays.

Equally important is establishing a robust feedback loop between users and developers. Lamb points to examples where users received software, quickly identified missing features or usability issues, and saw those changes delivered in weeks rather than years. This kind of responsiveness builds trust, encourages more feedback, and creates a virtuous cycle where software continually evolves to meet operational needs.

This feedback loop, he notes, is as much about culture as it is about process. Developers are most motivated when they see their products being used and valued in the field. In the old model—where code might sit for a year or more before deployment—developers never got that immediate validation. In the continuous delivery model, they see the impact of their work quickly, reinforcing team camaraderie and shared purpose.

Lamb also highlights the cultural and technical significance of Continuous ATO (C-ATO). In the traditional model, an ATO was a one-time event, followed by years of static operation. In a C-ATO model, security is continuously assessed as new code is produced and deployed, ensuring ongoing compliance without halting delivery. Lamb stresses that C-ATO is not just a compliance exercise—it’s a way to build resilience, as teams regularly practice responding to anomalies in production without panic.

Scaling C-ATO across the Department requires both leadership and a willingness to accept incremental progress. Lamb notes that many program security officers hesitated to offer early pathfinder projects to the CIO until they were “perfect,” but perfection is not the goal. An 80% solution that is already significantly better than the status quo is worth adopting, and can be improved over time. He cites recent Army pathfinders as a breakthrough, demonstrating that major programs can implement C-ATO in a way that meets operational and security needs.

Once one service proves the model, others are quick to follow. Lamb sees this dynamic as a healthy form of competition—whether it’s the Army, Air Force, or Navy, each wants to be seen as leading in secure, rapid delivery. That competitive spirit, when aligned with a shared mission, accelerates adoption across the Department.

The broader goal is to move beyond siloed efforts where each branch or agency “grows its own” tools and processes. Instead, Lamb advocates for creating reusable solutions—whether in C-ATO practices, cloud infrastructure, or DevSecOps pipelines—that can be adopted across the Department. This reduces duplication, increases interoperability, and speeds delivery for all.

Lamb’s perspective underscores a fundamental truth: DevSecOps in the Department of Defense is as much about organizational change as it is about technology. Success requires leadership willing to prioritize speed and operational relevance, security teams willing to accept incremental progress, and developers and users engaged in continuous dialogue.

For Lamb, the payoff is clear. When a $200 million program can get into production faster, deliver features more quickly, and adapt to user feedback in real time, the result is better mission support and smarter use of taxpayer dollars. It’s a shift from measuring success by compliance checklists to measuring it by operational impact.

The Department of Defense, he believes, is on the cusp of making that shift permanent. With early successes in C-ATO, growing examples of effective feedback loops, and leadership attention at the highest levels, Lamb is optimistic about the future. The challenge now is sustaining that momentum and embedding these practices deeply enough that they become the norm, not the exception.

Key Takeaways

• Embedding operational testing early in development ensures production-ready software on release.

• Continuous ATO enables secure, rapid delivery and builds resilience through regular anomaly response.

• Strong feedback loops between users and developers create faster improvements and stronger adoption.