A couple weeks ago, I was able to tune in to FWD50, a Canadian digital government conference now in its fourth year. Although the COVID pandemic meant it took place online instead of in person, the organizing team did a really impressive job of making it engaging and thought-provoking.
Alistair Croll, the FWD50 host, opened each day with some really fascinating interviews with different tech luminaries. One of the themes from the first day onwards was this concept, that government institutions are tech companies without realizing it:
There’s a similar quote in the business world, along the lines of: “every company is a software company, some just don’t know it yet”. Variations of that are attributed to Watts Humphrey, Satya Nadella, Lew Cirne, and probably others. Marc Andreessen wrote a famous piece in 2011 titled “Why Software Is Eating the World” that describes how technology companies are overturning the industries that they are in – Amazon and bookstores, Netflix and video rental companies, and so on. The takeaway is that: to be a successful company in 2011 (and today!) you need to be successful at software.
(What is software? I have a helpful intro guide just for you!)
There’s a lot that could be unpacked here, particularly in how this connects back to government institutions and how they work. (Not least of that is how, at their present-day size and scale, large tech firms have an impact on our social, regulatory, and political environment in ways that probably weren’t anticipated in 2011!) There’s a lot of downsides in how this idea can be interpreted, too – I bring up a few of these below.
The idea that governments are tech companies without realizing it resonates, though (parking the hazards of big tech firms for a moment). Particularly when it comes to improving how governments deliver services, by learning from how other organizations and companies do so. Alistair’s overall point was that public sector work, in a digital world, takes different ways of thinking and working than we’re used to.
As someone working in government service delivery, there’s a few elements of successful tech companies that immediately come to mind:
Fierce competition for digital talent
Tech companies are only as good as the software developers, designers, design researchers, cybersecurity experts, and product managers that work for them. Leading tech firms aggressively recruit top-flight talent, poach it from other companies, and find it in high schools. Government departments with dense job postings and year-long hiring processes are hopelessly outmatched.
Relentless product focus
Making products that people will buy – or keep coming back to again and again – is what keeps companies in business. Having a product that is elegant, fast, and easy to use is part of what differentiates tech companies from their competitors. Design trends and people’s interests continually change, and companies race to keep pace with them. In contrast, governments are usually monopoly providers – you can’t go somewhere else to get your driver’s license, or passport, or Old Age Security cheque – which removes the competition-based incentive to continually improve products and services.
Effective feedback loops with users
As part of that relentless product focus, understanding what resonates with users is a critical part of keeping companies relevant. Modern tech firms invest heavily in design research, usability testing, customer satisfaction surveys, and other ways of finding out – as quickly as possible – what will keep their users satisfied and money coming in. Being able to quickly roll out improvements based on that feedback is another area where companies tend to outshine government departments with once- or twice-a-year system upgrades.
Measuring outcomes, not compliance
In many ways, this is easier for companies, where revenue and profit are measures of success that don’t exist for government service providers. Asking “did this work?” and answering it with growth in users or revenues isn’t typically an option for governments. In place of these, governments have a habit of measuring how well processes were followed or how documentation was completed – often creating perverse incentives where institutions will make choices that are bad for users in order to better follow pre-established processes or oversight frameworks.
Each of these are things that make successful tech companies successful. They’re not impossible to implement in government settings, but they tend not to occur naturally given that the institutional incentives are so different from private-sector industries.
Fundamentally, it takes leadership to prioritize these and protect them while the institutional environment and culture slowly changes to match. This is probably the area where there’s the biggest gap – between, for example, the leadership competencies that tech companies look for in C-suite executives versus the leadership competencies that tend to be reflected in senior public service ranks.
For departments that have major service delivery responsibilities, in my view, it’s not enough to have talented folks at the CIO and senior director level. We need leadership with technology, design, and delivery expertise at the deputy minister and assistant deputy minister level on down.
Being a tech company within government
My favourite session at FWD50 was a workshop by Katherine Benjamin, Katy Lalonde, and Honey Dacanay titled “Delivering at the Speed of Need”. Each of their presentations looked at how digital teams can effectively operate in government settings – something particularly valuable in a pandemic setting where being able to design and deliver products and services quickly is critical. All of this connected back, in a way, to that question of: if governments are tech companies, what does it mean to apply that in practice? What if your team operates like a tech company, but the broader institutional environment you’re in doesn’t understand that? How do you show that your way of working is valuable?
Each of the presenters have done really inspiring, leading-edge work in bringing digital practices into government environments. As their presentations described, part of this work involves carefully understanding the environment you’re in, and the partners you’re working with; part of this depends on leadership that shields teams from burdensome processes and administrative overhead that continues to exist. Another critical part is showing your work in tangible and timely ways. In almost every case, there’s also a pretty dramatic funding disparity between newer digital teams and the traditional institutional IT groups they work within or alongside:
Digital teams often pull off herculean tasks, and yet, the dedication, drive and enthusiasm of product teams in a crisis is often used against those very same teams when they attempt to get reasonable resource allocation to align with the demands placed upon those teams.
Governance is about helping teams deliver, and not just in a moment of crisis. It is also about taking on the even harder work to create enabling conditions so that digital teams are funded fairly and sustainably, are focussed on the things that generate public value (not just cost avoidance).
That’s from Honey Dacanay’s blog post recapping her presentation; Katherine Benjamin also has a corresponding blog post and both are definitely worth a read.
The idea that government is actually a big tech company – or that it should be – could get misinterpreted in a lot of ways. There are a lot of non-tech-company aspects of governments that are critically important: making sure that vulnerable people aren’t left behind (or considered “edge cases” to figure out after the fact); public transparency and accountability; democratic leadership and decision-making. To some extent, government processes that are burdensome and slow to navigate were created in an attempt to maintain these important values.
The other misinterpretation that would be easy to make is that, if governments should act more like tech companies, then maybe tech companies should just directly deliver government services. Governments’ long-term dependency on large IT firms to build and manage services is, in my view, part of the reason why governments are so tech-challenged (and why the four elements of successful tech companies that I mention above are so absent in government institutions). This dependency might well be the most important root cause of major government IT failures, over the years. I’ll write more about that in future posts.
The FWD50 conference was, of course, sponsored by many large government-focused IT firms. Thanks, firms. That said, the Ottawa government IT conference that predated it – GTEC, organized by another company – was a far more vendor-captured, genuinely uncomfortable affair.
The other missing aspect is that there’s more to governments and technology than just service delivery. I say this reluctantly, since digital service delivery was my entry point into the field – sayings like “Most of government is mostly service design most of the time” from early GDS folk really ring true.
But, as my colleague Michael Karlin points out, there’s a lot more out there: what technology means for defence and national security; what it means for effective and modern regulations; what it means for economic development and trade, healthcare and education, physical infrastructure, intergovernmental relations and vital statistics and democratic participation and all the other activities and fields that governments are responsible for in different ways.
But, service delivery is probably the area where the mismatch between how governments work and how private sector companies work is the most noticeable. Where governments operate (or at least, are seen) as tech companies, but poor-quality ones.
Bringing the elements that make tech companies successful into government – and putting in place senior government leadership that understands and supports these elements – can only make governments better-suited to tackle today’s challenges. And tomorrow’s.
And (see you at next year’s conference, eh!) the next 50 years’.