This article is based on analysis originally published at nextgov.com, covering cultural factors that affect IT modernization in government agencies. The principles apply broadly to any large organization undertaking digital transformation.
Why Culture Determines IT Modernization Outcomes
Legislative and budgetary support for IT modernization—such as the Modernizing Government Technology Act and the cross-agency priority goals in the 2018 President’s Management Agenda—created formal pathways for federal agencies to replace aging systems. But funding alone does not guarantee results.
A persistent structural problem in federal IT is that a significant share of the IT budget has historically been consumed by operations and maintenance of legacy systems, some older than the employees who maintain them. Reduced discretionary budgets, growing cybersecurity threats, workforce attrition, and accumulating technical debt compound the challenge.
The deeper obstacle, however, is organizational culture. Agencies routinely concentrate on selecting the right technology stack while underinvesting in the organizational change required to make new tools effective. Here are three cultural factors that CIOs and agency leaders should address explicitly in any IT modernization plan.
1. Digital Transformation Is a Team Sport
A culture of cross-functional collaboration is the single most important factor in sustained digital transformation. Yet modernization initiatives are frequently run exclusively out of the CIO’s office, with minimal involvement from the business lines that depend on the systems being replaced.
Consider DevOps adoption as an example. A CIO shop may invest in hiring DevOps engineers, standing up cloud infrastructure, and deploying continuous integration pipelines—all reasonable first steps. But DevOps is fundamentally a culture and practice, not a toolchain. If organizational silos remain intact, the tooling delivers little of its intended value. Automation pipelines sitting between teams that do not communicate are not DevOps; they are expensive scripts.
The Department of Veterans Affairs’ transformation of its benefits system illustrates what genuine cross-functional collaboration looks like at scale. The updated Veterans Benefit Management System—one of the largest agile implementations in the federal government—reduced the disability claims backlog by nearly 68 percent from its peak. The effort relied on co-located scrum teams that included not only developers and analysts, but also product owners, program leads, site reliability engineers, cybersecurity experts, and communications specialists. Leadership actively championed the integration between business stakeholders and technical development teams.
Practical steps to build a collaborative culture:
- Map existing organizational silos before purchasing any new tools or platforms.
- Define success criteria jointly with business stakeholders, not only with the CIO shop.
- Co-locate or establish consistent ceremonies (standups, retrospectives, sprint reviews) that include both technical and business team members.
- Empower cross-functional teams to make decisions without unnecessary escalation chains.
2. Start Small, Learn, and Evolve
Large-scale, all-at-once modernization efforts—often called the “big bang” approach—have a poor track record. The complexity and interdependencies of legacy systems make it nearly impossible to anticipate every risk when attempting to replace everything simultaneously. A single miscalculation can stall the entire program for months.
A culture of deliberate, iterative learning is the antidote. Starting with one pilot program on one system allows teams to surface real-world constraints, capture lessons, and apply them before scaling. This approach requires transparency about both successes and failures—and a leadership environment where honest performance data is welcomed rather than suppressed.
The National Science Foundation’s adoption of the Scaled Agile Framework (SAFe) for a portfolio of grant management systems demonstrates this model. The team began with a single release on a single program, methodically documenting what worked and what did not, and sharing that data openly. Over time, NSF expanded mature scaled agile practices across the entire organization. The cultural shift also enabled a technical shift: the organization moved toward a lean microservice-based architecture that allows faster delivery of new capabilities.
Key principles for iterative modernization:
- Identify one bounded system or process as the first pilot—one with enough complexity to be instructive but not so critical that failure is catastrophic.
- Define measurable outcomes before the pilot begins, so results are evaluated against evidence, not impressions.
- Build retrospective reviews into the program calendar; treat them as mandatory, not optional.
- Use pilot learnings to update playbooks, contract vehicles, and architectural standards before expanding to additional systems.
3. Don’t Overlook Procurement Culture
IT modernization culture cannot stop at the boundary of the internal organization. How an agency buys technology and services reflects and reinforces its culture just as much as how it builds them.
A common contradiction: agencies state a goal of integrated DevOps services, then issue solicitations that split development and operations into separate contracts. This procurement structure recreates the silos at the vendor level that the agency is trying to eliminate internally. Vendors delivering against fragmented contracts have no contractual incentive—and often no mechanism—to collaborate.
Some agencies have begun issuing solicitations that procure development services at the sprint team level, which is a meaningful improvement. However, sprint-level contracts often fail to address the broader ecosystem: how application services will integrate, how they will be maintained in production, and how user feedback will flow back into the development cycle.
A related gap is the underrepresentation of non-technical expertise in modernization contracts. Procurements tend to specify technical certifications for developers and architects but omit equivalent requirements for change management professionals, organizational development specialists, and communications leads. These roles are not peripheral to digital transformation; they are often what determines whether end users adopt a new system or work around it.
Procurement modernization recommendations:
- Draft solicitations that require an integrated DevOps service model rather than siloed development and operations contracts.
- Include explicit task areas for change management, user adoption, and organizational communication—not just technical delivery.
- Require experience or certification for change management and communications key personnel, applying the same rigor used for technical roles.
- Address integration, maintenance, and feedback loops in the statement of work, not only initial development deliverables.
The Takeaway
Technology decisions in IT modernization are, in practice, the easier decisions. Selecting a cloud platform, a CI/CD toolchain, or an agile framework involves known options and established evaluation criteria. The harder work is changing how people collaborate, how organizations learn from failure, and how contracts are structured to support integrated delivery.
CIOs and program leaders who treat cultural change as a prerequisite—rather than a side effect—of IT modernization are the ones whose programs deliver lasting results. The technology follows the culture, not the other way around.