Sean Boots

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

The cycle of bad government software

Version history

One of my all-time favourite blog posts is from Leah Lockhart, titled ‘I don’t know how to use a computer!’: the stories of our most dangerous public servants. Writing from the UK – but equally applicable to the Canadian public service – Leah captures in a profound way why government systems and software tend to be so bad.

Bad government software – the user-hostile, complicated, enterprise systems that public servants everywhere are accustomed to – trains public servants to have low expectations of government software systems. Then, as individual public servants progress over time into management and leadership roles, they make IT decisions (and end up procuring new, equally bad software systems) based on the low expectations they were trained to expect:

It’s no secret lack of computing skills, including understanding various basic practices around safety and security, are low in public sector workforces. In fact I’d argue public services nurture these low skills and send people down a spiral of de-skilling with their outdated browsers, outdated operating systems and messy IT infrastructures…which may have been procured by the senior person who doesn’t know how to take a screenshot.

This cycle is produced (and reinforced) by a few interconnected factors:

  • The low quality and poor usability of many (perhaps most) of the software systems that public servants use on a regular basis

  • The insular-ness of government IT culture (for example, the perception that governments need special, government-specific software and IT systems rather than commodity products)

  • The high level of job security in the public sector (that, compared to the competitive private sector technology industry, does not incentivize continued learning and professional development to the same extent)

It’s not uncommon to find IT managers and leadership that have spent the entirety of their career in the public service. If they have moved between the public and private sectors, this is often limited to government-focused IT consultants and systems integrators. It’s much more rare to find IT professionals, in leadership roles in government, whose careers included stints in technology companies far removed from government. As an early post here reflected, the more movement back-and-forth between “normal” (non-government-related) technology companies and organizations, and the public sector, the better.

Breaking the cycle of bad government software depends in part on changing people’s expectations of what is acceptable when it comes to the software and systems that public servants use. And, for that matter, what’s possible with everyday “modern” technology. The opposite of low expectations, essentially, is expecting the technology you use to be intuitive, fast, and helpful.

A striking moment in my public service career thus far, back in 2017, was teaching a senior executive in my department how to use Google Docs for the first time. (No, not with sensitive data, and yes, reactions like that are part of the accumulated low expectations here.) As they watched edits I was making on my computer show up in real-time on theirs, they were floored. Google Docs was released in 2006; it had been available for 11 years prior to that point. That executive’s kids might’ve already used it on a regular basis in their elementary school. But in that moment, the experience illustrated how strongly public servants are insulated from the technology realities that the rest of the world is accustomed to.

That insular-ness has a lot of downsides, not least that it makes public service leadership even more vulnerable to flashy sales pitches from IT vendors and consultants for yet more expensive, government-specific IT systems. Not having the expertise to tell good from bad software, to recognize user needs, and to tell when things should be cheap or when they should be expensive – these are all reasons why public servants in IT leadership roles end up choosing bad software. But the reason these happen is because, over the course of long careers, they were trained by their everyday tools to have low expectations.

Interested in hearing public servants’ first-hand experiences with government software systems? Annex 2 of the Internal Red Tape Reduction Report is a must-read.