Process Eats Culture for Breakfast
Famed management consultant Peter Drucker is often credited with the phrase “culture eats process (or strategy) for breakfast.”
You can’t change organizations by implementing new processes alone, so the thinking goes, you have to foster a new culture in order to drive real change. To understand the degree to which this idea is accepted as management philosophy gospel, we have but to count the number of times it is repeated at conferences, in meetings, or on social media by various thought leaders.
But when we think about changing the way public sector organizations work, particularly in how they acquire and manage new technology, this idea gets flipped. In the world of government technology, process eats culture for breakfast.
One of the great truisms that underlies much of the work being done by digital service teams in governments around the world, and in civic tech communities, is that governments are not very good at adopting or managing new technology.
It can be tempting to view this lack of technology acumen as a symptom of general disfunction. Governments are thought to be large, plodding bureaucracies that do lots of things poorly — technology management and implementation are but one of the many things that governments do not do well.
People working in and around government digital transformation often take the position that the disfunction they see in public sector technology adoption is the result of a lack of knowledge or awareness on how to do something “the right way.” As a result, a great deal of energy and effort is expended telling governments how to do things differently when it comes to technology adoption. We often seek to develop a new culture in government organizations — one that values the input of users, embraces smaller projects and more speedy deployment, and highlights the value of cross functional teams.
But what if we proceeded from the assumption that there are people in government who generally know that they need to change the way they do things, but are unable to do so. Framed this way, the challenge for those of us working in government digital transformation becomes less about telling people what to do, and more about understanding the barriers keeping them from doing things differently.
The challenges facing governments as it relates to technology adoption are quite specific — there are a handful of processes, all easily identifiable, that work against the efficient adoption of technology by governments. More importantly, each of these processes that hinder efficient technology adoption work as designed. They are not broken. They exist for a reason.
Understanding why governments struggle to implement new technology requires us to understand what these processes are, and why they negatively impact technology adoption so specifically. If we don’t these process will end up eating the new culture we hope to bring to government organizations, and the problems we hope to solve will go on.
Modular contracting, DevOps, and Agile development are all cultural changes that digital service teams try to bring to their partners in government agencies. Each underscores the value of “smallness” — breaking work down into smaller pieces and delivering them more quickly. This reduces risk, and helps us ensure we are delivering services that will address real user needs. There is also ample data showing that larger technology projects fail at a much higher rate than smaller ones.
It’s no secret that reduced project sizes and more rapid delivery to users improves project success rates, but why is it still so common to see large technology projects with long delivery timelines in government?
Let’s think about the processes that impact how a government technology project gets funded, approved, and implemented. these includes things like the budget process, intergovernmental funding and governance processes, and the accreditation process for software applications.
Federal and state budget processes begin many months before a single dollar ever gets spent. As much as 18 months before a budget is even enacted, the executive branch will transmit instructions to agencies for preparing the future budget request. This will include a complex set of documents that will capture the amount of funding that agencies will request , as well as a detailed justification for why they need it.
Agencies will need these detailed justifications as the embark on a months-long set of hearings where their requests are questioned and scrutinized over and over again, first by the executive budget office and then later by legislative committees. Digital service teams often engage with agency partners after a budget has already been enacted, and the agency is ready to spend the money that has been approved. It’s not uncommon for these teams to find the agency’s plans for spending approved funds to be overly detailed and prescriptive, suffering from all of the symptoms of the Big Requirements Up Front (BRUF) approach.
The success of a digital service teams’ efforts in working with an agency partner like this typically depends on whether they can instill the culture of “smallness,” by adopting approaches like modular contracting, DevOps, and Agile. Unwinding these plans for overly large technology projects, which fail more often than smaller ones, is not always successful. What’s often missed is that the budget process that makes funding for these projects available doesn’t just allow large projects to happen, it incentivizes them. It makes larger projects more likely than smaller ones.
Agencies that can describe in detail to executive branch officials and legislators exactly how they will spend tens or hundreds of millions of dollars 18–24 months in advance are the ones that get their projects funded. BRUF is a virtue in the process in which budgets get formulated and adopted. It’s a process tailor made to encourage a waterfall approach to projects.
There are similar effects from other processes central to how technology projects get funded and approved. The process that governs how states receive funding for systems to administer federal programs (e.g., Medicaid) have similar waterfall- inducing features. When these processes require states to develop large, detailed plans up front for funding approval, and impose burdensome gated reviews checkpoints during project execution, it makes larger (and more complex, and riskier) projects more likely.
This is also true of the processes whereby software applications are accredited and granted approval to operate — a key milestone in many government technology projects. In some federal agencies, this process can take many months, or even years. The process usually requires many steps, lots of manual work and is paperwork-intensive.
Because agencies face these burdensome processes at key approval points in a technology project’s lifecycle, it’s not hard to understand why larger projects are more common. From the perspective of the agencies that must comply with gated reviews and ATOs, it’s rational to decide on a project approach that minimizes exposure to these processes. If iterative delivery of smaller project components requires an agency to navigate these labor and time intensive processes more frequently, it helps us understand more clearly why larger projects are more common.
In the early days of government digital service teams, the goal was to bring a new culture to government — one that approached risk differently, and placed the needs of users at the center of the work. A decade or so into this work it, seems more obvious than ever that simply bringing a new culture to government technology projects won’t be enough.
Simply telling agencies what they need to do misses the influence of existing processes — all working exactly as designed — on technology project outcomes. The need to reform these fundamental processes underscores that our most important work is not about technology.
Either we work on fixing these processes, or they will continue to eat our agile culture for breakfast.
