Virtuous Roadblocks and Digital Service Delivery
If Men were angels, no government would be necessary. If angels were to govern men, neither external nor internal controls on government would be necessary. In framing a government which is to be administered by men over men, the great difficulty lies in this: you must first enable the government to control the governed; and the next place, oblige it to control itself.
— James Madison
Hey there!
Are you thinking of joining the federal government to build better digital services for those that need them? Are you new to government service?
Awesome! This post is for you.
You may not have an especially positive view of government technology. You may have heard about all the bureaucracy. Lots of waterfall. Lots of big design and requirements gathering up front. Big, complex, infrequent, risky deployments. Government has all of these!
You may think that government IT shops need to learn more about agile, and DevOps, iterative delivery, and generally more about the way that product teams deliver stuff in the private sector. And you’d be right — we do need more of that.
But what you may not know, and what may take you a while to figure out, is that a lot of the things that make delivering digital services in government more difficult exist for a reason. There is a constituency for the madness we see in government IT — someone whose objectives and goals are served by the labyrinth processes and rules we must navigate in order to ship something.
The Year of COBOL
If you were reading or watching the news about state Unemployment Insurance systems melting down earlier this year, you probably heard the word COBOL.
COBOL is a programming language that was created decades ago to run on mainframe computer systems and is still in use today, most especially in government. You may even encounter it after you start your journey in public service. In some ways, COBOL and its continued use by states and the federal government became a convenient scapegoat for the problems that public benefit systems experienced this year. But the truth was deeper than that.
One of my favorite write ups on COBOL this year is from the technology historian Mar Hicks, who details how COBOL was developed and became widely used in both government and the private sector. A point in this essay that resonated strongly with me is that one of the reasons that COBOL is so often disparaged in the world of “modern technology” is because of the characteristics of the language that were meant to make it easy to use:
But despite this, there’s a cottage industry devoted to making fun of COBOL precisely for its strengths. COBOL’s qualities of being relatively self-documenting, having a short onboarding period (though a long path to becoming an expert), and having been originally designed by committee for big, unglamorous, infrastructural business systems all count against it.
So, the features of the COBOL language specifically designed as virtues have become the reason it is so often scorned.
There is a parallel here that we can draw with government — the features of government designed specifically to be virtuous (and which, as a result, can introduce complexity and bureaucracy) are the reason it is so often scored.
Complex by Design
To overcome bureaucracy, we need to separate those of its aspects that are problematic from those that are not, and focus our efforts on the former.
— Mark Schwartz, Author and former CTO of U.S. Citizenship and Immigration Services
Governments don’t use waterfall because they like it (spoiler: they don’t). They don’t do massive up front requirements gathering, sometimes taking years before a single user is talked to or line of code is written, because it results in better outcomes (spoiler: it doesn’t).
They do these things because the budgetary, regulatory and oversight environment in which government IT operates favors these methods. It rewards projects that use them with approvals, and funding, and ATOs.
And the fact that people in government might use these methods isn’t as irrational as it might first seem.
Governments are complex because they are big and have lots of responsibilities, but they are also complex on purpose. The complexity is baked in as a way to guard against things like corruption and the concentration of power. Oversight and auditing powers are vested in different parts of the government, and they all have a legitimate and important role in how services get delivered.
Our government was designed to make it harder to do things quickly and effectively. That notion is as American as apple pie. And while this isn’t always the reason that government technology projects fail, it is a common reason why a project team might adopt suboptimal practices.
Someone else in the government enterprise has a need or objective that is served by the requirements imposed on technology projects. And those requirements incentivize the things we preach against in pursuit of successful outcomes. It’s not an information deficit on good practices that leads project teams to do things the wrong way, but rather a rational response to bureaucratic pressures they are facing.
“Reforming” the way we do government technology, or scaling good practices across agencies will require us to understand the nature of these incentives, why they exist, whose purposes they serve, and how they push project teams to adopt bad practices.
We need more people in government who understand the practices that help ensure successful delivery of government digital services. We also need more people in government who understand the constraints and incentives facing agencies who want to adopt them.
We need you.
