Sean Boots

Technology, public services, and people. But mostly people.

A bleak outlook for public sector tech

Version history

Paul Craig (one of the best developers I know) recently wrote a blog post on the massive amount of compliance documentation his team produced to launch a small public website in a Canadian government department. It’s a must read:

Traditional IT government projects try to guard against the possibility of costly mistakes by requiring product teams to seek approvals from a revolving door of committees and groups. Unfortunately, the accumulated time and energy spent appeasing these various gatekeepers can be just as costly to the team as the mistakes they are trying to prevent. In our case, our 12-page website needed approval from around 8 different groups over a 6-month period. … For our 12-page site, we ended up writing almost as much as the Great Gatsby.

Something that was meant to optimize the team’s workflow and relieve a mild inefficiency turned into a black hole of effort: consuming hours and hours of time for documentation that few people will ever read.

When the cost of trialling new things is so punishing, it is not practical or even rational to try. … I’m not saying we shouldn’t have any compliance processes – of course we need security reviews and internal documentation of some kind. But above all we need procedures that are proportional to the outcomes, that adapt to changing situations.

This is a topic that’s near and dear to my heart, and one I’ve written about a few times here.

Documentation is a good thing; done well, it helps new developers onboard to a project; it helps ensure that privacy and security approaches are shipshape; it’s a critical part of making interoperable software systems. But the vast majority of government IT documentation doesn’t actually do these things.

If you work in a government IT operation, ask yourself how much time your team spends on building and shipping software, and how much time it spends on what I call “performative IT paperwork”. What’s the ratio? There’s some minimal amount of paperwork (like the documentation examples above) that’s genuinely worth doing, but everything beyond that is taking time and resources away from actually meaningful work. (Which is to say: work that has an impact on actual people.)

It’s comparable to the distinction Mark Schwartz (the former CIO of the US Citizenship and Immigration Service) makes between “watching” and “doing”. Most government IT organizations have vastly more people watching (various project management, security, privacy, communications, enterprise architecture, IT standards, etc. roles and gatekeepers) than doing (designers, researchers, software developers, DevOps staff, and product managers). And even then, organizational structures and processes mean that people ostensibly in “doing” roles end up spending more time on “watching”-related activities.

What’s unfortunate is that, in most government settings, IT organizations trend over time towards more watching and less doing, because watching is easier and also more similar to other government activities, which makes it more familiar and comfortable. That in turn makes “doing” even more difficult.

The result? Ten times more time and effort spent on performative IT paperwork than spent on building and shipping a useful product.

Digital government: how are we doing?

Here’s where I’m at. Public sector tech work (in Canada, at the federal level) is not in great shape. This is a problem for a bunch of reasons, but it’s a complicated one because it tends to be too niche for political leaders to care about, and too entrenched for grassroots public servants to be able to change (given the strong hierarchy of the federal public service).

These aren’t the only factors involved, but they’re three that I’ve been thinking about a lot lately:

1. An ill-equipped executive class

The federal public service has about 80 deputy ministers and associated DMs, about 400 ADMs, and several thousand executives (in various director or director general/executive director -type roles). Several hundred public servants become executives for the first time each year:

On average, I’d guess that it takes about 10 to 15 years between when someone joins the public service, and when they become an executive (with a lot of exceptions, for example people being recruited directly into executive roles, or joining the public service through programs like RPL that place them near the top of the non-executive classifications from the beginning). 10 to 15 years is a long time to be inadvertently insulated from how organizations work, and how technology is used, in fields outside of government.

Which is to say: of the 800 public servants that just joined the government’s executive ranks, how many would be well-equipped to lead, champion, or shepherd a technology initiative? My guess is, 20 or 30 of them, or less than 5%. How many will be expected to lead or influence technology initiatives in some way? In all likelihood: all of them.

(It’s also worth saying: those 20 or 30 tech-savvy public servants joining the executive ranks? That is absolutely worth celebrating, and they’re going to have a positive impact wherever they go in government. It’s just that there are so few of them, and that the senior executives still above them are likely to have skills and expectations that are yet more dated and insular.)

2. Agile words but not agile implementation

The second factor (and this comes up a lot lately in conversations with tech-minded public servants) is that, over the past few years, it’s become much harder to tell “who gets it” when it comes to digital government work. Digital-focused teaching and capacity-building efforts (which, I should say, I’m a big fan of) have popularized the terms and ideals of digital government widely across the public service.

What that means, though, is: if you’re looking to work with government teams who are empowered and motivated to work in modern ways (and you should be), it’s now much more difficult to tell those teams apart from any other, more traditional, government IT team.

If someone says “we use an agile process”, what used to be a vote of confidence is now a bit of a red flag:

Essentially: government IT teams have widely adopted the words that fast-paced private sector tech teams use, without actually adopting their ways of working. You virtually can’t work in an iterative, user research-led, shipping-daily kind of way when you have to write 10 times more compliance documentation (as Paul describes) than actual content and software code.

The only solution is to do less of the performative IT paperwork long expected from established processes and gatekeepers, and that’s a change to organizational power dynamics that can’t happen from the bottom. It needs to come from the top.

3. A pervasive lack of urgency

Given all this – and given that robust technology implementation is a requirement for any modern public service initiative – what might be the most disappointing is that these issues don’t seem to be on the radar of senior public service officials or of political leaders and parliamentarians. Promising steps to emphasize digital government work at the ministerial level have been discontinued. Public service renewal, or reform, or transformation – which is what digital government work ultimately consists of – isn’t a high-priority topic of conversation anywhere.

(Update: Mandate letters for ministers were published the day after I wrote this, including one for the President of the Treasury Board that includes a number of valuable digital government commitments. All told I’m feeling a bit more optimistic than a week ago.)

In the United States, to contrast, investing in modern public sector tech is an active, urgent effort. US departments are investing in a number of new ways to bring digital talent into the public service. The Biden administration has made reducing administrative burdens a public service-wide priority, to make it easier for people to access government programs and services. Civic tech luminaries have been hired to lead key federal departments. It’s an exciting time.

What would it take for this to happen in Canada? It’s not super clear. The US had the failure of healthcare.gov as its catalyzing moment for public sector tech, the moment that made political leaders start caring about technology as a thing that could make or break their most important priorities. In Canada we had Phoenix and …nothing substantially changed.

(Or, more specifically – the Government of Canada has invested substantially more money into IT projects over the past few years, but without making any really fundamental changes to how those IT projects are undertaken. That’s a problem.)

To sum up

In Canada, we have a public service executive class that isn’t equipped to lead technology initiatives. We’ve got widespread adoption of digital government words, which has largely just made it harder to tell effective and ineffective implementation apart. And we’ve got a political class that is (understandably, these days) too busy with other things to care about the public service’s tech capacity.

Not to mention: an overdependence on contractors and consultants, a shortage of in-house digital expertise, and a lack of modern tools and equipment for public servants.

Until something substantial changes – or a Phoenix-level crisis hits a public-facing service – we’ll all keep spending our time on performative IT paperwork instead of building better services.

Was this post too bleak? Not bleak enough? Are you working in a pocket of government that is doing awesome work? As always I’d love to hear your thoughts!