This article is based on remarks made by Patty Craighill, Director of DevOps Implementation at the Department of Veterans Affairs, at the ATARC Federal DevOps Summit on March 10, 2020. Original reporting by GovernmentCIO Media.
The VA’s DevOps Challenge Is Fundamentally a People Problem
When most organizations talk about DevOps adoption, they reach for tooling: CI/CD pipelines, container orchestration, infrastructure-as-code. The Department of Veterans Affairs is taking a different approach. According to Patty Craighill, the VA’s Director of DevOps Implementation, the hardest — and most important — part of the agency’s digital modernization is transforming its workforce and culture, not its technology stack.
Speaking at the March 2020 ATARC Federal DevOps Summit, Craighill was direct about where her energy goes: “My biggest focus has been the people … issues of workforce transformation and how to modernize the workforce. And that led into adopting DevSecOps and product line management at the VA and thinking about the impact that has on our workforce.”
Culture Change Before Tool Adoption
A recurring theme in Craighill’s remarks is that DevSecOps cannot be installed like a software package. Cultural preconditions — trust, autonomy, and a tolerance for iteration — have to exist before technical practices take root.
“Moving to DevSecOps is really a culture change. And if you don’t do the culture change, the rest of it won’t matter because it’s really hard getting everyone’s mindset to the right frame.”
— Patty Craighill, Director of DevOps Implementation, VA
This is a well-documented friction point in federal IT: hierarchical management structures and risk-averse procurement cultures are often at odds with the iterative, feedback-driven model that DevOps requires. At the VA — one of the largest civilian agencies in the US federal government — this tension is amplified by organizational scale and the high stakes of the systems involved.
Craighill described the trust component as bidirectional and non-trivial: “It’s about building trust across the organization from the top down among the people — leaders trusting the people who are working for them, and the people who are doing the everyday jobs trusting their leaders are giving them good direction. That’s not actually so easy to do if you don’t already have a culture of trust and autonomy.”
Breaking the Waterfall Funding Mindset
One structural obstacle Craighill identified is the traditional federal funding cycle, which pushes agencies to define and lock down project requirements and costs up front — an approach fundamentally incompatible with agile and DevOps delivery models.
“We’ve spent years in this framework where we put all our money up front. Then we want to protect it, so we’ve invested in building a certain capability. We don’t want it to vary at all because we’ve predicted how much it’s going to cost, and we want to get to the end state and be done with it in the amount of money and time that we’ve projected.”
— Patty Craighill
The shift DevOps demands is a philosophical one about what project success looks like. Rather than reaching a fixed endpoint on time and on budget, success in a DevOps model means establishing the organizational capacity to keep improving continuously.
“The new way throws all of that out and says: get into your customers’ head, make room for change, we don’t have to nail everything down up front. Success is not getting to the end point, but getting into a state of continual change and continuing to take risks. So you’re setting your organization up to keep improving and keep adding.”
— Patty Craighill
Mastery Teams: Training That Sticks
One of the most concrete workforce initiatives Craighill described is the concept of mastery teams — a training model designed to solve a problem every L&D team knows well: skills acquired in isolation decay quickly when they aren’t applied immediately.
“We’ve come up with the concept of ‘mastery teams,’ which is the idea that if you’re going to get training — particularly technical training — and don’t use it right away, it’s almost worthless. You forget, and it’s hard to go back and remember what you learned. So mastery teams embody the concept of going to training as a team, and then being able to use what you learned in training right away.”
— Patty Craighill
The mastery team model addresses this by ensuring that training is cohort-based and immediately actionable. Teams attend training together and are set up to apply new skills to real work directly afterward — compressing the gap between learning and practice to near zero. This is consistent with established principles in workplace learning, though the VA’s specific implementation details were not published in the source material.
Change Teams: Bridging Old Processes and New Practices
Alongside mastery teams, Craighill introduced the concept of change teams — volunteer groups tasked with working through the practical governance questions that arise when an organization tries to apply DevOps in a federal context.
These are not abstract process discussions. Adopting DevOps at a federal agency raises concrete questions around cost accounting, budget allocation, and acquisition — all of which are governed by rules that were written with waterfall delivery in mind.
“How do we do cost control, how do we do budgeting? And how do we do acquisition differently when we start doing DevOps? So all of these ideas we turned into change teams where we invited volunteers to work with us.”
— Patty Craighill
The volunteer model is notable: it creates internal advocates rather than imposing top-down mandates, and it surfaces practitioners who are already motivated to solve these problems.
Extending DevOps Beyond Central IT: Legacy and Cloud
The VA’s longer-term goal is to push DevOps and Agile practices beyond its central Office of Information and Technology into regional and local operations — particularly as the agency migrates workloads from private data centers to the cloud.
Recognizing that not all VA systems will move to the cloud immediately, Craighill outlined a plan to create reference implementations of DevOps tooling and practices on legacy environments — essentially staging environments distributed across VA regions where staff can safely experiment before cloud migration occurs.
“We have a lot of systems that are not in the cloud yet, so we’re going to establish some reference implementations using DevOps tools and practices on legacy environments so folks who aren’t yet on the cloud can practice these principles. We’re going to establish those in regions across the country so there are places where folks can go and try out the tools … We’re trying to make those available to anyone who wants to experiment.”
— Patty Craighill
This is a pragmatic acknowledgment that cloud migration and DevOps adoption do not have to be sequential. Teams can begin internalizing DevOps practices on existing infrastructure, reducing the learning curve at the point of cloud transition.
Key Takeaways for DevOps Leaders in Large Organizations
- Culture precedes tooling. Without a foundation of organizational trust and a tolerance for iteration, DevOps tools won’t produce DevOps outcomes.
- Training must connect immediately to practice. Cohort-based mastery teams that apply skills right after training are more effective than individual classroom learning with delayed application.
- Governance gaps are real blockers. Change teams that tackle acquisition, budgeting, and cost accounting within existing regulatory frameworks are as important as technical enablement.
- Cloud migration and DevOps adoption can run in parallel. Reference implementations on legacy environments let teams build skills before migration, not only after.
- Volunteers create internal momentum. Inviting motivated practitioners into change efforts builds advocates rather than resistors.
The VA’s approach underscores a lesson that applies well beyond the federal sector: at organizational scale, the human side of a DevOps transformation is almost always the longer pole in the tent.