Sean Boots

Generative AI vegetarianism

Wed, 11 Mar 2026 08:44:10 -0700

For some spicier takes! Anthony Moser’s “I Am An AI Hater”, Jenny Zhang’s “choosing friction”, Rusty Foster’s “A.I. Isn’t People”, or Ed Zitron’s “The Case Against Generative AI” if you have most of an afternoon to read it. Emily Bender and Alex Hanna’s podcast interview with Paris Marx is also excellent.

Hello, it’s me: I’m a generative AI vegetarian.

The tech industry is convinced this is the future; every app on my phone and most of the apps on my computer want me to use their new AI features.

I don’t want any of them. I want to write my own emails. I want to write my own (mediocre) software code. I want to learn and think and ponder with other humans, not with a text-prediction system built by consuming all the text on the internet.

If you’re stoked about generative AI tools, that’s cool. A friend of mine runs workshops across Canada teaching people how to use AI systems. Friends in the government tech space have built really interesting and thought-provoking things with AI. People find these tools useful and fascinating. In my day job, I’m keen on helping people use AI tools to make government data more accessible. I’m not here to cut you down; I’m not a generative AI vegan, after all. (Sorry, vegans!)

If you’re a government department or public institution looking at adopting AI tools at scale, well, I’ve got some real strong opinions for you. (As it says on the tin: criticize systems, not people.) But I’ll save those for another blog post.

What is generative AI vegetarianism?

When I planned on writing this post (in April 2024!) I figured a background explainer on “what is generative AI” would be a good place to start. It’s 2026, and if you somehow haven’t already collided with your phone’s messenger apps or phone camera or your office suite at work telling you to summarize or generate or edit something with AI, well, I’d love to hear how you did it.

Generative AI tools are software products that produce text, or images, or other media by generating it from a user request and a very large quantity of underlying data. LLM-based chatbots like ChatGPT are the most well-known.

I often describe software as made up of three things: interfaces, data, and math. In the case of generative AI tools:

The interface is pretty minimal (a chatbot or similar text interface, or a voice-recognition based interface like Siri or Alexa).
The data, for most of these generative AI products, is the astounding part: comprehensively-scraped copies of all of the publicly available text on the internet, millions of scanned books, transcriptions of Youtube movies and other videos, and so on.
And the math, in most cases, is based on “transformers”, mathematical operations that predict, for example, what words might come next after a series of previous words. It’s just, a lot more math and an a lot a lot more data than most software products.

That’s generative AI in a nutshell.

Generative AI vegetarianism, simply put, is avoiding generative AI tools as much as you can in your day-to-day life. For me, that means:

Turning off all of the optional AI settings I can find: turning off Microsoft Copilot in my office suite (over and over again). Turning off Google Gemini on my phone. Turning off Apple Intelligence on my laptop.
Not using any of the built-in AI features that I can’t turn off. (Hello, WhatsApp and Facebook Messenger. Yes, I’m bitter about it.)
Not consuming or re-sharing articles, photos, music, or videos that other people have produced with generative AI.
Choosing software products that don’t have AI features, and supporting companies and organizations and creators that deliberately avoid generative AI tools.

It’s pretty easy! (Despite the tech industry’s best efforts.) And this isn’t even a particularly extreme position (see the spicier takes and vegan jokes above).

“AI” is a nebulous, marketing-driven label. I still listen to algorithmically-recommended music playlists; Google Photos still helpfully/creepily organizes my family photos using facial recognition; I appreciate that spellcheck and spam detection in my email inbox exist. I still think that computer vision systems and OCR and procedurally-generated art that predates the current wave of generative AI tools are all pretty neat. If someone made an AI tool that could correctly parse government ATIP request PDFs into Markdown format reliably, I would use it for sure.

But generative AI tools like ChatGPT or Microsoft Copilot or Claude or Gemini? I don’t want any of them, full stop.

Why generative AI vegetarianism?

Why choose generative AI vegetarianism? Just like real-life vegetarianism, there are a bunch of good reasons. (Full disclosure: I’m not real-life vegetarian! My wife is.) You can choose the reasons that resonate most with you.

Reasons to adopt generative AI vegetarianism:

Generative AI tools have a dial for bias, discrimination, and racism that you can’t control. From their source training material to the political alignment of major AI companies’ leadership to their adoption by fascist actors to consistently biased output, there’s a lot of red flags there. Their negative effects disproportionately affect women and historically marginalized groups, and contribute to a society-wide degradation in being able to understand what’s real.
Generative AI tools lead to a loss of critical thinking, creativity, and skill. Building skills and craft takes time and effort. It takes difficulty; short-circuiting that with generative AI tools makes it harder to become a creative and thoughtful person.
Generative AI tools are optimized to create what’s expected and predictable instead of what’s insightful. They have an “inbuilt tendency toward cliché” given that they’re, in large part, a big text-prediction system. Summaries of content by generative AI tools exclude the most counter-intuitive and unexpected (and therefore useful) parts.
The generative AI industry is destructive to occupations and human vocations that I value: writers, illustrators, musicians, and all kinds of other artists. I want our society to celebrate and support the livelihoods of more creative people; instead these jobs are rapidly disappearing.
Generative AI tools shift more power to the already powerful. More precarious employment as the result of companies adopting AI tools has already led to worse working environments and widespread layoffs (particularly in the technology industry). A constant theme that employees are replaceable or worth less is damaging to everyone across an organization. Meanwhile, many AI tools depend on very low-paid, exploitative manual human labour (often in developing countries) to actually work.
The process for creating and improving generative AI tools (scraping vast quantities of information without compensating the original creators) incentivizes restricting rather than sharing information. It also damages open source movements and collaborative human efforts (like Wikipedia) that society as a whole benefits from.
Frequently using generative AI tools or building them into an organization’s processes or workflows introduces a very real risk of vendor lock-in, where it becomes impossible to switch companies or become less dependent on the tools even if they become more expensive or less useful.
Generative AI tools are easily used as an “accountability sink”: harmful decisions can be made while obscuring the human decision-makers behind them. They can be used as a cover for decisions that cause harm either at an individual or at a societal level, and make it harder for civil society groups, opposition politicians, or the media to figure out who is responsible.
Generative AI tools, and the data centres and equipment that power them, use vast quantities of electricity and other resources. The rapid expansion of new data centres is already disrupting communities with minimal if any local benefits in return.

You don’t have to get behind the entire list here; if one or two of these resonate, that’s enough to become a generative AI vegetarian.

Our household collection of (mostly) vegetarian cookbooks.

It’s a lifestyle choice

Overall: it feels freeing. I like it. It’s easier to say “no” to generative AI tools as an entire category instead of having to draw a more ambiguous line and use them for some purposes but not others. I just don’t want to use them at all.

And if this sounds too preachy, again, I’m not here to judge you. But if, likewise, you’re not a fan of generative AI tools, I want to make it easier to put that into words. To be able to say, if someone says “check out this new AI thing!”: naw, it’s cool, I’m vegetarian. And to hope that, over time, some subset of companies and organizations will lean into that, and make deliberately AI-free books and music and videos and video games, just like vegetarian restaurant options.

I want to create things that are good. I want to value quality and craft in the things that other people make.

And you could say, “hey, generative AI tools are getting better all the time, look at how high-quality this latest generative AI book or picture or song is.” It’s still just pretending, and meanwhile, it’s taking space away from an actual human creating an actual human creative work that means something.

As Mandy Brown wrote recently about specialization and automated systems:

Impossible not to think here of the rise of labor unions in the tech industry and the subsequent rapid (and surely coincidental) deployment of so-called AI which—unlike nearly every prior technological development in software—arrived with mandates for its use and threats of punishment for the noncompliant. …

But simply watching work happen, without any of the creative, autonomous activity that would occur if they were doing the work themselves, gives rise to a degree of boredom and stupefaction that can be physically painful and spiritually debilitating. Anyone who has experienced the pleasure of creative work is likely to greatly resist that reduction; better to create workers who have never known such things.

There is a whole industry, a lot of money and political power, behind the push to put generative AI tools in front of everyone. It makes our society more fragile and, cumulatively, it makes us worse people.

We can do better. Generative AI vegetarianism isn’t much, but it’s a small and useful step.

Simon Willison (a data scientist and AI researcher who also coined the term “prompt injection”) first described the concept of being “AI vegan” in a 2022 blog post. David Joyner wrote a similarly-themed article on “AI Veganism” in 2025. Many friends on Mastodon posted ideas that helped form this piece. I learned today that Mastodon links from 2024 – when I first started drafting this! – don’t, uh, stick around reliably. It’s still great.

Introducing Vote YES Yukon!

Mon, 06 Oct 2025 13:30:31 -0700

Update: On November 3, 2025, Yukoners voted YES to ranked voting. 🎉 More than 56% of plebiscite votes were in favour of the “yes” option, to switch to a ranked voting system as recommend by the Citizens’ Assembly on Electoral Reform. Read more on the Vote YES Yukon blog.

I’m really stoked to introduce Vote YES Yukon, a non-partisan campaign in support of electoral reform during the current Yukon territorial election.

This year, the Yukon is having a plebiscite asking if the territory should adopt ranked voting, in place of the current system of first-past-the-post. I think it’s a great opportunity to show that change is possible – to improve politics in the Yukon, and also to be an inspiration to the rest of Canada.

I wrote a blog post in August in support of the plebiscite, and (as the saying goes) one thing led to another and here we are! 😄 You can read the launch post for Vote YES Yukon here,

Electoral reform – improving how we vote and choose our political representatives – has been talked about for years. The electoral system we use across Canada today, “first-past-the-post”, has a lot of downsides that lead to more polarization and more extreme political views.

Here in the Yukon, a citizens’ assembly of everyday Yukoners looked at how our electoral system could be improved. After a lot of discussion, the citizens’ assembly landed on ranked voting as the best option for the Yukon.

In ranked voting, you choose your candidates in order of preference – 1, 2, 3 and so on – when you vote. It gives you more of a choice than just picking one option, and it encourages political candidates to appeal to a broader range of the Yukon population.

At the same time, ranked voting keeps the local responsiveness and accountability of our current system. It’s a win-win!

I think the citizens’ assembly did a great job, and it’s fun to be able to champion their work. And, hopefully, see it translate into a lot of public support! The plebiscite is non-binding but if the results are positive, it could lead to eventually changing our territorial electoral system to ranked vote.

And, as a non-partisan public servant, it’s fun to be able to run a non-partisan political campaign! It doesn’t happen often. We have lawn signs getting printed and everything. (In classic public service style, yes, I filled out a conflict of interest disclosure to be doing this.)

If you live in the Yukon, check out the different ways you can get involved in the campaign. And, thanks for considering voting YES to electoral reform! 🎉

You can find Vote YES Yukon on Facebook, or see the French version of our campaign website here. Keep on being awesome!

In support of the Yukon electoral reform plebiscite

Wed, 20 Aug 2025 21:38:32 -0700

Later this year, alongside the next Yukon territorial election, we’re having a plebiscite on electoral reform in the Yukon. I am extremely stoked that this is happening, and I hope fellow Yukoners vote “yes” to changing to a new electoral system. Curious why? Read on!

What’s happening?

Alongside the next Yukon territorial election – taking place sometime between now and November 2025 – there will be a plebiscite on electoral reform in the Yukon.

This follows a citizens’ assembly that was formed between 2023 and 2024 to look at options for electoral reform in the Yukon. The assembly, made up of 38 randomly-selected interested citizens from across the territory, landed on ranked voting as their recommended change. If implemented, this would replace the current “first past the post” electoral system.

If you’ve never heard of first past the post, or electoral reform, or any of this, that’s okay! The downside of doing an undergrad in political studies (hi, it’s me) is that your parents will wonder the entire time if you’ll ever have a real job. The upside is that you’ve got opinions on electoral systems that you’ve been saving for just the proper occasion.

Like almost anyone who has studied electoral systems (ie., how people vote), I think first past the post is terrible. It’s so exciting that the Yukon is considering a new option, and in my mind it follows in the footsteps of other recent (excellent) decisions to just go for it while other provinces spend a lot of time dithering. Getting rid of daylight savings time in 2020, for example (the best!), or dropping X/Twitter and using other social media channels for government communications instead.

In both cases, just taking the plunge and making a change was a fantastic choice, and one that would have been a lot less likely in a larger and more slow-moving jurisdiction.

For electoral reform, the upcoming plebiscite isn’t binding (it’s not a referendum), but I hope that a vast majority of Yukoners vote in favour of changing our electoral system, and that the next government in power goes ahead and implements the change.

Why it’s good for the Yukon

The Yukon is a jurisdiction with a small legislature (just 19 seats), and recent elections have tended to be very tight races. In 2021, memorably, one constituency ended in an exact tie as the balance of power in the legislature hung in the balance.

First past the post (our current electoral system) is a poor fit for an environment like this. (Not that it’s a good fit for anywhere!). It exaggerates election outcomes so that a minor difference in popular vote leads to large changes in legislative seats. Policies and legislative choices tend to swing from one extreme to the other as a result. Instead of being incentivized to compromise and find common ground, politicians are incentivized to stake out more extreme views and rile up their core supporters.

Over time, first past the post tends towards duopolies at the expense of smaller parties and a wider range of viewpoints.

When your political allies and your political opponents alike are friends and neighbours, it’s not a great fit.

The Yukon citizens’ assembly recommended changing to ranked vote (sometimes called “alternative vote” or “ranked choice voting”), as an electoral change that would work well for the Yukon’s context. Here’s how they described it,

Ranked Vote ensures that more voter preferences are captured in the outcome of an election. The winning candidate in each riding must receive a majority of the votes cast, 50 per cent plus one, requiring them to have broader support across their riding. This can lead to greater voter participation and an outcome that can be seen as more legitimate in the eyes of voters.

Local representation and accountability are extremely important to Yukoners and Ranked Vote maintains this value. Voters continue to have a clear, direct, local connection to representatives who are accountable to their constituents. This is something that we value in the current system.

In the current system, voters may feel compelled to vote strategically for a candidate they think has the best chance of winning, rather than their preferred candidate. With Ranked Vote, voters can honestly rank their choices without feeling their vote is wasted.

Why it’s good for Canada

Canadian politics – at the federal level and across provincial and territorial jurisdictions – has been disappointing people since, well, probably Confederation. Regardless of the parties in power, our legislative, political, and bureaucratic processes are too slow to keep up with fast-moving social, economic, and international issues.

Public servants (and I am one) cope by focusing on mundane processes and compliance oversight. Politicians respond by riling up their core supporters with fear campaigns and dog-whistle issues (far too often at the expense of marginalized or vulnerable people).

What does this look like in practice? This Andrew Coyne piece from 2023 has lived rent-free in my head ever since I read it:

Presumably the feds can’t be happy to see provinces defying the law, treating other Canadians as second-class citizens and tearing down national institutions. But they dare not do anything to stop it, because they lack the legitimacy: because in any confrontation with a provincial government, Ottawa is likely to emerge the loser.

It’s easy to blame the Trudeau government for this state of affairs: its constant denigration of our history and symbols; its tendency to play one part of the country against another. But in truth this is a problem going back decades. To be sure, any government that was elected with just 33 per cent of the vote – the weakest mandate in our history – would have some legitimacy issues. But the broader problem is structural. The problem is that governments can be elected with 33 per cent of the vote.

Indeed, thanks to our first-past-the-post, winner-take-all electoral system, it takes little more than that to win a majority. As the number of parties has proliferated, and the distortions from vote-splitting have grown more acute, governments have been elected off a narrower and narrower base of support.

Our current first past the post system, as Coyne points out, is a root cause of a lot of the malaise and dysfunction in Canadian politics today. Electoral reform would dramatically change politicians’ incentives for the better.

Larger jurisdictions have had halfhearted attempts at electoral reform over the past few decades. Ontario had a referendum in 2007 that ended with 36.8% support for changing. British Columbia, in a heartbreaking outcome, had a 2005 referendum where 57.7% of the population voted in favour of change, but the threshold to actually go ahead had been set at 60%. Subsequent BC referendums in 2009 and 2018 had lower rates of support.

At the federal level, the previous prime minister committed to electoral reform in 2015, abandoned that promise in 2017, and then – years later – described not following through on electoral reform as one of his biggest regrets.

In those undergrad political studies classes, one of my favourite professors described herself as a “reformed electoral reform advocate”. After having been passionate about electoral reform for years, she had resigned herself to expecting that it would never take place in her lifetime.

Nevermind that most countries around the world – the United States, United Kingdom, and Canada excepted – have switched to more well-designed electoral systems over the years. We’ve been stuck with first past the post for so long that even leading advocates for reform have given up.

If the Yukon votes in favour of electoral reform, and if the next government goes ahead with the change, it will show the rest of Canada that this is actually possible. That would go a huge way towards improving our political ecosystem across the country.

Don’t let perfect be the enemy of good

When the Yukon citizens’ assembly came out with their recommendations – to switch to a ranked voting system – advocates for proportional representation quickly came out and said they wouldn’t support the proposed change.

I can understand where they’re coming from – ranked voting isn’t as proportional to popular vote as some other voting systems – but frankly I think that any change at all is better than the status quo. (Provided, of course, that the change doesn’t disenfranchise people, which as we can see from the United States is an active concern.)

That’s my constant thought – any electoral reform change that improves things even a little bit is better than nothing at all, because it creates more opportunity for future positive changes. As long as an electoral reform change ends up encouraging more eligible people to vote, and helps a wider range of diverse voices be heard, it’s a good thing.

As all of the engineers in my family say, “static friction is stronger than dynamic friction”. Once things start moving, it’s easier to keep them moving forward.

For electoral reform, just showing that some kind of positive change can happen in Canada is a massive win. I hope it happens later this year!

What’s the takeaway?

Whenever the Yukon territorial election takes place, there will be a plebiscite on electoral reform. You can find out more on the Elections Yukon site here.

The question on electoral reform will be:

“Should the way members of the Yukon Legislative Assembly are elected be changed from the current system of first past the post to a different system of ranked vote?”

Which, let’s be honest, is sort of a terrible way to ask the question. (“Different”, there, is doing a lot of work to discourage people from voting for it, which I can only assume was decided by politicians or senior public servants who are happy with the status quo.) Different is good, really, when our political system is as broken as it is. And it’s still great to be asked.

If you’re an eligible Yukon voter, I’d recommend voting “yes”! And telling your friends to vote yes too.

Let’s show the rest of Canada that we can just go for it – just like getting rid of daylight savings time changes – when no one else has the guts to make it happen.

The Yukon government switched from X to Bluesky. Other Canadian governments should do the same.

Mon, 09 Jun 2025 11:58:23 -0700

In early April, the Yukon government announced that it would no longer be using X (formerly Twitter) in response to new US tariffs taking effect. Effective immediately, Yukon’s existing government X accounts notified followers that the accounts were no longer active and suggested that people follow the Yukon on other platforms for more recent information.

The Yukon government launched an official Bluesky account the same day. The account uses Bluesky’s domain name-based verification to confirm that it’s an official account. Several other Yukon government departments have also set up Bluesky accounts, along with pages on other social media networks. The switch made national news, alongside the Yukon’s other tariff response updates.

More effective tools for reaching citizens

Since Twitter was bought, its effectiveness as a platform has steadily declined. From the dismantling of trust and safety teams, to a dramatic increase in bots and spam, to user privacy concerns, the X platform is no longer a safe or pleasant place for everyday users.

More importantly, now that X requires visitors to log in to see multi-post threads, it’s not a reliable way for governments to communicate with their citizens. If, for example, the second or third posts in a thread about emergency responses or evacuations are only visible to logged-in X users – a frequent use-case for Twitter/X over the years – this presents an actual risk to citizens’ health and safety. That’s on top of X’s degraded ability to differentiate authentic versus fraudulent government accounts, and the possibility of deliberate algorithm changes making content less visible.

For time-sensitive updates from government departments, Bluesky or Mastodon are far better choices.

But the engagement numbers!

It’s understandable that government organizations and leaders are unsure about leaving X, given the prominent role that Twitter had in public communications for more than a decade.

It doesn’t help that, within X, organizations might still be seeing fairly high engagement numbers from their existing accounts and posts. My advice here would be: look at your web traffic, analytics, and user feedback from outside of X. See if anyone is actually arriving at your organization’s website from X, rather than trusting X’s engagement numbers.

In-platform engagement numbers have always seemed a little fishy; commercial social media platforms are heavily incentivized to tell you that your posts are popular. “Engagements” as a term conveniently blends together some artful combination of views, image views, likes or favourites, actual link clicks, and more, into some number that might not stand up to much scrutiny. As John Herrman writes,

Endowed with new powers of self-measurement, media companies, advertising firms, and online platforms have turned metrics into something approaching misinformation. They’re suspicious, context-free numbers, produced in private, selectively shared to tell just the right stories…

How long does someone have to glimpse a post to count? Doesn’t say. Do multiple views by the same user count? Yes. Are these numbers auditable or checkable in any way? Of course not.

For platforms in decline, it’s not a stretch to think that in-platform engagement numbers might be exaggerated (either within the platform’s analytics code, or through bot activity on the platform) to try to retain users.

All that to say: don’t use X’s in-platform engagement numbers to justify continuing to use X. Of course it will tell you that your account is popular.

People are here for it (switching away from X)

News coverage about Canadian government organizations (mostly municipal governments) switching from X to Bluesky has been consistently positive. Thus far, I haven’t seen any examples of Canadian citizens expressing unhappiness that their city or town or regional government has stopped using X.

After the Yukon government announced the switch from X to Bluesky (disclaimer: I work there!) I posted about it on Bluesky and Mastodon (an open-source Twitter alternative).

Post by @sboots@mastodon.sboots.ca

View on Mastodon

People were stoked. There’s nothing that Mastodon users love more than stories of people and organizations leaving X. 😜 (Even if they’re not moving to Mastodon!). To date it’s my most popular Mastodon post, not that, uh, engagement numbers are that important.

I’d love to see other Canadian jurisdictions and government organizations make the switch away from X, just like the Yukon did. Government organizations in the European Union are well ahead of us. With a little bit of prep, you can do it in a day. All it takes is public service and political leadership that’s willing to make it happen.

18F’s profound legacy of procurement reform

Fri, 30 May 2025 21:27:11 -0700

Back in March I wrote about the elimination of the United States government’s two leading digital government teams. These two teams – 18F and the United States Digital Service – were an inspiration for digital service teams in governments around the world, including our own as we launched the Canadian Digital Service.

Beyond their digital service work – designing, building, and improving online services for people across the United States – these teams also did a lot of heavy lifting to challenge and change processes and policies that held back better service delivery. Most of this work, I’m sure, was behind the scenes and unseen by the public.

In the spirit of working in the open, though, 18F in particular produced a long-running series of blog posts and publications that remain one of the best sources of insights on how to do technology procurement in government differently.

As I was researching IT procurement reform in Canada with Prof. Amanda Clarke, these 18F publications were always close at hand and informed our recommendations for Canadian government organizations.

IT procurement reform in 25 minutes

You don’t need to be a procurement nerd to enjoy these insights. One of 18F’s procurement experts, Waldo Jaquith, gave a presentation to a Michigan state senate committee that is still the best and most approachable introduction to this work:

Cost savings in the hundreds of millions of dollars

Procurement often seems like a dry topic, but the consequences of doing IT procurements well or poorly are massive. As 18F and USDS were suddenly shut down, anecdotes about the hundreds of millions of dollars saved by helping departments and decision-makers make better technology choices quickly emerged. A few conversations could help save hundreds of millions of dollars by avoiding wasteful or ill-advised IT spending:

You should know that a big part of 18F's work was to make sure multi-million to multi-*hundreds*-of-millions dollar contracts at fed *and* state level didn't go to shitty enterprise IT consultancies that *repeatedly* delivered tech that didn't work, was late, or didn't even do what it needed to
— Dan Hon (@danhon.com) March 2, 2025 at 11:03 AM

One of the continuous problems with IT procurement is that decision-makers have no idea how much money a custom software project should cost. If you’re trying to solve a specific need or replace an old system: should the new software cost $50 million dollars to build? $80 million? Departments issue a request for information, large IT vendors come back with multimillion-dollar proposals – perhaps similar to past government IT projects, with a bit extra for inflation and, of course, higher project complexity – and departments go ahead and issue requests for proposals for prices that match. No one involved from the government side is well-equipped to ask if the project should really cost that much, or what all that money is for. As Waldo Jaquith writes:

The result has been 20 years of spiraling of costs for custom software in government, as prices have gradually gone up because they are tethered to nothing but the amount of money that vendors say it’ll cost, and they have every incentive to provide a big number.

He has an elegant solution to this: budgeting software projects in “scrum team years”. Scrum teams (digital product teams of, say, 4 to 10 people), might cost $1 or $2 million dollars per year, depending on the size of the team. That’s a helpful grounding point for how much a custom software project should actually cost:

Is the bid for $20 million? Then you should be getting between 10–20 scrum team years, perhaps as 5 scrum teams working for 4 years, perhaps as 5 scrum teams working for 2 years, or any number of other mathematically plausible variants. Experienced software developers can compare the complexity of a project to the number of scrum team years and have a sense as to whether the price makes sense.

This works at an agency level, this works at a procurement level, this works at a budgeting level. It allows people who lack deep expertise in software development (which is to say nearly everybody involved in the entire budgeting and procurement process) to have some basic unit of value to compare and debate. (Does this project really require 500 people working for 5 years? What could we get from 10 people working for 6 months? Wait, we’re only getting 10 scrum-team years but we’re paying $50 million? And so on.)

If you’re a public service leader working on IT or service delivery projects, the State Software Budgeting Handbook that Waldo wrote with Robin Carnahan (later the head of the General Services Administration) and Randy Hart at 18F is a must-read.

Along with that handbook, and the scrum team years blog post above, there are two other blog posts from Waldo Jaquith that I send to anyone looking for advice on IT procurement:

The one time a sitting Canadian Member of Parliament asked me for digital government advice, that’s what I sent them, too. (I no longer worked in the federal public service at that point!). Also you don’t need to be an MP to ask me for advice, you can just email me. 😜

Along with Waldo and the team at 18F, fantastic public servants across the US government worked for years to change IT procurement for the better and deliver better services to citizens. The United States Digital Service had the “procuremenati”, a small but mighty team of procurement experts helping departments buy software more effectively. Within US departments and agencies, unsung heroes worked to either change outdated rules or to achieve useful outcomes despite them. (Mark Hopson, the now-retired “procuremancer”, has an entertaining newsletter of procurement adventures from the past decade.)

I’m forever grateful to all of these public servants for their work, and for having the courage to share it in the open. If we’re ever able to achieve significant reforms to IT procurement in Canada, it will be thanks to the example they set.

Things that are happening

Tue, 04 Mar 2025 22:25:24 -0700

It’s hard to know where to start.

We’re six weeks into a new US government administration. The scale of deliberate and gleeful destruction of US state capacity on the part of the Trump administration is hard to process. As someone who writes about public service excellence it’s heartbreaking to hear so many stories of people’s careers, teams, and accomplishments being ripped apart. And to appreciate the immediate and longer-term impact of these changes: people losing access to lifesaving medicines, the abrupt halting of clinical trials and medical research, forcing out women and people of colour from US civil service leadership positions, eliminating protections for Americans with disabilities, dismantling weather forecasting, and more. Not to mention, picking fights with long-time international allies, celebrating authoritarianism, and generally flaunting the rule of law.

This isn’t a blog about US politics and it isn’t about to become one. I’m a non-partisan Canadian public servant and a very slow writer, which is two reasons why that isn’t likely to change anytime soon. But this is a blog about what it means to be a public servant in a changing world, and on that specific front, the past month has filled me with persistent sadness.

The deliberate destruction of care

I joined the public service because I want to make people’s lives better. It sounds trite but for so many public servants, their motivation is similar: to contribute to the well-being of their neighbours and communities and country.

Whether it’s research scientists or aid workers or forestry staff, the public servants being fired in the United States represent people who chose the work they do out of care for others and out of passion for the work. That’s what’s now being punished. Anne Helen Petersen wrote about this a week ago:

These cuts don’t just signal the end of public works as public good. They also signal the twilight of the passion job, better known as the jobs performed by millions of Americans, often at great personal expense and sacrifice, simply because they loved the work that they did. When you read the stories of the forest service employees who lost their jobs, that’s what you hear over and over again: I moved myself and my family across the country. I agreed to be a contingent employee for years. I didn’t make much; I spent weeks and months in the backcountry; I did physically taxing work; I dealt with understaffing and cranky visitors and unspeakable poop splatters. And I did it because I love this work.

Evidently there are downsides (as Petersen writes: work won’t love you back!) but as someone who feels the same way about my public service work, I want there to be jobs like this! I want there to be more of them, not fewer. I want people to be able to do work that is meaningful and helps people and isn’t focused on making a profit. It feels simplistic and childish to write that down, but it’s a choice we could collectively make. (And of course, “helping people” is often a cover for harm, well-intentioned or not.) But the opposite – where government services are hollowed out and replaced with for-profit and exclusionary services – is also a choice.

The loss of truly excellent public service teams

In my specific field of government tech, it was jaw-dropping to learn this past week that the US’s best digital government teams are being fired. The United States Digital Service (USDS) was folded into the so-called Department of Government Efficiency, and almost all of its existing staff subsequently resigned in protest.

18F, the digital service team within the General Services Administration, was shut down and all of its staff were fired on March 1. Don Moynihan has a detailed recap of what happened, and Lucas Cherkewski wrote more about it from a Canadian perspective here.

These teams were absolutely world-class, made up of some of the brightest minds in the technology field. These are people that left prominent tech firms and took pay cuts to make government services work better for people. (If you’re curious about 18F and USDS’s origins, this 2015 post from Ben Balter is a good introduction.)

The US Digital Service’s values, from their archived website.

As former 18F staff described it:

Just yesterday we were working on important projects, including improving access to weather data with NOAA, making it easier and faster to get a passport with the Department of State, supporting free tax filing with the IRS, and other critical projects with organizations at the federal and state levels.

Ethan Marcotte (a long time hero of mine) left 18F a few weeks before it was shut down. He writes,

Leaving was the right call for me, but I’ll never feel good about the decision. I mean, there’s the grief angle: up until about a month ago, I was working on projects that felt like they mattered, and working alongside people who cared about helping government services work better for the public. A few months ago, I would’ve told you I’d like to stay there for years, which is not something I’ve said about any other place I’ve ever worked. I am incredibly sad to leave this job.

And look, being able to leave is, flatly, a privileged option: I can’t not work forever, but I can not work for a little bit. Most of my coworkers didn’t have that option. Some had just bought a house; some returned from parental leave, only to learn they might be losing the jobs they’d counted on to support their families.

I’m also angry at what was taken from me. At what’s being taken from all of us. I’ve watched a wonderful job, a wonderful place to work, a wonderful team get pulled apart by rich men in ill-fitting suits, each of them parroting the same talking points around “realignment” and “right-sizing”.

Far beyond their immediate projects, 18F and USDS staff leave behind a profound legacy of learning and inspiration for all of us that work in this field. Everyone that I met from both teams, without exception, was happy to share insights and ideas and resources. These are humble, kind, and brilliant people, and the very best of what the civic tech community represented.

Post by @aworkinglibrary@mstdn.social

View on Mastodon

What does the United States get instead? Degraded IT security, the loss of privacy and protection of sensitive information, and a free hand for corruption, grift, and replacing in-house talent with expensive contractors and management consultants. What a choice.

A poisoned well for public sector reform

It’s a small piece of all of this, but what’s especially painful on a personal note is how these decisions are being framed around “government efficiency” and reducing government waste.

For those of us who have been advocating for a better public service for years – one with less process and more capacity – it’s distressing to see the same language we used be applied in such a deliberately cruel and wanton way.

A year and a half ago I called for a “revolution” in public service delivery in Canada. (Who else was calling for a revolution, months later? That guy.) Back in 2017 I made my own “Move fast and break things” poster (yes, it aged poorly). The glacial rate at which public service institutions typically change felt so incompatible with a quickly changing world, one that clearly needed public service teams who were nimble, able to pivot when needed, empowered with good tools and responsive to robust feedback loops.

In the lead-up to the Trump inauguration, public service reformers like Jennifer Pahlka were hopeful that this could be the moment for change that a public service held back by “procedure fetish” needed.

What hurts is that I can see a part of myself in the young and inexperienced staffers now forming these (clearly harmful) “government efficiency” teams. I too was naive and optimistic about the potential for technology to improve outdated and clunky government services. I too had simplistic ideas of how decisions are made and how things should change. I would have loved to roam from department to department, learning how things work and how much things cost and what procedures and policies were slowing things down.

But would I have wanted root access to production systems storing millions of citizens’ data? Would I have wanted to fire senior public servants standing in the way of damage to critical national infrastructure? I don’t want either of those things now, when I’m years into a government technology career, let alone when I was right at the start of working in government. I’m happy to find creative workarounds for counterproductive policies, but I am very keen on following the law. And, I say this having worked on this a lot, on double-checking the math in your procurement data!

More fundamentally, I guess: I want to change the public service to make it better at doing what it does, not to make it not exist.

“Poisoning the well for public sector reform” is how a UK friend once described the fact that, for a brief time, the most prominent advocate for changing how the UK public service works was Dominic Cummings, the advisor to Boris Johnson more famous for having flaunted COVID-19 lockdown requirements that he helped draft. That combination made any other conversations about public service reform in the UK a non-starter.

I worry that the past month or so will have had the same effect on public service reform conversations here in Canada. Who is the current face of government efficiency? That guy, again. That’s not great, when we desperately do need changes to make the Canadian public service more effective, and when all of our noteworthy recent changes (looking at you, return-to-office policies) have made the federal public service worse instead of better.

Where do we go from here? I’m not sure. At the least, hold tight to your colleagues and friends, and look out for one another. Find what your work is now, as Mandy Brown describes it. Bear witness to things that are changing, and push for as much government transparency as you can – it’s the only way to know, down the road, how things subsequently change.

And if you’re in a political or senior public service role, recognize that public service delivery matters, and that poor-quality implementation has political costs. Because by the time unelected billionaires are dismantling government services at scale, it’s too late.

For more on the shuttering of 18F, read this reflection from Hillary Hartley, this thread from Dan Hon, or this post from Lindsay Young. You can also read 18F’s excellent guides for digital service delivery, archived here.

Published in Canadian Public Administration: “Breaking All the Rules: Information Technology Procurement in the Government of Canada”

Thu, 03 Oct 2024 20:47:56 -0700

I’m really thrilled that our research article on government IT procurement was recently published in Canadian Public Administration. It’s a bit over two years since Prof. Amanda Clarke and I began this research project, and this article being published is in some ways the final milestone of that work.

The article is open access, and you can read it online (or download the PDF version). Here’s the upshot:

We reveal that the federal government betrays accepted best practice in modern government IT procurement on several key dimensions, including on contract values and lengths; on the diversity of suppliers; on the source of IT expertise; and in the management of intellectual property. We argue that the Canadian approach to IT procurement is an historically overlooked but crucial driver of its failing digital reform efforts. We conclude by turning to IT procurement policy reforms gaining traction outside Canada that may help the Government of Canada improve how it buys and deploys IT going forward—a task we argue is essential if the government wants to avoid future IT contracting scandals and deliver on its long-standing promise of digital era modernization.

I’m really grateful to Prof. Clarke, to Chantal Brousseau and Anne-Michèle Lajoie who were research assistants on the project, and to my former department and the Canada School of Public Service for the opportunity to work on this. I’m also grateful to the many friends and fellow public servants who contributed ideas, feedback, or help troubleshooting R code (thanks Lucas!), to Prof. Evert Lindquist from the Canadian Public Administration journal, and to the anonymous peer reviewers for their feedback and comments.

Along the way this research project included publishing a website analyzing Government of Canada contracts, being featured in news coverage from a variety of publications, almost presenting at the 2022 FWD50 conference (which Prof. Clarke was fortunately able to do and which you can watch on the FWD50 Access platform), and speaking on several occasions at the House of Commons’ Government Operations committee. It’s been a fun adventure!

Alongside the published article, you can read our Guide to Reforming IT Procurement or read the preprint version shared in July.

This research had its origins in an Ottawa Civic Tech volunteer open data project that started in 2017. Ottawa Civic Tech recently started up again after a pandemic hiatus – if you live in Ottawa you should definitely check it out!

If you love procurement reform…

Coming up on October 10 (next week!), the FWD50 digital government conference is having their all-online day (in addition to hybrid and in-person sessions later in November).

Warren Smith (my UK procurement reform hero) is one of the presenters. Is a “public procurement renaissance” overdue? Heck yeah!

You can get tickets online on the FWD50 website. I’ll be attending virtually & hope to see you there!

Also at the end of October, I’ll be presenting at the Canadian Open Data Summit in Edmonton about the R data analysis that went into this project. It’s a great community of open data folks (also relevant to my day job) and I’m looking forward to being there!

Speaking at the Government Operations committee this Wednesday

Fri, 19 Jul 2024 22:25:43 -0700

On Wednesday, July 24, Prof. Amanda Clarke and I will be appearing at the House of Commons Standing Committee on Government Operations and Estimates (OGGO) to discuss the research paper that we recently shared as a preprint.

If you’d like to tune in you can watch via the ParlVU livestream starting at 11am Eastern Time (8am Yukon time). You can see recaps of our previous two OGGO appearances from Nov. 17, 2022 and Jan. 30, 2023.

The research paper builds on our analysis of Government of Canada procurement contracts and Guide to Reforming IT Procurement. As Prof. Clarke writes,

The tool and the research findings our team has drawn from it have been covered by iPolitics, Politico, the CBC news podcast Frontburner, and highlighted in analysis by journalist Paul Wells. Former Clerk of the Privy Council Michael Wernick endorsed the tool as “exactly the kind of initiative [Treasury Board] Minister Brison had in mind when he pushed forward open government and open data.” Sean and I were also invited to deliver expert testimony at two parliamentary studies of federal government contracting (including the inquiry into the ArriveCAN app) by the Standing Committee on Government Operations and Estimates, where we submitted the recommendations we outline in A Guide to Reforming Information Technology in the Government of Canada.

Today I’m happy to share the academic paper we developed using the tool (it’s still under peer review, so we share it now with that caveat!). In the paper we explain the role that IT procurement plays in supporting (or more often, preventing) digital government transformation, draw on international experience to outline a set of ‘rules’ for modern public sector IT contracting, and then assess the extent to which the Government of Canada adheres to these rules.

The punchline is – the federal government breaks almost all globally accepted best practice for modern public sector IT procurement, a reality which we argue helps explain why we have scandals like the ArriveCAN debacle that’s still unfolding. More importantly, we argue that unless we reform federal IT procurement so that it gets up to speed with widely accepted best practice in the field, any attempts to drive forward meaningful digital reform in the Government of Canada are bound to fail.

You can read the (preprint) paper here – we’d love to hear your thoughts and feedback!

It was wonderful to work with Prof. Clarke and her research assistant team, Chantal Brousseau and Anne Lajoie, on this project. I’m really grateful to the Canada School of Public Service and to my old team for the opportunity to be part of this. When we began the project in 2022, none of us expected a topic like IT procurement to reach the level of public and political interest that it has over the past year or two. It’s been a fascinating adventure.

Why yes, I printed off a paper copy to make sure that the charts turned out alright, if you want to leave a copy on your ADM’s desk.

Notable charts

If the paper seems like a dense read – here are a few standout charts from the data analysis (from pages 24 and 27 of the paper respectively).

Top 10 IT vendors by estimated contract value and IT subcategory (page 24)

Across the five years of the research analysis, three vendors (IBM Canada, Bell Canada, and Microsoft Canada) received more than $100 million per year in estimated contract value. Overall that’s $4.49 billion in total estimated contract value going to those three firms (in constant 2019 dollars to adjust for inflation), or 23% of overall IT contract spending.

Estimated IT consulting services contract spending by vendor (page 27)

When it comes to IT consulting service vendors, GCstrategies – the origin of much of the current political controversy around IT procurement – is 19th on the list (by 2021-22 total estimated contract value).

You can read more about the data analysis methodology, or check out the R analysis source code on GitHub. Prof. Clarke’s 2022 FWD50 presentation is also a great overview of our initial research findings (you may need to create an account on the FWD50 Access website).

But this week – if you haven’t read it yet (academia for the win!) – read our preprint paper and, if you’d like, tune in on Wednesday to hear Prof. Clarke and I speak at the OGGO committee. We’re looking forward to being there.

Why we became public servants

Wed, 03 Jul 2024 09:48:20 -0700

These two videos are a small celebration of why people choose public service careers. Brian Whittaker, Rebecca Croll, and I compiled these with the help of wonderful public servant friends across Canada and the United States. They were shown at the 2023 FWD50 conference in Ottawa.

Part 1:

Part 2:

A big highlight of FWD50 this past year was being able to work with Brian on a panel celebrating awesome and inspiring public servants. Brian runs the Humans of Public Service project, a celebration of incredible public servants from across the United States that will brighten up your social media feeds.

We were really lucky to bring in Uchenna Moka-Solana and Dr. Rim Khazall, two brilliant and status quo-breaking public servants from the US and Canada. Uchenna and Rim talked about their public service journeys and what it looks like to challenge “how things are always done” in public sector organizations. You can watch our panel discussion on FWD50’s Access platform (you may need to create an account first).

One of the things Brian and I wanted to highlight was that amazing and inspiring public servants are everywhere. When you’re a public servant trying to change things, it can often feel like you’re alone against a giant system. Although we couldn’t bring dozens of public servants on stage, we wanted to celebrate how public servants are making a difference - in big and small ways, and often against the odds.

Rebecca is FWD50’s content director and edited these clips together amid a flurry of conference preparations! I’m really grateful to her and Brian and to everyone who was part of this video series.

You can watch keynotes, panel discussions, and other videos from the FWD50 conference on their online Access platform. And, you can register for the 2024 FWD50 conference here. Hope to see you there!

Speaking at Civic Tech Toronto

Mon, 24 Jun 2024 10:45:27 -0700

Back in March I gave a presentation at one of Civic Tech Toronto’s weekly hacknights. It was really nice to be able to tune in from Whitehorse and talk about some of my past civic tech projects.

You can watch the video recording here, or see my slide presentation here.

Civic Tech Toronto is a really inspiring and welcoming space. I’d attended in person a number of times during visits to Toronto before the pandemic, and joined in remotely when they began virtual and hybrid sessions. The Civic Tech Toronto volunteer team does a wonderful job facilitating these and helping folks feel at home both in-person and online.

Here’s the civic tech projects that I talked about during the presentation:

Sean’s Work Computer (2016-2018)
Meeting Cost Calculator (2017-2019)
Is this blocked in my department? (2018-present)
End-to-end services analysis (2021)
Internal Red Tape Reduction Report (2020)
Large Government of Canada IT projects (2020-2022)
GoC Contract Spending analysis (2017-2021)
Government of Canada contract analysis (2022, really a PSIR project that evolved out of the earlier civic tech spending analysis above)

And, of course, the running joke is that all of my civic tech projects have the exact same structure:

Take something that should have been a spreadsheet (for example: unformatted or hard-to-find, but public, government data)
Make it into a spreadsheet (or more generally, structured data that computer software can read, sometimes using data analysis tools like R and sometimes literally copying text out of a PDF by hand)
Turn that spreadsheet into a website (usually using Hugo and static site hosting from GitHub or Netlify)
Add a tiny bit of flavour (but not enough to get fired!)

“Flavour” being, some kind of very low-key colour commentary about how public service institutions could be better.

I’m really lucky that I’ve had supportive and encouraging managers and leadership folks throughout my public service career – in a lot of organizations, this sort of work-adjacent colour commentary wouldn’t necessarily be welcomed! But the goal has always been, finding ways to help us all improve as public servants and public service organizations, and better help people along the way.

You can see the software source code and data underpinning these projects by looking at the GitHub repository links for each of them.

Ottawa Civic Tech is coming back!

On a related note! I’m so excited to see that Ottawa Civic Tech is making a comeback. On Wednesday, June 26, it’s having a revival event – you can see the details on their Meetup page here.

Ottawa Civic Tech was a foundational part of my time in Ottawa, and a community where I met so many close friends. It was the home for all the projects above, a place where I could learn from and trade ideas with other folks interested in technology and public good.

It took a hiatus throughout most of the pandemic, and it’s really fantastic to see it coming back (with many of the original organizing folks behind it!). If you’re in Ottawa you should check it out – sending tons of good vibes to the whole crew!

To the Clerk, and friends

Mon, 06 Nov 2023 18:14:02 -0500

To John Hannaford, your team, and colleagues across the federal public service:

Below are a set of radical (but implementable) ideas that would make the public service better equipped to handle the challenges of today and tomorrow. We need to invest in state capacity in Canada, and that starts with changing our public service structures, processes, and organizational culture for the better.

I presented these today at FWD50, an Ottawa conference dedicated to using technology to improve society for everyone. The most important of these ideas don’t involve technology at all; they involve changing how we work to better empower front-line staff and experts, to remove burdensome processes, and to change or eliminate structures that lead to negative outcomes.

I’d be happy to chat about these anytime, you can get in touch by email.

Empowering public servants

Hire people from across Canada, and if they work at a desk, let them work from anywhere. Last year’s return-to-office implementation took the wind out of the sails of every conversation about building a better and more representative future public service. Until we admit that it was a mistake, I don’t think we can call ourselves an evidence-driven public service.
Give public servants the tools they need to do their work. Outlook and Word and Excel aren’t enough. It’s 2023. We could roll out, for example, open source data science tools to every public servant tomorrow, as a first step.
Get rid of at least one layer in the federal public service executive hierarchy. Keep the people but let them move out of management roles if they want. Citibank recently announced they were phasing out 5 of their 13 layers of hierarchy, allowing them to eliminate 60 management committees as an added benefit. We have too many talented leaders that are stuck acting as mailboxes, and too many constantly re-litigated decisions, owing to the number of management layers that we have.
Increase the number of non-management individual contributor positions, and let people advance to the very top of non-executive classifications without becoming managers. Tech companies like Shopify have done this, so that people who are good at their craft don’t have to stop doing what they do best, in order to progress in their careers.

Better structures for digital capability

Move Shared Services Canada under the Office of the GC Chief Information Officer, and make all of SSC’s service offerings optional to departments instead of mandatory. Migrate away from traditional corporate networks and just use the normal internet, like the UK did years ago and the US is starting to do now.
Stop requiring that IT and CS staff work inside departmental CIO shops. They’re valuable contributors across departments. Split the IT classification in two (rather than grouping together all technology roles, from IT help desk staff to database administrators to network technicians) so that we can hire senior software developers and cybersecurity experts at competitive rates.
Update the GC Digital Standards to actually act as a quality bar for online services. Pass legislation to enshrine user needs in service delivery and digital transformation work the way that Ontario did.
Put digital practitioners at the helm of organizations. Not sales executives, not management consulting partners. Find people that have done the work and know what it actually takes to ship great services. Make them deputy ministers. Don’t smother them under a layer or two of our longest-serving and most traditional senior public service leaders. Hillary Hartley in Ontario and Natasha Clarke in Nova Scotia have done amazing work, the best in the country, partly because they’ve been able to change things from the top.
Adopt an “approved once, approved everywhere” security assessment process for software and tools. The US has had this for more than a decade under FedRAMP, and is currently planning changes to streamline this further. Meanwhile, Canadian public service organizations redundantly assess the same widely-used software in individual departmental silos.
Mandate that all custom software written for the government is made open source, and eliminate the software provisions of the Policy on Title to Intellectual Property Arising Under Crown Procurement Contracts that only benefit large IT companies (or deprecate the policy entirely). Don’t pay for the same software twice.
Implement hard caps on time and money for IT projects, and unbundle all projects larger than $2 million/year into small ones. The UK’s spend control limits saved hundreds of millions of British pounds and curtailed spending on wasteful, expensive software. With more courage, we could do the same.

Simplify our administrative processes and improve government transparency

Get rid of all the processes that stand in the way of delivering good services. That includes probably 80% of the TBS policy suite related to project management, procurement, and IT. Outside of policy requirements that have a legal backstop (like accessibility, Official Languages, and privacy), make them all optional.
Relatedly: get rid of our 7-level information classification framework, and bring in a simplified model similar to the UK’s. Let public servants use normal cloud services without requiring additional approvals for anything that’s not Secret or Top Secret. Implement internal cost-recovery mechanisms for any documents that are marked sensitive to fund future declassification efforts and to disincentivize over-classification tendencies.
Amend Crown Copyright to declare that all government works are in the public domain. Introduce a “release to one, release to all” model for Access to Information requests, and exempt documents released for transparency purposes from the web accessibility and bilingualism requirements that apply to government communications.

Learn more from everyday people, and use this to improve our services

Create dedicated funding for departments to do design research. Normalize going out and talking to everyday people before you start building or procuring things. Eliminate policy provisions restricting public opinion research or, at minimum, set a floor of several thousand respondents below which these no longer apply.
Build better feedback loops. Require senior management and deputy ministers to spend an hour a month working front-line help desk support, answering call centre phones and client support tickets. If processes and eligibility rules are too complex for this to be doable, urgently begin work to simplify these.
Create your own critics. Fund a Canadian version of Citizens Advice that helps people access government services, and also holds us to account when things don’t work. Fund it through a long-term trust mechanism that prevents us from withdrawing its funding when it gives us advice we don’t like.

Protect the future of the public service

Update the Values and Ethics Code for the Public Sector. (I’m glad to see that this is already being considered.) Bring in a commitment to Reconciliation and a commitment to evidence-based decision-making while there’s still enough political consensus to make it happen. Give the public service some preemptive defense against post-truth political movements that are growing around the world.

Public service effectiveness matters. Implementation matters. Too often, our services and our processes let down the people who need our help the most. We can change that, by changing ourselves and our organizations for the better. Most of all, we need to get accustomed to regularly changing how we work for the better, to make decisions that increase our future capability to change, and to have the creativity and open-mindedness to make this possible.

Here’s to the future of the public service, and here’s to the people that we serve. Thanks for reading.

Revolution, not evolution, for federal public service delivery

Mon, 06 Nov 2023 18:10:38 -0500

This morning I gave a keynote presentation at FWD50, Canada’s leading digital government conference. It’s a really wonderful community and I’m really grateful for the chance to speak there.

My talk was titled Revolution, not evolution, for federal public service delivery and you can watch it on the FWD50 YouTube channel or see my slides here. In the presentation I talked about how Canada needs a revolution in how we operate as a public service – not just when it comes to technology work in government, but there in particular, too.

Martha Lane Fox’s 2010 report, Directgov 2010 and beyond: revolution not evolution was the main inspiration. 13 years later, it still rings true. Her report kickstarted a whole set of downstream changes: the creation of the UK Government Digital Service, the building of GOV.UK, and radical changes to how the UK built and delivered digital services, implemented IT spending controls, broke away from large established IT vendors, created digital service standards, and more.

As I spoke about in my presentation, here in Canada, we often tried to do surface-level versions of these same changes (migrating departmental websites to Canada.ca, for example), without having the courage to do the actual revolutionary parts.

Why does this matter? Because ”state capacity“ – or the lack of it – is an urgent and growing concern in Canada. We’re suddenly realizing that we need public service institutions to work well when it comes to challenges like pandemics, or housing affordability, or climate change and wildfires, or infrastructure, or complicated geopolitical situations around the world.

(Reflections over the past year from Paul Wells, Brian Kelcey, and Andrew Coyne illustrate this issue well.)

Photo credit to Jordan Storozuk.

Too often, our public service organizations aren’t ready for those challenges. We’re too slow, too traditional, too timid and risk-averse. We’ve doubled down on processes instead of creativity, on committees (and more committees) instead of empowering and trusting front-line public servants and experts that are closest to the problems we’re trying to solve. More importantly, our public service structures and organizational culture make it almost impossible to change things from the inside.

That’s partly why we have this recent tradition of people retiring as Clerks of the Privy Council Office – the position at the very top of the Canadian federal public service – and only after that, pointing out all the things that the public service should do differently. It’s an indication that the status quo (and the structures that reinforce it) are too heavily established, a classic “Coasian heck”.

Sharing radical ideas for change – most of the last half of my FWD50 presentation! – is an example of how to respond to Coasian hecks. Changing the “Overton window” of what we think is possible, and increasing the public pressure (and perhaps, multi-partisan political pressure) to improve how the public service works.

It’s easier, of course, to do this now that I’ve left the federal public service and work for a territorial government (which of course means, I can’t be too critical of the departing Clerks, whose ideas for change are good ones!).

But my goal throughout is always: I want the public service to be excellent. I want us to deliver services to the public that are actually good. I want us to stop doing massive IT projects that don’t actually help people. I want public servants to be proud of what we do. I want us to be proud of the tools and tech that we use, instead of embarrassed by it. I want us to be proud of our public service leaders, and I want them to lead us with courage and trust.

And I have a bunch of ideas on things to change! They’re radical, but not that radical. Here they are.

Twitter is dead. Let’s start live-tweeting conferences on Mastodon instead.

Fri, 27 Oct 2023 10:40:27 -0700

It’s been almost a year since I stopped using Twitter on a regular basis. It was a big change given how large a role Twitter played in my professional life – connecting with public servants across Canada and around the world and learning from their experiences.

Now that it’s 2023 and X (formerly Twitter) is both crumbling apart and morally suspect, I think we should make Mastodon our new community. Mastodon does what Twitter did, it’s less sketchy, and it’s part of a bigger community of federated apps that are new and exciting.

FWD50 starts in a week and a bit (Canada’s go-to digital government conference), and if you’re attending in person or virtually, I’d love to see you on Mastodon!

The always-inspiring Pia Andrews on stage at FWD50 in 2017. Not pictured: me trying to keep up on live-tweets with two phones and a laptop, probably.

Live-tweeting conferences has always been one of my favourite things – a fun way to document highlights of the conference, and create spontaneous friendships with other people doing the same thing. A tiny kinship of online people – and you’re all invited to be part of it.

If you’re new to Mastodon, that’s all good! Here’s an updated getting-started guide below.

Getting started with Mastodon

1. Creating a Mastodon account

Unlike Twitter, Mastodon is a federation of thousands of servers. While on Twitter (and most social media) you sign up through a central registry, on Mastodon, you sign up on a server (or “instance”).

For Canadian public servants, I’d recommend the mstdn.ca server; it’s run by a good team and has a lot of nice people on it. To sign up and create an account, you can go to the mstdn.ca sign up page and follow the steps from there.

Other good servers include CoSocial.ca (it’s a co-op, which is lovely!) and ottawa.place (for public servants based in Ottawa). They’re also both run by great people.

2. Customizing your profile

When other users consider whether to follow you or interact with you, they may check to see if you have an image and a short bio with your account. It just helps people know who they are talking to.

3. Post!

Post interesting things and ideas! A couple tips on this – it’s always nice to reply to people posting interesting things, to say thanks and tell them that they’re cool. And, if you post photos, it’s really important to add alt text so that people with screenreaders and other assistive tech can tell what you’ve shared.

4. Follow people and hashtags

You need to follow people before you start seeing their posts, because of how Mastodon’s federation system works. It helps to follow lots of people, and then create lists to see updates from your friends and other favourite people.

If you’re into government tech, some great people to follow are:

Dan Hon @danhon@dan.mastohon.com
Elizabeth Ayer @elizayer@mastodon.social
Waldo Jaquith @waldoj@mastodon.social
Dave Guarino @allafarce@hachyderm.io

There’s also a directory of civic tech folks and a (very extensive) directory of academic researchers on Mastodon with interesting people to follow. Fedi.tips (@feditips@mstdn.social) is also a great account to follow and learn from.

Once you’ve created an account and signed in, you can search for hashtags using the “Explore” option or the “Search or paste URL” text box. You can then follow that hashtag, which will start listening for future posts with it. If you’re attending the FWD50 conference, start following the #fwd50 hashtag before the conference starts!

That’s really all you need to know to get started!

Let me know if I can help!

I’d love to see more Canadian public servants on Mastodon, from across government jurisdictions and from across the country. If you’re a Canadian public servant and you’d like a hand getting set up on Mastodon, send me an email! I’ll help walk you through it.

I’m excited to rebuild the community of awesome public servants that existed on Twitter, and I’d love for you to be part of it.

Beyond the basics

Once you’re up and running, here is some more information to enhance your experience.

Your server moderators can have the biggest impact on your user experience. The moderator determines the rules of engagement and protects members from users that abuse the rules. You can move servers if you don’t like its rules, but it’s easiest to just pick an instance you like off the bat.
Moderators are usually volunteers. If you’re able to, it’s nice to donate regularly to help cover the costs of the server you use (mstdn.ca, for example, has a donation link on its About page). There’s no advertising on Mastodon and so the team running each instance pays for these costs out of pocket. (What’s a good amount? It’s up to you but if you’re also still unhappy about Twitter’s demise you can donate $8 a month to your Mastodon server as slightly poetic justice.)

Access

You can access Mastodon by logging into your server through your browser, or you can download an app. Mastodon is the name of the main iOS and Android apps, as well as the name of the platform.

There are also several third-party apps that come highly recommended, depending on which device and operating system you use:

Ivory (for iOS and MacOS)
Tusky (for Android)
Elk (for Android and web)
Mona (for iOS and MacOS)
Mammoth (for iOS)
Ice Cubes (for iOS)

You’ll notice a theme with the names of these apps. 😜 Mastodon is free, but some of the third-party apps have subscription or purchase fees since, again, there isn’t advertising on Mastodon or a single company behind it to fund these through ads and user tracking.

For most of these apps, it works best to create an account first through your web browser, then log in to the app and sign into your account. You can pin the app to your device’s home screen for easy access.

Expanding your account profile

You can also add links to other websites and social media profiles to your account profile. (Mastodon uses a neat setup for verification, which is optional but worth checking out if you run your own website!)

You can also opt-in to Mastodon’s cross-server search functionality, if you’d like your posts to show up in search results. Or, you can leave things as default or turn on additional privacy options.

Let me know how things go! Big thanks to everyone who contributes to Mastodon’s open source code and documentation, to the Fedi.tips team, and to everyone who shared feedback and edits to this draft post on Mastodon. Rock on! 🐘

Coasian hecks, or, when the people in charge can’t change things either

Tue, 26 Sep 2023 11:30:58 -0700

Conversations around “state capacity” – can government organizations do big things? Can they meet the complex challenges of modern society? – have taken on a new urgency over the past few years. Pressing social and economic issues, confronting the consequences of climate change, and navigating disinformation campaigns and threats to democratic participation all require an effective, nimble, and robust public service.

One of the themes of my writing here is that I really want our federal public service to be excellent. There’s a lot of ways it could improve. Although I’ve recently begun working for a territorial government, I’m always thrilled to see more public conversations on how our federal institutions could do better.

Over the past year, one unexpected and welcome source of those conversations has been recently retired Clerks of the Privy Council sharing their perspectives on what the public service should do differently. The Clerk is the senior-most public servant in the Canadian federal government, the secretary of Cabinet meetings and the deputy minister in charge of the Privy Council Office (which is responsible for managing deputy minister and other senior-level appointments, responding to pressing national issues of the day, and public service renewal efforts, among other things).

Late last year, Michael Wernick (Clerk from 2016 to 2019) began writing a series of articles on how the federal public service should change for the better. The whole series is worth a read. More recently, Janice Charrette (Clerk from 2014 to 2016 and from 2021 to 2023) shared her perspectives in a CBC interview shortly after retiring:

“The public service is still working in what I would describe as kind of analog ways and the world has moved on. You can make a dinner reservation, you can book a cruise, you can move money in and out of your bank account, transfer between the two of us — it’s remarkable the things you can do in a digital world and the public service, and our service delivery infrastructure has not kept up with that.”

“In all humility, we know we have to do a better job there,” she said.

Other former Clerks, including Paul Tellier (Clerk from 1985 to 1992) and Kevin Lynch (Clerk from 2006 to 2009) have also spoken in interviews and published articles over the past couple years sharing their suggestions on how the public service should change.

One immediate question, of course, comes up: each of these former Clerks were, in turn, the senior-most public servants in the Canadian federal government. Given the problems they identify, and the solutions they propose, it isn’t surprising to ask: why didn’t they do something about these issues when they were in charge? Or, if they tried, what barriers limited their impact?

Abe Greenspon (one of my very favourite public servants) asked exactly that question in a LinkedIn reply to Michael Wernick:

As former Clerk of the organization about which you’re writing, perhaps you could consider writing about your efforts to address these issues. As much as I appreciate you advocating for change, it feels somewhat strange absent your personal reflections about how you worked to resolve these issues yourself when you had the chance. You were the most senior official of this very organization only a few years ago at a time when all of these issues were equally relevant. Perhaps something to consider for a future piece.

Essentially: the federal public service is a strongly hierarchical, top-down organizational environment. None of the problems – in procurement, in HR, in program design, in speed of decision-making – being discussed are new; practically all of them have existed through multiple governments and political environments. If the senior-most person in charge of that hierarchical structure couldn’t change things, who can?

The Office of the Prime Minister and Privy Council (formerly Langevin Block), where the Clerk of the Privy Council works.

Coasian hecks

The federal public service isn’t unique as an organization that operates in a way that is resistant to change. In some contexts, that’s seen as one of its virtues (particularly as a non-partisan institution that can continue to operate predictably through significant changes in political leadership).

In the context of operational (and non-partisan) challenges within the public service – like cumbersome procurement processes, or an inability to hire technical expertise – this resistance to change illustrates a different underlying issue.

Essentially: the public service is an example of an organization that has been structured in a way that prevents it from changing itself. (Or at least, from changing itself quickly enough or significantly enough to matter in the context of state capacity challenges.)

Alex Harrowell has a fascinating term for this phenomenon, “Coasian Hells” (named after famed economist Ronald Coase). I’ll call these “Coasian hecks” for the rest of this piece. It’s a family-friendly blog!

Alex Harrowell’s piece is about transaction costs and the shift (over decades) towards contracts and subcontracts instead of centralized organizations. He looks at privatized rail firms in the UK and healthcare in the US as useful examples of contract-based environments involving large numbers of actors. In these cases, if something goes wrong, legal claims and finger-pointing consume a lot of resources without providing much clarity or clear responsibility over outcomes.

The “cost” of determining what happened, or who was responsible, can become unfeasibly high because of the lack of information-sharing beyond the boundaries of each organizational group. The combination of diffuse actors and limited information sharing leads to negative outcomes for which no one actor is clearly responsible:

As we will see, in Coasian hell it is usually impossible to finger any particular guilty party, because its problems are system-level properties, driven by the interactions between firms in the system. Reductionism just leads to finger-pointing.

This model is a useful description of the federal public service, which ultimately is a collection of more than two hundred organizations, each with highly-structured internal divisions and sectors. Each of these organizations reports to an individual deputy head (in most cases, a deputy minister) who is responsible for pursuing their specific minister’s priorities and for complying with government-wide policy requirements.

In practice, doing anything substantial almost always involves a wide range of participating actors. Different sectors of a department (corporate IT, HR, and accounting; strategic policy; communications; specific operational and program areas) as well as separate institutions (Shared Services Canada, for IT infrastructure; related departments for horizontal initiatives) all need to collaborate. This environment ultimately takes the same form as the “Coasian heck” that Alex Harrowell describes: diffuse actors, limited information-sharing, complex interactions, and no clear ultimate owner if something goes wrong.

More importantly, no one in this kind of environment is clearly empowered to structurally change the environment itself. Each participating actor (each sector, silo, or individual department) has a clear picture of their existing (previously-established) responsibilities, even if responsibility for the overall outcome is diffused and unclear. Each actor’s funding and prestige might also depend on maintaining or defending their current responsibilities against changes, making them predisposed to be hostile to system-wide changes.

Strategies for operating in a Coasian heck

It’s probably accurate to say that most public sector work involves operating in a Coasian heck of some kind. As a shorthand, if you’re operating in a dysfunctional (or partly dysfunctional) structural environment, and no one involved is able to change that structure, you’re in a Coasian heck.

(Structural dysfunction could mean: burdensome or counterproductive policies and compliance requirements; broken feedback loops; ineffective service provider or contractor dependencies, and so on. There are many other kinds of organizational dysfunctions – interpersonal dynamics, for example – but we’ll leave those for another day!)

If you find yourself there, here are some strategies you could try:

Create protected spaces for pilots and experimentation. In many organizations, “pilots” are a mechanism to (at least temporarily) opt-out of established policies and procedures. In best-case scenarios, this approach can create enough organizational flexibility to deliver a prototype (or even ship it), allowing teams to gather feedback that can help make the case for maintaining that flexibility.
Gather and publicly disseminate data (the more embarrassing the better). Many structural dysfunctions are widely known and acknowledged within organizations, but not beyond. In Coasian hecks – where organizations are unable to change themselves – publicly reporting on service response times, transaction success rates, project costs, and other metrics can create external pressure to implement systemic changes.
Make decisions that increase future autonomy and flexibility to change. As Dave Thomas writes, when faced with an uncertain set of options, “take the path that makes future change easier”. Delegating authority down to lower levels of hierarchy and creating or improving feedback loops within organizations are both important ways of doing this.
Find allies and reduce external dependencies. A lot of inefficiency in government originates from organizational dependencies, and the resulting communications and management overhead of parallel and competing reporting structures. (Separate program teams and IT teams, or separate service provider departments, are both examples of this.) At the same time, finding teams with similar objectives in other sectors and organizations can help create a broader internal push for systemic changes. Researchers and advocacy organizations outside of the public service can also be important allies.
Shift the Overton window of expectations within and outside institutions. Changes within a Coasian heck result from one of two things: external pressure, or sufficiently-broad consensus on the need for change. Communicating the impact of structural issues, and the benefits of different ways of working, can help shift the “Overton window” of decision-makers’ expectations over time.

Challenging the orthodoxy

Challenging the status quo within public service organizations is hard and often lonely work. This can frequently lead to staff burnout within change-oriented digital government organizations, and within the public service more broadly.

One broader reason that change is difficult – and this is a structural issue that takes place on a personal level – is that relationships are an important form of social capital (for decision-makers and working-level public servants alike). The more that you push for change, the more you diminish your relationship-based capital. Fighting certain fights and burning certain bridges may not be worth it; at the very least, there are strong social incentives against doing so.

Public service organizations – with their job security, pensions, and comparatively long careers – tend to produce change-averse, tradition-oriented organizational cultures. They tend not to reward creative or unconventional thinking. Their size and scale, combined with a political and media environment that is unforgiving of risk-taking and failure, tends towards more blockers and fewer enablers.

Overall it’s …pretty heckish. But I’m glad that we’re talking about it!

I hope that, both inside and outside public service organizations, there’s enough advocacy taking place for things to change for the better. It’s hard not to feel pessimistic about the public service’s ability to respond to future social issues – social instability, environmental collapse, geopolitical events, at-scale disinformation campaigns, future pandemics – without substantially changing how we work.

No one person can do that, not even current or former Clerks. It will take all of us.

For more on decision-making in large organizations, Lorin Hochstein’s Moral Mazes book review and Avery Pennarun’s What do executives do, anyway? are both excellent and thought-provoking reads.

Thinking of NWT and BC wildfire evacuees

Fri, 18 Aug 2023 11:15:01 -0700

This past week wildfires forced the full evacuation of Yellowknife, the capital of the Northwest Territories, as well as many other communities both nearby and across the territory. That evacuation is currently ongoing. As of this morning an estimated 28,940 people were under evacuation orders, in a territory with a population of about 46,000 people.

Meanwhile, late yesterday Kelowna, BC residents were suddenly ordered to evacuate when a major wildfire crossed Lake Okanagan. Close friends of ours there evacuated late last night on minutes’ notice.

It’s an unprecedented summer of wildfires across the country, and as people wonder what will happen to their homes and communities (or how to rebuild them) it’s hard not to wonder what the future looks like.

NWT’s Cabin Radio – which has been providing outstanding live coverage, and deserves a CRTC license – had an interview a few days before the Yellowknife evacuation was announced with John Vaillant, who studied the 2016 Fort McMurray wildfire response and evacuations. Heather and I both plan to read his book, Fire Weather, and learned a lot from his interview about modern wildfire behaviour:

And I think that’s really what happened in Fort McMurray. So at 11am on May 3, there was a press conference – literally an hour and a half before the fire breached the city, authorities were still talking about “have a plan, get your kits ready, send your kids to school and go to work and do what you need to do, and we’ll keep you informed.” And who informed the people of Fort McMurray that there was a fire in their city and they had to evacuate right away? The fire. There was no time. That’s how fast that happened.

Something that is really difficult for human beings to understand about 21st-century fire is: it moves way faster than you think it’s going to. You see the smoke cloud on the horizon and then, you know, look at Maui in Hawaii, look at Enterprise, Northwest Territories. Look at Lytton, BC in 2021. It’s happened over and over again. “Well, the fire was over there and then suddenly it’s over here.”

Ollie, this is really important to understand: you can do a great job with the fire breaks, you can do a great job with the sprinklers, but if the wind is strong enough – and it doesn’t have to be that strong, it can be, you know, 20 or 30 km/h – the embers from that remote fire can carry right over the top. They carry right over the fire breaks, they can carry over the lines of sprinklers and land in the heart of the community and light it up if it’s dry enough. And that’s what blew people’s minds over and over again, was embers would land in the grass, embers would land in the mulch in their garden, embers would land in the gutter of their home and burst into flame. And it almost didn’t seem possible. But when it’s dry enough and hot enough, and you’ve had a summer like we’ve had – which has been bone dry and unseasonably hot, things are really dried out and primed – that’s a recipe for fast-moving, explosive fire.

There’s parallels from the Fort McMurray fire in 2016 to the rapid spread of fires this past week in NWT and BC:

How it went in Fort McMurray was: We are going to cut cat guards on the fire side of the city, we’re going to put up sprinklers, we’re gonna get some water bombers in there – and then the embers blew right over the top of that, landed in the city, ignited the city wholesale. Suddenly firefighters were just running around like a terrible game of Whack-a-Mole as entire blocks of houses burst into flames, something none of them had ever seen before or were prepared to deal with. And then it suddenly went from “we’re going to hold this fire at bay outside the city” to, in a matter of hours, “how do we keep the death toll as low as possible?”…

Canada has been extraordinarily lucky so far with only one fatality in Slave Lake, only two in Lytton, none during the fire in Fort Mac – which is practically a miracle, given the scenario and the panic that ensued, frankly, because of a delayed evacuation. This is what has happened in the past, and Yellowknife shows many of the characteristics of those communities. And the weather has not been kind.

As the evacuations in NWT and BC continue we’re thinking of friends and family of friends who are part of it. We’ve had a number of friends reach out asking how Heather and I are doing (which is very kind!) but we’re in the other territorial capital that starts with a colour and ends with a noun. It’s confusing. There are active wildfires across the Yukon but at the moment none in threatening range of Whitehorse.

A photo from 2020 of burned forest near Mayo, Yukon from a 2019 wildfire.

We’ve had an emergency “go bag” packed since 2020 when we listened to a podcast on earthquake dangers in Los Angeles and got (healthily) spooked. The Yukon government has helpful instructions on what to put in an emergency kit. (Outside the Yukon, what you’d need in your region or community might differ; you can look these up on your province or city government’s emergency management websites). But this past week was a good reminder to refresh it, add baby clothes and gear for Ben and make sure we’ve got everything we need for a long-haul evacuation, if that becomes a necessity in the years ahead.

In the meantime, we’re really grateful for all the efforts of fire response and emergency workers, and we’re thinking of everyone in NWT, BC, and everywhere else affected by wildfires. All the best from here.

For updates on the NWT evacuation efforts, follow CBC North or Cabin Radio (directly from their websites given that Meta is blocking news links on both Facebook and Instagram). To support NWT wildfire victims, you can donate to a friend of a friend’s NWT United Way fundraiser here. And: everything Lyn says.

Hellos and goodbyes

Tue, 15 Aug 2023 21:20:10 -0700

This past week I started work with the Government of Yukon, wrapping up almost seven years since rejoining the federal government and the team that became the Canadian Digital Service.

In my new role, I’m the open government program manager within the Yukon government’s eServices for Citizens branch. Part of my responsibilities will be the Yukon open government portal, along with supporting a number of initiatives that the team has on the radar. eServices is a really outstanding and welcoming team; you can read about what’s on the go in a team blog post from earlier this summer. There’s a lot happening!

Open government and open data work is (as you can guess!) a topic very near and dear to my heart, and I’m thrilled to be able to work on it here in the territory.

The S.S. Klondike National Historic Site, around the corner from my new office.

It’s bittersweet to wrap up with the Canadian Digital Service; many of my closest friends and most inspiring colleagues are current or former CDSers. It’s also a pretty noteworthy time of transition for CDS as it moves from its current parent department (the federal Treasury Board Secretariat) into Service Canada. Kathryn May has a great write-up of what this could involve, including some of the opportunities and pitfalls. It’s something that I’ll follow with a lot of interest and encouragement from the outside.

In the months ahead I’ll be reflecting more on the past several years in the federal public service, and I hope to pick up the pace of writing and blogging here! If you have ideas or suggestions on topics to write about, please give me a shout anytime.

Public service tech tip: Get yourself some good audio gear

Mon, 26 Jun 2023 12:52:38 -0700

Hybrid work is here to stay, which – for all of us as public servants – means a lot of hours in Teams meetings. (Or Zoom or Google Meet or your organization’s videoconferencing system of choice.) Whether you’re at home or in the office, chances are good you’re tuning in to video meetings on a very, very regular basis.

We’re all getting better at un-muting before we speak, but even a few years into this it’s rare to go a week without an “I can’t hear you” or a “your sound is breaking up” or a “can you say that again?” Audio quality! It is a precious thing. You can run a meeting and have a conversation with glitchy or frozen video feeds, but if you can’t hear people, you can’t get anything done.

If you’ve ever had someone say “can you repeat that?” on a video call, this post is for you. Here’s the counter-intuitive thing. With just the normal speakers and microphone in your work laptop or tablet, chances are good you can hear other people. Crank up the volume, no problem. No one can hear you, though. There’s no obvious feedback loop if your own microphone and audio setup isn’t working great, aside from your colleagues and friends telling you that you’re hard to hear.

If you’re in a leadership position, then it’s even less likely that someone will have the confidence to tell you that your audio is terrible. Feedback on how you sound is a gift; receive it gracefully and pass it along gently if you’re having trouble hearing other people.

Fortunately, there are solutions! Which you can purchase, thank you consumerism, for fairly cheap. Here’s some examples that I’ve found work well in my own experience. Read on and find the option that works best for you!

From left to right: a Jabra 510, a Sennheiser PC-8 headset, and an iPhone sitting on a portable phone stand with a headphone jack adapter and wired headphones plugged into it.

The Jabra 510: The conference room champion, and/or you don’t like headsets

I’ve got Ross Ferguson to thank for this one, which he brought along from GDS when he joined CDS. We were just beginning to operate as a distributed team, and this little tabletop audio puck blew all of our minds.

To this day, I’ve never found a better speaker/microphone combo. If you’re huddled in a meeting room with two to eight people, it works like an absolute gem. People on the other end of the line can hear everyone in the room, not just the person who is closest to the laptop. Roll up the little USB cable and bring it wherever you go.

A Jabra 510 (with a USB-A to USB-C adapter if you need it for your device).

The Jabra 510 is also great outside of work; my wife and I bought one to chat with far-away family and friends. Once you get one, you’ll immediately start trying to convince everyone else you’re talking to to get one too. That’s what happened to us, at least.

The Jabra 510 is particularly good at filtering out ambient sound (more on that below). If you don’t like to wear headsets or can’t find a comfortable one, it’s a great choice. You can leave it plugged in on your desk – even if it’s just you using it, not a whole meeting room – and people will be able to hear you much more easily than if you’re using your computer’s normal microphone and speakers.

The Sennheiser PC-8: Hello, fellow committee people

Back in November, Prof. Clarke and I were invited to chat with the Government Operations committee of the House of Commons. The House of Commons committee clerks and AV staff are fantastic, and also very particular about the audio headsets you use. They have to have wires, probably because one too many committee witnesses dropped out halfway through an important discussion because their wireless headset batteries died at just the worst time.

The House of Commons has a list of approved wired headsets. For a moment I was like, “really? my old Logitech H800 wireless headset works pretty good, should be fine, right?” and Lucas thoughtfully reminded me that if anything went wrong, tech-wise, it would be better to at least have used the approved equipment.

A Sennheiser PC-8 wired headset.

I bought a Sennheiser PC-8 (one of the approved headsets in the list) from the Staples in Whitehorse. It plugs in with a USB cable. The headset seems flimsy but the audio works great, and after using a wireless headset for years I suddenly realized how nice it is to not have to remember to charge it. You just plug it in, and it works. There’s a physical mute switch on the cable, which could be handy but is also worth remembering in case it gets switched accidentally in your bag and no one can hear you.

If you’re having video meetings in an in-person office, you might want a headset with more noise cancelling features than this headset (it’s one of Sennheiser’s cheapest products). But for meetings from a quiet room at home, it’s a solid choice.

The iPhone headphone adapter dongle: You’re on your phone and on the move

If your department issues you a work phone, and you can access Teams or whichever videoconferencing system your team uses on it, it can be a really handy go-to device.

I recently got issued a replacement work iPhone (my circa-2018 work phone was being end-of-lifed) and I was floored at how well the Microsoft Teams iPhone app works. My beleaguered Surface Pro work computer struggles to keep up with any Teams meeting with more than one other person; the Teams iPhone app cruises along incredibly smoothly.

One benefit of joining Teams meetings from your work phone is that you can then use your regular work computer to take notes or review meeting documents. From the Teams desktop app, you can also “Add this device” once you’ve already joined the meeting from the Teams iPhone app. That can be handy if anyone is screen-sharing a Powerpoint presentation or other document (so you don’t need to squint at your small phone screen). Meanwhile, if your work computer crashes unexpectedly, you don’t drop out of the videoconference call.

If your department didn’t send a pair of headphones with your work phone (or if they’re terrible), then you can use any microphone-equipped headphones you have lying around by buying an adapter dongle. For iPhones, that’s this $10 Lightning to headphone jack adapter that you can buy directly from Apple. If your work phone is a recent Android device, then you might need a USB-C to headphone jack adapter instead.

An iPhone sitting on a portable phone stand with a Lightning-to-headphone jack and wired headphones plugged into it.

You can buy headsets and headphones that connect directly with Lightning or USB-C cables, without an adapter dongle; I personally prefer traditional headphone cables (partly so I can use the same headphones with my computer) but if you find one that works well, awesome.

Apple AirPods also reportedly work very well, if your work phone is an iPhone, but they cost, er, more than the $10 headphone adapter does.

If you’re regularly joining meetings from your work phone, another helpful piece of gear is a portable phone stand. My genius colleague Lesley suggested this foldable phone stand, which is heavy enough to not wobble around and light enough to toss in my bike bag. It’s been a real game-changer after months of just haphazardly propping my phone up against a water bottle and hoping for the best.

Why does this matter?

Using a headset or headphones – instead of your phone’s speakerphone or laptop speakers – makes it much, much easier for other people to hear you.

If you’re not using a headset or headphones, then your phone or computer has to struggle to filter out both the ambient sounds of the room, and the audio coming from your colleagues on the other end of the conference call. That makes it much more likely for you and your colleagues to interrupt or speak over top of each other, or to miss key sentences and words as your phone or device struggles to keep up.

If you’re in a meeting room with several colleagues who have all connected to the same videoconference call, you might also experience the loud whine of feedback as audio coming out of one computer or phone’s speakers is heard and amplified by another computer or phone’s microphone – and then comes out of the first computer’s speakers again, in a cycle that very quickly gets louder and louder.

There’s two ways to prevent this feedback whine: one is to make sure that only one device’s microphone and speakers are active (every other device should be both on mute, and with the speaker volume turned down to zero).

If your videoconference app supports it, you can also join a meeting without any audio enabled (for example by using Microsoft Teams’ “Add this device” option or Google Meet’s “Companion mode”), on every device except the designated audio device that you’re listening from and speaking into. Just having one computer or phone active applies whether you’re using the built-in microphone and speakers or an external audio device like the Jabra 510 above.

The second option to prevent a feedback whine is for everyone present in the meeting room to use headsets or headphones (literally everyone!). That way, there’s no “ambient sound” from the videoconference call in the room. Everyone listens on their headphones, and speaks into their respective microphones when they’re contributing.

The first time I saw this in practice was when the Ontario Digital Service first started working distributed across Ontario, several years before the pandemic. The meeting principle they shared was: “if anyone is distributed, everyone is distributed”. ODS will hold meetings with their entire team where everyone is joining in on their work phones with headphones on – even with dozens and dozens of people in the same meeting rooms, others joining in from satellite office meeting rooms, and others yet joining from home. It might seem strange at first but it makes it really clear and easy to hear everyone, and makes sure that people who aren’t in the “main” room don’t miss out on the conversation. It lets everyone contribute equally to the meeting, no matter where they are physically located, which is a great approach.

A videoconference call with the Ontario Digital Service in October 2017, hosted by the brilliant Alex Lougheed.

The Ontario Digital Service has a series of fantastic Working Remotely blog posts, published in April 2020 but still really useful. Highlights include Leading Distributed Teams, Working Remotely, and Running an effective virtual meeting.

What’s next?

Go buy yourself a Jabra! Or a wired headset. Or an iPhone headphone adapter dongle. You don’t need permission (unless you work in a conspicuously high-security organization) and it’s a worthwhile investment. Just go to your local electronics shop or buy one online from a reputable brand and pay for it yourself. It’ll be handy wherever you go in your career and wherever you work from.

Like I said off the top: this is about making it possible for other people to hear you better. Even if you can already hear your colleagues really well, just using your computer’s normal speakers, that doesn’t mean that they can hear you.

Get yourself some good audio gear, and ask your colleagues and friends on video calls if they can hear you better. You’ll be surprised at the difference it makes. And then you’ll try to convince everyone you know to get better audio gear, too.

Public service heroes: Deepika Grover

Thu, 04 May 2023 10:25:40 -0700

Deepika Grover is a strategist at Finance Canada, a member of the Free Agents program, and a long-time practitioner and advocate for equity, inclusion and anti-racism work in the federal public service. She’s previously worked at the Public Health Agency of Canada, Canadian Heritage, Global Affairs Canada, and the Privy Council Office. Deepika has played a role in many of the public service’s innovation programs over the years. And if you’ve heard of Tiger Teams, you can thank Deepika for this as well. We’ve been friends on social media for many years and I’m always grateful for her thoughtful and candid insights on how to make the public service better. We chatted by email in February, followed up by virtual convos in April and May.

How did you get started in the public service?

Early in my undergraduate in Ottawa, I found work through a temp agency. One assignment was as an administrative assistant at the Pest Management Regulatory Agency. It was a really short stint, though. I didn’t really get a strong flavour for government work per se. I did get a strong sense of the people who served as public servants. They expressed a lot of curiosity and interest in the world around them. I liked the daily news clippings, as well as the resource library with all the books about leadership and strategy. I’m a big nerd, and I could see that these folks were real nerds too.

Later in my undergraduate, I learned from friends about a contract position in a government department, as part of the news clippings team. They always had trouble finding folks because the work shift was from 5 to 9am and, quite frankly, the manager was a real jerk (or as I like to think, ‘not a morning person’). I loved newspapers, and I’ve always been an early morning person. I was all in! We were a team of three people, plus the manager.

The job was to go through a selection of French-language and English-language Canadian and key international daily and weekly journals, looking for content that either mentioned the Department or would be of interest to the Department’s branches. We’d each choose a bunch of papers and go through them page by page. When we found articles of interest, we’d use rulers (!!) to cut the articles out. There was lots of repetition of stories across publications, so as a team we’d go through a collaborative sorting process, creating a thick, book-like package with sections. We’d take the packet to a small photocopier and create a primary copy of the day’s booklet, plus two additional copies. Each team member would take one copy and go to these massive photocopiers, and we’d produce the required number we needed for our ‘delivery routes’ through the department.

My teammates were amazing, I learned a lot about teamwork (we had a scrum every morning and there was a quality assurance component, too, as it wasn’t unusual for an article to get missed here and there); iteration; team process and group dynamics; as well as how to deal with a difficult manager. And there was something really satisfying about being part of an invisible support system for all the good work that public servants would undertake that day.

I hadn’t started thinking analytically about systems yet. That would start later in my graduate work, during field research. But I had already started thinking about how producing the news clippings allowed me to be part of something bigger than myself. Plus, I really loved being done with a shift of work early enough that it didn’t interfere with my studies, socializing with friends, or my other part-time gigs.

Tell us about an inspiring (or memorable) moment in your public service career.

Working in the public service comes with diverse and weighty challenges. Part of my own spiritual values encourages me to stay healthy in the face of challenges by balancing two things: (1) being eyes.wide.open, and (2) staying connected to daily inspiration, small moments of authentic joy and everyday awe. (I share this latter element cautiously because I really don’t want it to get mistaken for toxic positivity.)

A lot of my inspiration comes via people, and am really fortunate to have a close network of peers and colleagues. These folks add sparkle to my day just by being who they are and how they are in the world. They also make me feel seen, whether it’s a good day or, more rarely, a bad one.

I’ll share a moment that really stands out for me. I was co-lead on a digital innovation project. I provided policy innovation expertise, while my co-conspirator brought fabulous, forward-thinking IT expertise to the table. We are both strong proponents of systems change, open-policy making, and open government. We were excited to work with each other, and especially excited about the project. We were on-boarding a new AI technology for use in government public engagement, ensuring that the platform complied with GC requirements, like data, privacy, accessibility, official languages, etc. A gargantuan task at the best of times, and we were working on very tight timelines.

We had assembled, at one weekly table, all the functional specialists required to help us rapidly move the project forward. The rate of attendance, participation, and collaboration was high. Friction was fairly low. Most people were happy, and so was I.

During the weekly meetings, though, I noticed that my co-lead would occasionally interrupt the conversation in specific ways. Particularly, he would ensure that men weren’t talking over women (not that there were many of us at the table) and that people’s contributions were acknowledged. He interrupted because I would sometimes say something and get no response from colleagues, only to have a man repeat the exact same thought 10 minutes later and spark lots of responses and affirmation. It’s not that I didn’t notice, or that it didn’t irritate me. I did. It did. But I love collaboration, there were many other things competing for my attention, and I can sometimes be so in the moment that I tend not to let myself get distracted by friction. But this means I also didn’t really see the pattern.

My co-lead’s actions changed that. Without fail, anytime I was interrupted he would graciously and firmly re-assert space for me, and he also always corrected attributions: “Thanks for raising that, Bill. I think Deepika mentioned it a few minutes ago and also shared…” I started to note how often it was happening, and started to think about how I, myself, could practice making similar space for others on different working groups and other teams.

My co-lead was never pointed or weird about it, just matter of fact. I asked him about it once and realized he was barely even aware that he was doing it. For him it was simply a matter of fairness. Perhaps he is inclined that way… and it is natural to him. There are a few rare humans around who are just like that; their hard-wiring is fair and it informs their way of being every single day. More likely, he learned practices that contribute to an orientation to equity. Either way, it is inspiring and helped me build a stronger equity practice.

You often hear the inquiry “many folks can talk the talk, but can they walk the talk?”. Underpinning this is the difference between espoused values and enacted values. My co-conspirator lived his values. In doing so, he showed me that it really is just that simple to use one’s unearned privilege to level a playing field and create an equitable outcome.

He also reminded me of the power of positive micro-actions, or what adrienne marie brown calls fractals, which encompass the interactions between two people or small groups of people. If you can contribute to creating equity at the scale of a dyad (two people), you can imagine how it can scale upwards and outwards.

There’s a lot to unpack in that memory, and some of it is less inspiring. At the same time, my colleague really respected and appreciated working with me. He valued me as a leader. He made me aware of something that is likely happening during the thousands upon thousands of GC discussions that take place on a daily basis. I myself am part of many discussions each week. And drawing from his inspiration, I am more attentive to the gender and racial dynamics around meeting tables, and, alongside my more non-nonsense persona, I also have some very easy, gracious ways of interrupting patterned ways of being and working with others. It might lead to a greater sense of belonging, more social cohesion, and more equity.

If you could wave a magic wand and change one thing about government/the public service, what would it be?

I think we understand this system – the government, the public service – from where we are in it, what we do in it, and what the consequences are of what we do. At this point in my career (I’m at the 15th year mark), here’s what I know: everytime I push against the system, the system reveals something new about itself. So, in the past, when I’ve asked myself this question, the answers have included:

Risk – Senior people have often said to me, “Canadians would never tolerate that risk.” I’ve often responded “how do we know what risks Canadians will or won’t tolerate? Have we asked them? Have we, as a society, had a collective conversation about risk?” It has always felt to me that this would be a good idea, especially as our social problems reveal themselves to be more and more complex.
The paradox of change and hierarchy – I suspect that the way we approach change as something that is managed and planned through working groups and cascading plans and templates might be getting in the way of actual change. Change seems like it’s a fairly every day human experience. Why is it so consistently painful in the public sector? I’ve noticed patterns. There’s the obvious: persistent conflation of incremental and transformative change. But, also, other patterns. Figuring out what needs to change and reaching consensus on this can be hard. At the same time, even when there is upfront agreement that specific change is required, this somehow gets forgotten when, in a project, new options are finally on the table. Attachment to the status quo is very strong and it fairly persistently manages to hijack critical thinking, including openness to new ideas and ways of doing things. Then we end up with rigid, change-resistant structures and a few people delegated to guide template-driven ‘change’ that barely yields any new or different results, much less desired ones. There’s a lot going on in this set of system dynamics… so, it would have to be a very strong magic wand that effectively unblocks the change pipeline.
I have noticed a contradiction in the nexus of change resistance that has been striking. It’s in relation to hierarchy. Even when calls for change come from the very top of an organization and are supported by its grassroots, actual change can be thwarted by activated middle layers. It’s a paradox, in an otherwise arch hierarchy, that the middle layers are often the very enforcers of said hierarchy when it comes to their power over, and also the resisters of change desired or mandated by the senior officials to whom the middle layers report.
This has always puzzled me in my public sector innovation work. There I could see some of the emotions at play, but now as I watch organizations struggle with hugely complex issues like COVID, legacies of structural racism in our workplaces and in society writ large, and complex consequences of climate change I see it more clearly: we don’t take seriously the emotions connected to change, such as fear, but also – and more profoundly – grief. Just as we don’t take seriously the structural power invested in the status quo.
Traditions – I also pondere about those structural elements that hold things fixed in place, from the Westminster Model to meritocracy to impartiality to neutrality to objectivity, etc. and the many rules that codify these elements into our institutional realities. It’s past time to question everything. It’s not only about asking “show me the rule” but also about questioning the provenance of actual rules. We have a lot of defaults that are past their best by date. At best, they pose barriers to real progress. At worst, they have and continue to cause harm, and they are based on assumptions that arguably may have once been tenable, but likely would not bear weight under critical, multi-perspective scrutiny.
I always understood that “doing things because that’s what we’ve always done” was problematic, but it’s taken me a few more beats to truly understand that this way of being, which is like oxygen in government organizations, is actually the very opposite of due diligence and critical thinking. How might we make questioning everything a rooted practice in government?

I could go on… But for me, it’s been valuable to connect with more systems thinkers and systems change agents, and build practices based on what I learn alongside them. If challenging the system is what’s necessary so that the system might reveal more of itself to us, finding ways to share that social intelligence may be the closest we get to a magic wand.

But if I did have an actual magic wand, I would no doubt use my one swish of a magic wand to put magic wands in the hands of every equity-denied federal public servant and the wands would work in the following way. A wand swish would be credited to a person’s wand for the following: every act of solidarity they undertake, every time they express courage, and for every time they experience harm. The latter happens so often that the number of wand swishes would accrue rapidly. And the wand holders could use their accrued wand swishes to achieve their desired level of work potential without the imposition of stark structural barriers. Those magic wands can serve as a proxy for unearned social privilege experienced in the public service by cis-gendered, heteronormative, able-bodied folks that are racialized as White, while also recognizing the innate excellence and agency of public servants who belong to groups that have historically been denied equity, and who are, in an on-going way, affected by the continued consequences of such unequal historical legacies.

Solidarity with PSAC workers

Wed, 19 Apr 2023 00:05:57 -0400

Update: As of May 1, 2023, a tentative agreement was reached between PSAC and TBS. You can read more about the agreement on the PSAC website. On June 23, the agreement was ratified by the federal government after being previously ratified by members of each bargaining group.

Today the Public Service Alliance of Canada (PSAC) began strike activities. With more than 155,000 participating PSAC members, it’s one of the largest strikes in Canadian history.

PSAC’s Frequently Asked Questions page provides details on the bargaining process and on strike activities
TBS’s Collective Bargaining page includes news on collective bargaining negotiations
The Canadian Association of Professional Employees (CAPE, my union as an EC employee) has a useful page outlining its members’ rights and obligations when another union is striking (if you’re in another collective bargaining group, your union might have similar information available)
The r/CanadaPublicServants Reddit community is an excellent, unofficial resource for strike-related information (along with other discussion topics)
Kathryn May’s Policy Options newsletter is also an informative resource for public servants and the general public alike

I’m grateful that PSAC is advocating for stronger remote work provisions (which will ultimately make the federal public service more effective and more representative), alongside other important considerations to support Indigenous employees and Veterans Affairs case workers.

Public sector collective bargaining (although it’s often slow and cumbersome!) helps raise the bar for workers’ wages and rights across the country. Strike action will likely be a challenging time for PSAC workers, but it makes a difference for all of us.

Public service heroes: Nick Wise

Tue, 21 Mar 2023 08:58:58 -0700

Nick Wise is a long-time technology leader in the Canadian public service, most recently serving as the Chief Information Officer of Public Safety Canada. Previously as an executive director in the Office of the CIO, he was responsible for the GCtools team and for the small team that became the Canadian Digital Service. Nick and Ryan Androsoff brought me into the federal public service during those early days, beginning a fascinating journey to try to change government for the better. I’ll always be grateful for Nick’s insightful and humble style of leadership, and for his thoughtful stewardship of the teams he led. We chatted by email in October.

First, thanks for the opportunity to pause and reflect, Sean. Actually, I am poised to retire from the public service so the timing is great as I am at that confluence – looking back on years that have helped define a good deal of my contribution and identity, professionally, and looking ahead and contemplating where next to devote meaningful time and energy. As Monty Python would say, “and now for something completely different”!

How did you get started in the public service?

It has been a very rewarding career, I have to say, in all sorts of ways. I think the interest in working in some sort of public service capacity was always there – government or non. Devoting time and energy to a career that was more about service and contribution than it was about selling stuff always struck me as ultimately more satisfying and meaningful.

Interest in government and governing specifically grew throughout university which began at Queens in English Lit, proceeded with a BA in Middle Eastern Studies at McGill and concluded with a Masters in Poli Sci/Public Admin at Concordia. Concordia offered a paid internship option for credit which at the time was quite novel and so I got my start with the federal government as a student policy analyst.

What cemented my position and, in many ways, passion was the Management Trainee Program (MTP), now sadly defunct, which nurtured an important sense of pride and purpose and responsibility in the institution of the public service, and our contribution to it and through it to the country. I also liked the fact that it drew in a really diverse group of new recruits who brought different backgrounds, experiences and perspectives into the ranks. It made for an interesting group and a much more stimulating experience. The MTP was about recruitment, succession planning and management development, but also about shaking things up a bit by injecting the system with new ideas to test and challenge convention and orthodoxy.

That formative experience marked me in a way that has stayed with me over the years. Change and challenge is good, is necessary. Embracing the unfamiliar, trying new things, looking at things differently through new lenses.

Part of the appeal or at least realization stemmed also from my own experience adapting to new countries and contexts, as an immigrant to Canada, then living for a few months in a village in rural Pakistan as part of a youth exchange program, travelling a lot, then getting married young to a Québécoise and moving to Montreal and becoming a father while still a student. As a young man these experiences molded me in ways that were hard, but ultimately incredibly rewarding.

For me, much of the enjoyment and satisfaction I have had in my public service career can be traced, I think, to this impulse – embracing new realities, new perspectives, and challenging what is normal or expected. If a job started to become too routine or comfortable or if my contribution to it became too automatic, conditioned by accumulated experience or received wisdom, then it was time to change. Fortunately, the ‘Service’ always accommodated – there are so many interesting places to go and things to do and people to work with across the federal government!

Tell us about an inspiring or memorable moment in your public service career

As regards inspiring or memorable moments, there have been many, thankfully. I think the best times have come with the challenge of introducing and cultivating new initiatives without any real guidebook – working with a team that has conviction, creativity and talent, and figuring things out as we go.

The real motivation for becoming an Executive was essentially to obtain the trust and latitude and resources required to do more of this. Working with you, Sean, and other members of our happy band we helped advance thinking in government at “the centre” about service in the digital era. That was incredibly rewarding and memorable. Operating within TBS – from within the ‘house of rules and protocols’ – was challenging, but it made the impact and legacy all the more significant.

Before working on the Service Policy I had been hired into TBS to work on what we called ‘the web of rules’ initiative, cutting red tape, simplifying policy instruments and hunting down mythological, needless regulations and controls (whose origins likely began as a response to an exceptional issue, perhaps put in place by a risk-averse manager, and then became entrenched). It was a great place to develop a critical yet respectful and constructive perspective on how to influence public service culture from inside the central agency. It was a fertile and transformative and important opportunity, which was a good staging ground for subsequent work in the digital service space.

Ultimately though it was the energy and creativity and commitment of the team that was outstanding and led to great things. The legacy stands with the introduction of new tools and institutions to inform new thinking and behaviours, but it’s the informal moments shared with teammates on the journey that impress the most. Literally, in the case of our happy band travelling across the country gathering ideas and consulting to inform the establishment of the new Canadian Digital Service.

Informal moments and personal relationships count too, of course. Plying Mike Bracken (the ‘godfather’ of digital service in the UK) with beer at a bar on Preston Street in return for his perspective on GDS in the UK, which led to meetings in London alongside Yaprak Baltacioğlu was memorable and decisive in the establishment of the CDS in Canada. Meeting Alistair Croll and Phil Telio at a restaurant on Greene Avenue in Montreal to hatch the idea of what has become FWD50 as well. The name derives from conversations with the team brainstorming about how to bring non-technical policy folks to a conference on digital transformation, by imagining what we wanted Canada to look like in 50 years and then mixing things up, with technology experts and policy experts looking at solving a broad range of issues together.

These moments were important and defining in many ways, but decisive because of the people involved – leading, exchanging, formulating, figuring things out.

If there was one thing you could change about the public service, what would it be?

These experiences that we shared underline for me what is ultimately the most important thing in government, which is to bring different people together, motivate them, trust them, protect them if need be, create an enabling environment and then get out of the way.

This has been reinforced during my time at the Department of Public Safety as CIO. Part of my responsibilities at TBS included community development for CIOs across government, but after a while, I thought, to really understand the challenges they face in the era of digital service, I should actually try and do what they do.

When the opportunity arose, I took it, recognizing that my experience and credibility were going to be stretched to the limit. However, we had been preaching the need to mix things up, to cross-pollinate, to break the leadership silos between the warriors of policy and programs and the druids of tech, so I thought I would give it a go.

It was hard, but as mentioned earlier seeing the world through the lens of a CIO was a revelation. The experience at Public Safety has been probably the most challenging and ultimately the most rewarding of all. This is in part due to my personal growth in that role, and in part because of the strides we have taken to advance digital transformation at that complicated department. Most of all it was because of the culture created: bridging in new, diverse talent and forging collaboration with seasoned techs, providing opportunities to bring in new ideas, creating an environment where the dynamic and complex nature of technological transformation is humanized and made more real and responsive to the needs of policy and program colleagues, introducing a Client Experience Officer position to channel the perspectives of those we serve and support into the digital agenda.

This work is about blurring the edges and breaking silos and exploiting the friction that occurs to question traditional ways of working and serving. It’s about seeing beyond boxes and org charts and testing new perspectives. My young admin was provided an opportunity a year after being bridged in to switch out and serve as a junior IT employee based on her interests and aptitude, if not her formal qualifications. She is now a rock star in our IT desktop enablement team, and personifies the spirit I am talking about.

It comes at a cost sometimes, because change and transformation are hard, and frustration can result. But if you are open and authentic and enthusiastic, lots can be accomplished. As such, it’s not that I would change things in the public service, but I would push for more promotion of environments that enable greater collaboration and cross-training and shared experience – to break down silos, challenge convention, better understand potential, to demystify functional realms and to promote empathy.

This can be across and within organizations, occupational categories, up and down hierarchical structures. Understanding, discovering and learning together more holistically is key, crucially at a time when, as I bow out, the world of work in the public service and indeed the world it serves is undergoing such dramatic shifts and will require certain conventions and orthodoxies to be challenged and re-conceived.

Public service heroes: Shannah Segal & Sheena Samuel

Wed, 15 Feb 2023 07:59:11 -0700

Shannah Segal and Sheena Samuel lead the experience design and technology chapters, respectively, at the Ontario Digital Service (ODS). They’re brilliant and thoughtful leaders, and have brought experience from their careers in the private tech sector into government. Friends all across ODS speak very highly of working with them, and it was a real honour to hear about their experiences over the past nearly five years working in government. We chatted in late October. (Views here are their own.)

Sean: Let’s start with, who you are and what kind of work you do at ODS!

Shannah: I’m Shannah Segal, and my official title is Senior Manager of Experience Design. I lead the experience design chapter at the Ontario Digital Service.

My team is comprised of service designers, UX designers, and user researchers, and we work across the government to help teams in our ministry and also inside the ODS design and research and build digital products, with a user-centric perspective.

The team is a good size, especially for a government team. We hover in between probably 27 and 30 people, and a third of those are the co-ops and interns who live in our lab. We have a unit called the XD Lab, which is part of the experience design chapter, and that usually has about 7 to 10 co-ops and interns who rotate in and out, on 4- to 16-month rotations. That’s the chapter.

Sean: That’s awesome! That’s a really cool approach. Sheena, how about you?

Sheena: I lead the Technology chapter within the Ontario Digital Service. I manage a team that comprises developers, engineers, DevOps engineers, architects, and QA automation engineers.

It’s slightly different from experience design in that we work on actually building the products, we’ve got about 15-plus products in our space. The team members are cross-functionally deployed across the team, providing different types of technical expertise.

Sean: That’s very cool. Super big fan of both those fields of work!

Shannah, why don’t we jump back to you and talk about, how you got started in the public service?

Shannah: Yeah! So actually Sheena and I started on the same day.

Sean: No way! Outstanding!

Shannah: It’s been about four and a half years now, it’ll be five years in April.

I entered a competition; basically how I found out about the Ontario Digital Service was – I used to run a company, I had my own company, with two outstanding partners. It was a user experience, design and strategy consultancy firm. It was quite small, about 20 people. We ran it for a pretty long time, about 15 years.

But then markets changed, enterprises changed, and small businesses in that sort of agency field were getting fewer; many of them got bought by other companies, et cetera, and it sort of came to pass that from a business perspective it was looking like we would’ve had to change a lot of our business model to remain viable. Also we had been doing it for 15 years! Running an entrepreneurial small business for that long can be quite exhausting.

So it was sort of, time to move on. And the question in my mind was: what do I do afterwards? Because it was a bit of a career-changing moment, or at least a moment of examination and reflection. Like, it felt very much like one chapter was ending; what was the next chapter going to be?

And I thought about the kind of work that I really liked doing when we were consultants, and it tended to fall into the philanthropic, education, social enterprise realm. We did a lot of work for for-profit industry as well like travel, airlines, tourism, retail, financial… most of it was financial, to be totally honest, since that’s where the money is. But that wasn’t as satisfying as the other stuff we did. So the question was: how can I gear the rest of my working life to something that had more social impact?

So I started looking into organizations that were in the not-for-profit realm, and then coincidentally at the same time – because our company had shut down – all my colleagues landed in different spots, and a few of them landed in the OPS [Ontario Public Service] and the ODS was kind of, just at the end of its first year by then, so they were on a growth path. Through coffee chats I met some of the folks who used to work at my company and who were now working at ODS, and that was my intro.

I went through the very long competition process – which took forever – which was a complete shock to me. Like, what?! Four months? And then I learned afterwards that four months was like lightning speed for recruitment.

Sean: Such a good point!

Shannah: And that’s how I ended up here. I liked the ethos. I met Hillary and was immediately star-struck, so that was great. There was a big focus on servant leadership, at the time, that was very very important. And that’s how I ended up here!

Sean: That’s so cool, that’s awesome. Sheena, how about yourself? How did you get started – starting on the same day!

Sheena: It’s been an exciting journey. Looking back, my story is slightly different in that I was working in tech companies in leadership at different levels.

I had some experience working in more than six industries, including finance and tech. I’ve worked in a large organization with a narrowly defined role, and then pivoted to a startup environment where you get to do everything on your own. I realized then that while I enjoyed the fast pace I really needed time to think. This led me to define the type of role, pace and breadth that suited me. That led me to ODS.

Sean: Cool, for sure.

Sheena: I was passively looking for interesting opportunities with the phrase “servant leadership” and ODS jumped out.

Sean: Nice!

Sheena: I was like, this looks interesting!

I was all excited seeing the job description, then the Medium blog, and was like, wow! And the one thing that clicked then was: it’s the government. I just clicked on the site and it redirected to their government jobs website, and I was like …uh-oh!

Shannah: But you still applied!

Sheena: Yes! The fact that the job resonated – putting the fact that it was government aside – I thought, let’s give it a chance, see how it goes, and, as a result, I was pleasantly surprised.

I met with Hillary and was inspired by her vision for digital transformation. And the work! I think the work was really interesting too in that it was very much about scaling. So there was a role that aligned with my skills and a unique challenge in a sector that was new to me.

Servant leadership and scale, those were the things that brought me here.

Sean: That’s super super cool. It’s really cool to hear people’s starting points into this work in government, I find super fascinating.

Shannah: And yeah! Both of us were a little unique, like, neither of us have had any jobs outside the ODS (in government). Our perception might be coloured by that!

Sean: That’s super legit, for sure! Why don’t we jump to the next question, tell us about an inspiring or memorable moment in your public service career?

Shannah: Yeah, wow. There’s been so many, I mean, that’s actually a really hard question.

Sean: Sorry!

Shannah: There’s a lot of small moments. One thing I realized is, working in government is more about the cumulative small moments than it’s about, like, some big bang, since those don’t tend to happen that often.

It’s really more like, incremental change slowly over time, and then you can look back and see, oh wow, we really made a difference.

That said, I will say that joining and then two years later – maybe not even two years later – entering the pandemic, was a real eye-opener. I had wanted to do work that makes an impact and that is meaningful to society, and then, like, bang. I was in the Ontario Together “we have to get gloves to every single hospital now –”

Sean: Wow, yeah. That’s real heavy.

Shannah: Yeah. I was kind of not thinking that much impact, but, it happened! So that was quite a journey.

We were working on all the procurement of PPE, and the digital tools that would help source and distribute all of those, and you really did feel like you were making a difference. Because it was like: I’m helping get this sanitizer and masks and, unfortunately, heart machines and body bags from factories to hospitals. And you really felt like you were right in it. I think that was definitely part of it.

But then if I was going to look at something that was more of that, looking back over time, a thing that was really great – I’m going to have to go with the design system. We have an Ontario Design System which is a digital tool that helps all the designers – and all teams across the government – make things that are consistent and use the same visual standards and use the same code, all that kind of stuff.

Sean: Really big fan.

Shannah: That was a side-of-desk co-op project in my first year, and now it’s a fully-functional product team with proper release cycles and full-time staff and the whole thing. And four years (for that) is not that bad. It’s a lot of achievement for four years.

Those are two moments that I’d point to.

Sean: Cool, that’s awesome. Sheena, how about you?

Sheena: Very similar to Shannah – we worked on similar products side by side, so we have similar stories. Design system stands out to me too, when it started it was small and scrappy.

One thing looking back we recognize that – those two years before the pandemic were crucial to letting us scale, by building that bench strength. You don’t necessarily see that; by the time it arrived we had the people, skills, and the vision.

Nobody planned for the pandemic. However, we had that agility and strength, and that’s mainly because there was some groundwork laid. Not just by us, but our predecessors as well. We reused our learnings and rebuilt products – that helped get us there. The biggest work was actually around our talent.

The other example I’d have is Verify Ontario. I appreciate the public side of it, seeing the announcements. But it was more than that, seeing a team come together for meaningful work, and they’re all proud at the end, saying, it’s what their kid was talking about when they went to a restaurant, proud that their mom built it, that kind of thing. Stories like that are more important to me as they resonate deeply about the type of work we do: work that touches Ontarians every day.

Shannah: All the stuff we did during the pandemic was so impactful. Like the self-assessment screener, the school screeners… all those things that we saw people using every single day. We were like, wow, you know, we helped build those. That was pretty mind-blowing really, when you thought about it.

Sean: Like seeing your work out in the world in a way more tangible way than a lot of typical government stuff, eh?

Shannah: Totally.

Sean: And Sheena I feel like that was a really good point too, like in a crisis situation like the pandemic, that’s when you’re seeing the benefits of building a team, building up talent capacity, building tooling – that suddenly, even if it wasn’t super obvious how valuable that would be beforehand, then you see that in that moment, right?

Sheena: We were fortunate to have a two-year headstart prior to the pandemic to learn and unlearn many things, from talent, the skills, and the understanding of government basics. Had we not had those crucial two years, who knows?

Shannah: The other thing about the pandemic was: people really felt shoulder-to-shoulder. It was kind of ironic that at the one time when you couldn’t actually be together, is when we felt the most attached to each other. It was interesting.

Sean: For sure, I definitely feel that too.

Sheena: I would add one more piece to it: agility, that was the key, not just for us. We were moving quickly, and we found how the government moved to execute on time. There was clear direction that asked everyone to get in line. It was very nice to work with peers we’ve never worked with in the past. It was rare to see everything aligned top-down and bottom-up.

Sean: I think we had some similar experiences, where we were like: this is how fast – across a lot of organizations, a lot of parts of government – seeing how fast people can move when it’s needed is pretty impressive.

Shannah: Yeah, interestingly – those approval chains? Like, wow did they disappear fast. Which just kind of goes to show…!

Sean: Totally. Why don’t we jump to the last question – if there’s one thing that you could change about the government or the public service, like waving a magic wand, what would that be?

Sheena: Perception. People’s perception of government, versus our own perception of ourselves, I think they’re both distorted sometimes. You can see that in a lot of the press around app development right now, like, “I could have done it in a hackathon on a weekend”. Sure you can! But can you get through a series of rigorous approval processes fast?

And then our own perception of ourselves – we don’t give ourselves room and credit for the difficult environment. But, it is a difficult environment, not just translating, like, private sector concepts here. It’s a different way of working. Private sector is driven by profits. We’re driven by a different currency.

I think those two things: getting better at our own perception of ourselves, and the public’s, helping with that.

Sean: That’s a really great perspective.

Shannah: I think what I would say is: I’ve got to think of a gender-neutral way to say this, but, the concept of “statesmanship” seems to be less important now than maybe it was historically.

And I guess another way to say it would maybe be stewardship, since, “statesman” is too man-ish, I guess.

Sean: Bit of an old-fashioned word!

Shannah: But what I find would be really positive was if our orientation was really to the future. Like, we need to steward our services, our people, our society. We need to think, not in terms of what’s happening right now, or next week, or the next election.

We need to be thinking of the generation that comes ahead. How do we move forward in a way that is cognizant of the many changes and vagaries of society that we’re going to encounter. How might we be prepared to deal with something as impactful as a pandemic, again.

I think we did a really great job, but there was scrambling. And of course there’s always going to be scrambling, but if there was a sense of stewardship, and sense of caretaking – and if that was more important to us than announceables or initiatives – I feel like that would be a vision that would be very attractive not only to people working inside the public service but to the general public as well.

Sean: That’s awesome.

Shannah: That’s what I would love to see. I’d love to see more of an attitude of stewardship.

Sean: Yeah. And sort of that, thinking to the long-term as a core part of our job as public servants.

Shannah: Yeah.

Sheena: I have an add-on, maybe, this is a perception and stewardship kind of thing. When you think of data from a public perspective it’s like “you’re all siloed, you never talk to each other.” “Talk to each other! Be better at talking to each other!” You hear a lot of that, as if it’s that simple.

Stewardship in the long run is about examining policies that were set up at some point in time to serve a specific purpose, which was effective then, but, perhaps, not now. Barnacles of bureaucracy that need to be slowly cleared, starting with understanding why they exist.

Shannah: And I think – I can totally appreciate why some things do need to be very pedantic, and very approval-driven. Because we are dealing sometimes with matters of public safety or security. You don’t want to rush into some of these types of decisions.

Sean: People’s privacy, stuff like that.

Shannah: But I think it fits in the stewardship narrative. Like, when we need to take the time to do something, we should. We should not be swayed by, like, “do it faster!” But on the other hand, we would be better stewards sometimes if we could recognize when something doesn’t have to be, like, overly complicated or onerous.

Sean: 100%. That’s a great way of putting it.

Sheena: Culture is another aspect. For those easy, small, quick wins, it’s about that willingness to test a hypothesis. Let’s test, experiment, and learn.

Shannah: I think we tend to get a little shy about testing things, because it could be seen as a failure, and not as an experiment.

Sheena: That’s the piece that digital services have been doing successfully across the globe. It doesn’t apply to every problem. But sometimes we use one rule for everything and try to paint it with the same brush. The pandemic was a good example – there were some cases where the risk was low and the return high. Testing hypotheses and then moving forward is something we could do better at in a lot more places.

Sean: For sure. This is perfect, I think those are really great thoughts to end on – thanks so much!

Saying goodbye to Twitter

Mon, 21 Nov 2022 15:45:09 -0700

Over the past few weeks I’ve gradually been migrating from Twitter to Mastodon, an open-source, federated social network. You can find me there at @sboots@mastodon.sboots.ca.

(In early January I moved to an individual instance – Gersande La Flèche has a great overview of that here, and the Fedi.Tips feed has useful instructions on how to migrate an existing account between instances.)

If you’d like to learn how to migrate from Twitter to Mastodon, Patricia Aas has an introductory guide (including tools to help find your Twitter friends on Mastodon, which is helpful!). Jeremy Keith has also collected a number of useful “getting started on Mastodon” guides. If you’re reading this in Canada, you may want to choose an instance like mstdn.ca that was stood up a few weeks ago and seems excellent.

Twitter has been a pretty big part of my professional life for more than a decade. It’s strange and sad for that to come to an end so abruptly. If you’re reading this and thinking, “what happened?”, Nilay Patel’s recap sums it up very well. Matt Tait, Lucas Cherkewski, Mark Headd, and Giles Turnbull have also all written really thoughtful reflections about leaving Twitter.

At this point, continuing to actively use Twitter feels like it would inadvertently be an endorsement of values that I disagree with (not least, treating employees terribly, jeopardizing their access to healthcare and work visas, and leaving international teams out to dry). For now, at least, I’ll keep on posting new blog posts there (similar to LinkedIn), but I won’t be actively checking in on what has, for years, been the website I visit the most and a community that I’ve really treasured.

Reminiscing

I created a Twitter account in February 2011, after a few friends suggested joining. (Twitter had already been around for a few years; a couple summers earlier my friend Kyle Baptista had made a Twitter account for “Sean Boots the Office Fish”, a fish in the Engineers Without Borders national office in Toronto that the office staff had named after me.)

I was finishing undergrad and taking an international ethics seminar; throughout the next few months I quickly became glued to Twitter as reports came in, in real-time, from activists who were part of the Arab Spring and journalists who were covering the conflict in Libya. Many of the earliest people I followed on Twitter were national security journalists and researchers like Joshua Foust, Stephanie Carvin, and Steve Saideman, whose “Twitter Fight Club” bracket competitions introduced me to a much larger set of neat people to follow.

In fall 2011, I moved to Ottawa for grad school. I couldn’t transfer my Saskatchewan phone number, and so I bought a Mobilicity “smartphone” with a small data plan. The phone wasn’t powerful enough to run a web browser (!) but I installed Twicca, a lightweight third-party Twitter app developed in Japan, and it worked beautifully. On winter OC Transpo rides to and from school, I’d catch up on the latest tweets from Ottawa bicycling enthusiasts, which prompted my long-running tradition of planning to bicycle all winter, giving up in January when it got cold, and then starting up again on “Winter Bike to Work Day” because all of the #ottbike people were doing it.

After finishing grad school in 2013, I moved to Kumasi, Ghana and worked for a tech startup for a few years. My Ghanaian colleagues became fast friends and introduced me to the country’s tech scene through meetups like Barcamp Kumasi and GhanaThink events. Ghanaian techies were all avid Twitter users, and thanks to a multi-hour time zone difference (and Twicca’s purely chronological timeline), I quickly landed on a routine of checking “Ghana Twitter” first thing in the morning when I woke up (everyone tweeted during their trotro commutes to work), and “Canada Twitter” in the evening for news right before bed.

Ghana Twitter was a nonstop feed of tech tips and project updates, political news, debates with Nigerians about Jollof rice, and – especially in 2013-2014 as the Black Lives Matter movement grew – discussions on American politics, police oppression of Black people, and similar experiences of systemic anti-Black racism around the globe. As a white kid from Saskatchewan, it was an eye-opening and humbling experience. Many of my Ghanaian Twitter friends and past colleagues are now tech leaders or prominent researchers either in Ghana or around the world – folks like Rasheeda Yehuza, Kofi Yeboah, Edem Kumodzi, Kuukuwa Manful, Ato Ulzen-Appiah, George Arthur-Sarpong, Jojoo Imbeah, Prince Boadu, and so many others.

Twitter was ultimately my starting point to re-joining the federal government, when Ryan Androsoff sent me a Twitter message in spring 2016 asking if I wanted to meet up for coffee. Chatting over a chai latte in the lobby of the Lord Elgin Hotel, Ryan told me about his idea to create a digital service team within the Canadian federal government. In September 2016, I joined his team, and by July 2017 we had launched the Canadian Digital Service. As CDS got off the ground, Twitter was where we found our earliest community – change-oriented public servants who all found each other with the #GCdigital hashtag. That, in turn, was an evolution of the #w2p hashtag (“Web 2.0 Practitioners”) of tech-minded public servants who were pushing to collaborate across the public service long before departments were comfortable with social media.

Many of the public servants that I look up to the most are people that I met way back in 2012 at #w2p meetups, while I worked as a co-op student on Travel.gc.ca. People like Thom Kearney, Mary Beth Baker, Ioana Finichiu, Laura Wesley, Rob Butler, Steph Percival, Abe Greenspon, Stef Christensen, Kent Aitken, Nick Scott, and many more. Trying to change public service institutions for the better is hard work, and having a community of fellow travellers on Twitter was (on a very regular basis!) the boost of motivation we all needed to keep going.

Twitter was an important connector for all of us involved in Ottawa Civic Tech as it got off the ground. Civic tech and design folks from around the world became a big inspiration – people like Cyd Harrell, Dana Chisnell, Dan Hon, Dave Guarino, Waldo Jaquith, Michelle Thong, Will Slack, Mark Headd, Chris Whong, Noel Isama, Nikki Lee, Bill Hunt, and tons of other amazing folks. Many (probably most!) of the blog posts I’ve written here were inspired by conversations and ideas I saw on Twitter. Twitter was also a great way to make and find friends at conferences, where – frantically typing updates and sharing photos using the conference hashtag – you could immediately run into all the other Twitter aficionados attending the conference. From EWB events to the Code for America Summit to FWD50 conferences, this was always a huge highlight.

Twitter HQ in San Francisco in 2018, when I was in town for the Code for America Summit. It was a different time. I was so stoked to see it in person.

There were a few things about Twitter that made it especially appealing (to the point that, let’s be real, I was pretty heavily addicted to it). The short character limit meant that so much of it involved capturing the perfect sentence, turn of phrase, or play on words. The impromptu communities that formed around hashtags. And probably most of all, retweets (or RTs) that let you share and amplify other people’s insightful and creative ideas. Let’s just say: I was an enthusiastic retweeter, probably to the chagrin of some of my friends and family members on Twitter. But I learned so much from interesting people on Twitter, with perspectives and histories and cultures that were so different from my own.

As a Barcamp Kumasi attendee once said, “retweets are Jollof”. (If that was you, let me know!) Being able to share along others’ ideas – and give them the credit for it – really did feel comparable in awesomeness to what is still to this day one of my favourite foods.

Twitter obviously was not perfect, and a lot of these same features and techniques could be used for negative rather than positive purposes. But over the past decade it brought together people around the world, kept people informed during disasters and throughout the COVID pandemic, helped document human rights abuses and government oppression, and connected researchers and journalists and activists in unprecedented ways. Twitter built so many communities, and taught me so many things, that I only feel sadness as it falls apart.

Keep in touch

As mentioned off the top – you can find me on Mastodon at @sboots@mastodon.sboots.ca. If you’re a federal public servant trying to sign up for Mastodon and running into issues, give me a shout by email and I’d be happy to help!

To friends and colleagues from Twitter (and really, anyone reading this!) thanks for all the conversations over the years. It’s been a slice, and see you on happier parts of the internet from here.

Public service heroes: Sameer Vasta

Mon, 14 Nov 2022 15:27:13 -0700

Sameer Vasta is a founding member of the Ontario Digital Service and one of the kindest human beings I know. He currently works on the Talent team at the Ontario Digital Service and until recently taught the “Government in a Digital Era” course at the University of Waterloo’s Masters of Public Service program. Sameer is on the board of several community organizations, an advisor to a number of small non-profits, and a mentor to early-career public servants. And he’s a brilliant and thoughtful writer. We’ve been friends on the internet for years and I’m so glad he could be part of this series! We chatted by email in June.

How did you get started in the public service?

My first ever job was as a summer day camp counsellor for a day camp run by the City of Toronto. I was tasked with taking care of a group of sometimes-unruly children for eight weeks during the summer; I absolutely loved it.

I didn’t realize then that I was, effectively, a public servant. I wasn’t caught up in the machinery of government, or in the bureaucracy: all I knew is that I was providing a service to these kids and their families, and that I was having a blast while doing just that.

Eventually, I went from camp counsellor to coordinator to working on administration for a little while. I started to learn a little bit about what it meant to work in a bureaucracy, what it meant to work in the service of the public. What I didn’t forget, however, was the immense joy I got from working with those kids, and from knowing I was helping and making a small difference in their lives.

Many years after I stopped working for recreation programs, I was working at a startup when I realized that I wanted a bit of a change of pace. Someone introduced me to David Tallan – a leader in the Ontario public service who is responsible for bringing an incredible amount of talent into government – and we started chatting about the work he was doing on the eGovernment file, as it was called back then. I knew then that this kind of work was the right work for me: it was not only something that was going to have some meaningful impact on the people around me, but it was going to be work that I loved doing, too. I joined David’s team shortly after that, and it was the first step in my career in what we now call digital government.

Over the past two decades since then, I’ve spent time going in and out of public service. When I was ready to learn something new and try on a new adventure, I spent some time working in non-profit organizations around the world, but I always found myself drawn back to the public service in the end. It was the place I felt like I had the most impact, but also had the most fun, despite all the challenges. I went from eGovernment to Open Government to now Digital Government, and in all that time, I’ve continued to keep having fun through it all.

Tell us about an inspiring (or memorable) moment in your public service career

I’ve been incredibly lucky to have had the opportunity to be a part of some amazing teams working on incredible projects and programs in the public service so far – it has been a career full of inspiring and memorable moments, and it’s hard to pick just one.

Over the past few years, I’ve been making a more conscious effort to help mentor and support younger public servants – and aspiring public servants – to help them chart a path through the public service that they would find fulfilling. I’ve had the opportunity to teach at a couple of universities as well, and through those opportunities, I’ve met some of the most ambitious, smart, and committed young people.

My most inspiring moments in public service always come down to one thing: seeing people grow, thrive, succeed, and flourish. I get a flutter in my chest when I hear of one of my former students getting a role in the public service they have been working hard towards. I break out into smiles when I hear of someone whom I have mentored getting the opportunity to work on something they care about deeply. My heart is overjoyed when I hear of colleagues and friends excelling in their journeys through the public service.

Maybe that’s why I’ve been so drawn to working on issues around talent in the public service. I believe that the public service is successful when the people in it are given the opportunity to do their best work, and to grow and learn as they do that work. I believe that investing in the people who do the work of serving the people is fundamental to the success of government; that good people, when given the right environments, can do great things.

I’m grateful to have had the opportunity to teach future public servants at universities and to have supported current ones through my work in Talent at the Ontario Digital Service. Helping people grow and thrive in their public service journeys is the most fulfilling, and inspiring, part of what I do every day – and it’s also the most fun.

If there was one thing you could change about government/the public service, what would it be?

Ask any public servant that question and I know you’ll get a ton of answers: there’s so much we can change to make things better! Before I jump in with some of my thoughts, I did want to remind ourselves of one thing: there’s also so much we’re doing right. Sure, the public service isn’t perfect, but every day we do our work is another day where we’re helping people live better lives. Of course, there is much more we can do, and a lot of people who need much more support, but it’s important to remember that the work we do makes an impact, and that’s because we’re doing at least a few things right.

There is, of course, much more to do. I remember when we were first in the process of founding the Ontario Digital Service – there were just a few of us in the room at first, and our singular focus was to create a structure (and eventually, an organization) that could model how to do things differently, and hopefully, better. We had to figure out what rules we had to follow, what rules could be bent, what rules needed to be changed, and what rules weren’t actually rules at all.

During that work, I was mostly obsessed with people: who needed to be in the room, and what kind of environment we needed to create so those people could thrive. That’s where I’d love to see some change in government: a more concerted focus on people. It’s not work that Human Resources, at least as it is structured right now, can do effectively; any organization that thinks of people as “resources” rather than discrete individuals to be nurtured isn’t in the place to be creating that change. (Not to mention, HR often works in service of leadership, rather than in service of the organization.)

I’d love to see our “People” functions in government start to really invest in understanding what matters to people in the public service and giving them what they need to flourish. This may mean doing things a little differently than we used to – breaking some rules or creating new ones in the process – and it definitely means changing the focus of our people administration from policy and process to empathy and understanding.

This isn’t easy work, and it can be hard to conceptualize, especially in extremely large organizations. But it is crucial and important work. The public service is only as good as the public servants within it, and these public servants can only do their best work if we’re giving them structures and systems in which they feel supported, safe, and empowered. Let’s move beyond HR and towards a place where public servants aren’t managed, but instead invested in. When we create a space where our people can grow, learn, and thrive, the public service, and the public, benefits.

An update

Fri, 28 Oct 2022 09:09:57 -0700

Unfortunately, I won’t be able to present in-person at FWD50 next week. Prof. Amanda Clarke will cover the AMA on government-vendor relations in my absence – I hope you can all tune in for it (either virtually or in-person!)

The FWD50 team is brilliant and I’m really grateful to have been invited to present. For those of you who are going in person, I’m so sorry to miss seeing you! For in-person and virtual folks alike, I hope it’s a fantastic conference.

I’ll be tuning in to the virtual conference from here in Whitehorse, and cheering you all on in spirit. Take good care. 💖

Public service heroes: Ryan Hum

Tue, 18 Oct 2022 12:28:25 -0700

Ryan Hum is the Chief Information Officer and VP of Data at the Canada Energy Regulator (CER), a federal agency based in Calgary, Alberta. He’s an inspiration to so many of the best designers and design researchers I know in government, and he’s championed user research work at PCO, at IRCC, and in projects with a wide range of departments. At the CER, his team has done above-and-beyond work in data visualization, mapping, open data, and technology transformation. We spoke on July 7.

Sean: To jump into it, did you want to start with introductions? Tell us who you are and where you work these days!

Ryan: Sure! My name is Ryan, I work for the Canada Energy Regulator, it’s a separate operating agency for the Government of Canada.

Nice. You’ve been at the Canada Energy Regulator for a few years now, what’s it like being a federal public servant outside of the NCR?

I think it’s really fantastic. You know, when you are in the public service, you have to apply for competitions, and most of the time – at least I do – I actually want to come in second. I never want to win; I want to come in second. So you could be on the list, you could choose your own adventure, and you can choose when you want to be promoted up.

And I applied for this job – not necessarily wanting it – and then when I got it, I had to make a choice. The CEO, the deputy head at the time, was the former clerk of the Alberta government. And you could tell that he was super seasoned, and I thought that I could learn a lot from that.

The other thing is – I think public servants, especially ones in Ottawa, need to get out of Ottawa. You don’t understand the rest of the country if you’re only reading about it in the newspapers.

That’s such a good point. That’s very cool.

Did you want to talk a bit about how – I think, in a really awesome way – you’ve had a kind of unconventional public service journey. Did you want to talk about, how you started and where you ended up?

Yeah! Did you LinkedIn me? Check out my weird, ADHD career path?

It’s amazing!

I’m a biologist and engineer by training, by my original background. And at the time when I was graduating, you had a couple choices. You could work for pharma, or you could work for oil & gas. And neither of those appealed to me, as a little queer twinky-doodle gay boy, right?

And so I looked at NGOs, I looked at a couple of different options, I was always interested in the biotech space. And I went to a conference that was in town; I was living in Toronto at the time. And I met my future boss there. We had a chat about GM labelling of food; he asked me a whole bunch of questions. And, I think it’s rare to have a science geek talk about social issues, and he hired me soon afterwards.

That’s awesome.

I’ll build on that a little bit – one of the really nice things about the public service is, there’s so many different jobs out there. I started off in biotech, then went into food and drugs regulation, working for the FDA equivalent in Canada.

As a policy geek at the time, your passport is what matters. You have to work in social departments, science departments, and to round out the experience, I had to work in an economic one for a while. Each one of those were quite different.

And after a certain amount of time in policy, I was like… I miss “doing” things!

I don’t mean to say that policy peeps don’t do things, but – the lag time by which you write a paper, or a memo, and turn it into policy or legislation – it takes a long time, right? And for a little while I thought: you know what? I’m going to go back to my roots. I miss the lab. I miss building something with my hands.

So I enrolled in a master’s of product design, thinking that I’m going to actually build things. And silly me, at the master’s level they just assume that you know how to build things. And instead we learned about ethnography, and user research, and where do ideas come from, and what’s the ideation process. That’s how I got into this whole user research, service design, digital etc. space.

I was kind of curious, when you mentioned that you did biotech and engineering, I was curious where the design angle comes in. Since you’ve done amazing work both at IRCC and at the CER on user research and testing.

I literally remember the first day of design school. My prof was talking about, you know, how users are supreme and you have to listen to them, and all that good stuff that you hear all about in design and HCD.

And I remember lifting up my hand and being that jerk in the class – as an engineer, you know, well, anyways…

My family is all engineers, so I can picture what you’re thinking!

I lifted up my hand and I said, “users are dumb”. Users break your products. Users let the best product die in the marketplace. Why should I listen to users?

It’s like, why does MySpace (at the time) win, when its technology is really bad, right? Like, those things happen.

Exactly! And my prof said, you silly boy, you’re mistaking the difference between a user knowing what they want, and a user being able to tell you what they want.

If you go down this path as a designer, your job is to be able to extract what they want, when they’re not able to tell you.

That’s super interesting. That’s a great perspective, for sure. And that’s where more, like, observational user research and things come in?

Absolutely. And when I started getting into this space, I was like: holy crap. We should be doing this for policy. We should be doing this for service. We should be doing this for a whole variety of different fields, because we don’t always know what the answers are, at all.

And so going back into this space [into the public service], that’s what I really tried to bring. That user research. And I don’t mean the theatre around, like, pretending to create personas and all that. I mean: actually talking to people.

And it’s not necessarily what they say, it’s sometimes what they don’t say.

That makes sense, for sure.

Is there a particular moment doing this that stood out? I was reading about the work you did at Pier SIX [IRCC’s Service Insights and Experimentation unit] doing usability testing in front office kind of counters, like when people are waiting in line-ups. What was that like?

Really cool. I wrote a little LinkedIn post about that, where the origins came from, so I won’t get into that too too much.

But IRCC is such a special place. Not only do you have front counter service, and now digital, but the people that work there don’t want to leave. Because they are passionate about helping people and making Canada better.

And so you get all these amazing opportunities to work with this extraordinary staff, who are user-inclined anyways. And just giving them the tools to be able to do that is just phenomenal.

One of my favourite moments was, creating design challenges at IRCC. Previous to working at IRCC, I was working at the Privy Council Office in what was the Central Innovation Hub, what ended up becoming the IIU.

And there, I was just prototyping different ways of doing user research. So, working with OEE on energy efficiency in homes; we did the first photo study probably ever in the Government of Canada. Working with Health Canada, we did a whole bunch of intercept interviews at random places to better understand how products are regulated and how consumer products can be safer.

By the time we got to Immigration as a project, I had prototyped a whole bunch of different ways of: lengths of time, how many people, etc. And I was able to be a little bit bolder, and I was seeing that – there’s a mixture of finding the right user research, and allowing for time to percolate into ideas. But also, you need to support that culture change afterwards so that the ideas actually turn into something.

So meeting with Michelle Latimer and Alanna MacDougall, we were really lucky to have a four-week design challenge. Week One was all user research, and in that process we probably interviewed 300-some people. Week Two, we suspended all the analysis until week two, and we did all our journey mapping, user analysis… trying to find insights. Week Three was all ideation, like, a full week on ideation, and Week Four was prototyping and crafting our storyline to tell senior management.

And we took fifteen people from across the department – everyone from call centre staff to policy analysts, comms, finance people, immigration officers, anyone who touched that file – and they were part of the process.

And it was just this amazing process, and you could see how it changed the way that they were developing policies or services. Our first one was so successful that – we presented on a Friday, and somehow Michelle Latimer got us onto the agenda on Monday morning to brief the minister and deputy minister. And that’s when I knew that we hit something really special.

That’s amazing, that’s very very cool.

Yeah. And you know, the classics, like – Ryan Androsoff was there, and Mithula Naik – and, yeah. It was just, a really really special time.

That’s really cool. Like, really cool work, and really cool people.

And you can see how – we ended up doing these design challenges, like, two major projects a year. And they were so popular; minister’s offices kept on saying: oh, you know, we’re having this problem, can you just do a design challenge about it?

Because they were seeing it as a tool to be creative. And the popularity of this, and bringing in user research to do creative problem solving, became so intense that we had to create a service. So that’s where the usability lab in the front office came about.

That’s awesome.

Going to the last question – and this could be for any department or any level of government – if there’s one thing you could change about the government or the public service, what would it be? Sort of like, if you could wave a magic wand to change one thing. It could be anything.

I thought about this for a little bit, and I don’t think they’re quick, but, I have two.

One is: when we hire new public servants, we should send them out the door at the very beginning. We should get them to meet stakeholders. We should get them to meet clients. Experience a service, before they actually join.

By doing that, I think we would create a culture where that’s permitted, and acceptable.

Whoa, yeah.

So that when they’re actually in their career later on, they could feel like they could do that.

That’s huge. I really like that.

And then the second one was: in one of my first EX town halls, Michael Wernick said, every one of you – this year – should make one risky hire. And I think about it – like, a lot of us hire people with our backgrounds. If you’re in policy, let’s hire someone with an MPA; I’m an economist, I know what I could do, therefore I’m going to hire people that think like me…

Asking all managers to do at least one risky hire, to bring in diversity and different perspectives; I think it would be really, really good.

That’s awesome. That’s a really cool strategy.

It’s slow-burn, but I think if you change too much, sometimes, there are unintended consequences, right?

Yeah. I like how both of these are “long game” investments in both the approach and the makeup of the public service, and how to make that better.

I mean, don’t get me wrong, I’m sure there’s some quick fixes around procurement and other things, but yeah.

So good. This has been awesome! Any last closing thoughts or closing words?

Is someone going to interview you?

Um, I don’t think so?! That’s the fun part about being on this side of the Teams call.

If I could recommend one thing: you’ve brought in some amazing, very senior people to be interviewed. I wonder whether or not bringing in some “newbies” to be interviewed would be really, really neat.

Almost putting in this, like, behavioural science commitment – do you know what I mean? Like: they say that this is what they actually want to do, and this is what they want to change in the public service.

As public servants.

And having that on the public record I think will make them think differently about their career.

Whoa. I like that. Okay. I might reach out later on that!

If you’re a new public servant (within the last few years) interested in being interviewed as part of this series, that would be amazing! Send me an email if you’re interested. Thanks for reading!

“Charbonneau Loops” and government IT contracting

Wed, 12 Oct 2022 17:12:24 -0700

Dan Hon’s newsletter (which is excellent) had a great anecdote last week about the New York City Sanitation Department hiring McKinsey to study and design a procurement for trash containerization. Which is exciting (urban planning!) but also, as Dan says, alarming:

This kicked off my usual consultant-consulting-on-RFP threat-response mechanism, this time focussing on: under what circumstances and in what environment is an external consultant needed to design that organization’s RFP for them? …

In general – and in my experience – this kind of thing happens, where external consultants are needed, because a bunch of hollowing-out of experience has happened in favour of outsourcing and contract management.

This reminded me of something I’ve been meaning to write about (since May 2020, thanks Evernote) that’s somewhat prevalent in Canadian government IT contracting. That something is “Charbonneau Loops”, which, yes, is a term I made up.

What are Charbonneau Loops?

Let’s start with a brief throwback to the Charbonneau Commission, a judicial inquiry into corruption in the Québec construction industry that published its final report in 2015 (officially the Commission d’enquête sur l’octroi et la gestion des contrats publics dans l’industrie de la construction).

There were a lot of corrupt-y things that the commission uncovered (envelopes full of cash to municipal politicians, for example) but the part that stood out, to me, was the commission’s recommendation (on page 1,336 of a 1,741 page report) that the Québec provincial government rebuild its in-house capacity to oversee transportation engineering projects (see English translation):

En l’absence d’expertise interne, les donneurs d’ouvrage publics dépendent de consultants externes pour la planification, la réalisation et le contrôle des travaux à réaliser. L’impartition de certaines tâches à des firmes externes ne pose pas problème, lorsqu’elle répond à des besoins d’expertise spécifique ou en raison d’une hausse temporaire du volume de travail à effectuer. Toutefois, le manque d’expertise interne empêche les donneurs d’ouvrage d’apprécier à leur juste valeur les solutions proposées par leurs fournisseurs et d’évaluer le travail accompli par ces derniers. Lorsque la perte d’expertise interne est trop prononcée, ils sont alors complètement dépendants des firmes externes. (p. 1,243-1,244)

Ce rapport met entre autres en lumière d’importantes hausses de coûts et déplore que les ingénieurs du [Ministère des Transports du Québec] soient devenus «des gestionnaires de projet cantonnés dans des tâches administratives » alors que les firmes de génie-conseil préparent « 100 % des estimations relatives aux contrats d’infrastructure routière à Montréal et 95 % dans les autres régions ».

Il peut être avantageux de recourir aux firmes de génie-conseil lorsque les besoins d’un donneur d’ouvrage requièrent une expertise très pointue ou se manifestent durant une période de pointe. La Commission juge toutefois qu’il est primordial de rééquilibrer le recours aux firmes de génie-conseil et de redonner aux donneurs d’ouvrage les coudées franches lorsque vient le temps de déterminer si des travaux doivent être réalisés à l’interne ou octroyés en sous-traitance. (p. 1,336, Recommandation 23)

Up until the 1990s, the Ministère des Transports du Québec had in-house engineers who oversaw construction and engineering work for highways, overpasses, bridges, and so on. From then on, to save costs, the provincial government instead largely contracted out oversight of these projects to other engineering firms.

You can see where this is going. The total number of firms who were capable of either a) doing highway engineering work or b) overseeing highway engineering work in Québec was not that big. On one project, company A would be doing the work, and company B would be overseeing their work on behalf of the government. On the next project, company B would be doing the work and company A would be overseeing it, and so on.

They all talked to each other, and (to paraphrase a lot) found creative ways to cut corners, keep the extra money, and not call each other on it or report it to the provincial government. For a couple of decades.

Overall – minus the envelopes of cash – this is a pattern that you see in other areas of public sector procurement. When the same set of vendors is sometimes doing the work, and sometimes overseeing it, you get a repeating pattern that I call a Charbonneau Loop.

How do Charbonneau Loops happen?

In most cases, I should be really clear, they don’t involve actual corruption. Charbonneau Loops happen whenever you have:

Insufficient internal capacity to provide oversight directly
A small pool of established vendors

And, it almost goes without saying, you’re doing work with a sufficiently high level of complexity that it requires active oversight. This includes infrastructure construction projects (like highways), and it also includes IT implementation, client service delivery, and a whole range of other fields.

It doesn’t include everything; landscaping and gardening, for example (with apologies to gardeners!) doesn’t necessarily need the same level of oversight. If done poorly, it likely won’t affect people’s life and livelihood the way a collapsed bridge or failed benefit program IT system would.

In some areas – public sector IT, for example – “oversight” can refer to a range of things. In this context, it could include planning procurement activities, and developing documentation for these; it could include project management and coordinating the work of other vendors; it could include reviewing and approving other vendors’ work; and it could include more traditional oversight roles like security compliance or privacy assessments.

You can see #1 above show up when you see government organizations issue RFPs for “procurement support” (like Dan’s New York City example, above), for different kinds of “design authority” work, to write requirements, or to support project management offices.

#2 is harder to determine, because it depends on a longer pattern that shows up over several years’ of procurement activities. Are there companies that are sometimes implementers, and sometimes oversight providers? How frequently do the same companies show up in different aspects of the same projects?

Charbonneau Loops ultimately happen when the “pool” of companies (receiving public sector contracts for a given type of work) is small enough that the same companies are sometimes overseeing, and sometimes overseen, by their peers in that same pool. Even if they never actually coordinate with each other – even if they don’t have any conversations whatsoever – they’re all incentivized to be a little bit less critical of each other as a result.

Ultimately, each of the companies in these kinds of environments recognizes that – in the next iteration of the Loop – that if they carefully scrutinize and call out poor-quality work when they’re in an oversight role, their peers will take it out against them when their situations are reversed. It’s “better” for everyone (every company, at least) if they’re gentler on each other, and report back that things are pretty fine to the public sector organizations that hired them.

All of this is compounded by the very blurry line between public servants and vendors that tends to occur in these environments. Imagine the boundaries of public service so porous that you couldn’t tell if you are meeting with colleagues or contractors? It’s not only because the contractor has been around at least a year with no sign of leaving, but also because contractors get government email addresses and have access to all internal systems. Some may even hold senior advisor roles to Assistant Deputy Ministers and Deputy Ministers via Interchange programs.

It’s not corruption, but it’s a set of incentives that aren’t aligned in a way that’s favourable to good public sector outcomes.

How do you fix it?

In short, just like the two criteria above, there are two overall solutions:

Rebuild or increase your in-house capacity (as a public sector organization) to provide oversight directly
Increase the size of the “pool” of vendors who are regularly participating in procurements

Beyond having sufficient in-house capacity to provide effective oversight, more in-house capacity gives you the option of implementing in-house, reducing or eliminating the need for vendors at all. For government IT work, there are some great pieces from Mark Lerner and colleagues on increasing in-house tech capacity: Should this role be in-house, or outsourced? and The Government Technology Silver Bullet: Hiring In-House Technical Talent. The takeaway from a lot of recent research (including these pieces) is that governments’ heavy dependency on outside companies makes it hard for them to hold these companies to account.

When it comes to increasing the number of vendors participating in government IT procurements, this has been an acknowledged problem for a while. In Canada, burdensome procurement processes make it hard for small companies to participate. Departments are locked-in to existing proprietary software systems, making it difficult to switch vendors despite high costs.

Other countries have undertaken a lot of interesting and innovative approaches to tackle this, particularly the UK government’s Digital Marketplace which had an explicit goal of bringing in small, geographically-diverse vendors that hadn’t previously worked with the government. Being able to cut ties with underperforming vendors (without jeopardizing your project!) is also a critical but very under-exercised set of skills.

When Charbonneau Loops happen in the government IT space, they’re often related to the participation of large management consulting firms. These firms have the expertise to provide project management and oversight activities, and to help design procurements, and they have large IT professional services wings. They also tend to have arrangements with specific large software vendors (for example, a go-to case management suite, a go-to proprietary database vendor, and so on). It’s not surprising that – as departments have accelerated their digital transformation efforts – spending on IT consulting services has increased noticeably.

In data that’s publicly available, it isn’t possible to track the participation of specific firms to specific IT projects at a scale that would illustrate Charbonneau Loop patterns. There’s no smoking gun here (and this blog isn’t the place for it!). Outside of occasional news articles (usually based on access to information requests), it’s rare to know which companies worked on which projects.

Charbonneau Loops are far from the only reason government IT software projects fail. Building custom software is hard. Building custom software that you didn’t know was custom software is harder. That’s partly why being able to hold companies to account – ensuring that their work is functional, reliable, and high-quality – is so critical.

And as departments attempt to modernize both how they work, and the IT systems their work depends on, they tend to rely on the same small set of vendors. Given this, it’s worth keeping a close eye out for Charbonneau Loop situations. And it’s worth keeping in mind that, regardless of any other good advice they might provide, established vendors are not going to come out and say: established vendors are a key structural problem.

These days I have A Lot Of Thoughts about IT vendors! For slightly more academically-rigorous thoughts, don’t miss Prof. Clarke and I’s “Ask Me Anything” session at FWD50 in November!

Public service heroes: Christopher Scipio

Tue, 04 Oct 2022 08:05:47 -0700

Christopher Scipio is a long-time champion for a more diverse, equitable, and anti-racist public service. He’s currently the senior strategic advisor to the Black Executives Network, and has previously worked in a number of policy roles at the Department of National Defence, Employment and Social Development Canada, Innovation, Science and Economic Development, and Justice Canada. We’ve been Twitter friends since 2014 and his perspectives on the challenges facing the public service today are always insightful, candid, and eye-opening. We chatted by email in August.

How did you get started in the public service?

I am the first person in my family to work in the federal public service. I joined the public service in 2010, as a student analyst via the Policy Research Affiliate Program (PRAP). My first job was at Justice Canada working on access to justice for vulnerable Canadians. I started with the Public Legal Education and Information (PLEI) program and after a few months I joined the legal aid team.

At the end of the summer, the team I was working on didn’t have an available box or funds to bridge me in as an indeterminate employee – so I had to leverage the networks I had developed over the past six months to find another team to join at Justice. Looking back, those few weeks were so stressful because I was still new to the public service, and I didn’t have a large network to tap into. Fortunately, there was a new unit being set up and they were looking for staff, so that was my bridging opportunity. The team was responsible for change management and corporate reporting.

I spent six years at Justice Canada before going to ISED for about year to work on digital government and then to ESDC to work on the temporary foreign workers program. National Defence was the next step on my career journey and right now I’m on an assignment/interchange with the Black Executives Network.

Most of my twelve-year career has been in strategic policy work though I did program delivery for about three years.

Tell us about an inspiring (or memorable) moment in your public service career

I honestly feel that my career has had many inspiring moments. I love being a public servant because I love being able to do impactful work.

In 2014-15, while at Justice Canada I was the co-lead for the Indigenous Policy and Programs Innovation (IPPI) Hub. We were using design thinking to better understand the factors contributing to the overrepresentation of Indigenous Peoples in the criminal justice system, both as victims and offenders. At a time when policy innovation was the buzzword in the GC and public sector innovation labs were being set up to tackle wicked problems, we decided to tackle one of the most “wicked” – the lack of access to justice for Indigenous Peoples. It required confronting the colonial legacy and systemic racism of the criminal justice system.

I remember some of the first engagement sessions we designed, and communities being surprised that we were coming with our post-it notes and writable walls and wanted to hear directly from the impacted communities about their ideas. “Lived experiences matter” was our mantra, and we were intentional about how we worked. We wanted to shift the power dynamics and wanted to make space for Indigenous Peoples to define the policy issue and identify the solutions that they wanted, not what some bureaucrat thought was best.

We had a beginner’s mindset. We were trying to be innovative but not just because it was “cool” – rather, we wanted to work differently and work better. We committed to respecting Indigenous ways of working, and one of the first advisors we had was an Indigenous Elder. She showed us how empathy, curiosity, humility, and love for the communities we were serving would lead to solutions that would have a more positive impact on those most affected. It was a pilot project so we didn’t get to see all of our ideas and plans come into fruition, but we know that with the little time we were around, IPPI Hub did something very special.

The other memorable moment is the work I am doing right now to address anti-Black racism in the public service. In February 2022, I joined the Black Executives Network/Le Reseau des exécutifs noirs as the senior strategic advisor and lead for the Secretariat. BEN/REN is a community-driven employee network for Black Executives. BEN/REN provides support to Black executives and works with the Government of Canada to address anti-Black racism. Some of our priority areas include mental health, data and research, and talent management.

Did you know that there are 6,717 executives in the federal public service but only 128 who identify as Black? That’s just 1.9% of all executives, even though Black Canadians represent 4% of Canada’s population at present and are projected to be 5.6 to 6.0% by 2036. Anti-Black racism not only prevents Black talent from reaching their full potential, but it also prevents the public service from harnessing the full talents of brilliant Black public servants who are committed to the public good and want to help solve the challenges we face as a country.

A lot of my work entails collaborating with others to bring about the changes BEN/REN endeavours to see. And putting on my GBA Plus advisor hat (prior to joining BEN/REN I was a Senior GBA Plus Advisor at National Defence), to properly understand and respond to anti-Black racism you must recognize that Black women, Black persons with disabilities, Black LGBTQ2S+ experience racism differently from able-bodied cis-gender Black men. This work has a real impact; there are people working today and those who worked in the past who faced career stagnation and negative mental health outcomes because of the anti-Black racism they had to endure. We must do better as a public service. I am determined to do my part to reduce the negative impacts.

I am fortunate to work in a space where I am not the “lonely only” and I don’t take that for granted. When I turn on my MS Teams and enter meetings, I know that there will be many faces like mine on the screen. Every day, I am working on initiatives to unblock the talent pipeline, to help foster inclusive and anti-racist spaces so that Black public servants from coast to coast to coast can feel psychologically safe at work. This work comes with great responsibility, but it also gives me great joy.

A few years ago, I realized that when I retire from the public service I want to know that I was a Good Ancestor, that I made things a little bit easier and a little bit better for those who will come after me. I want to leave a legacy where I used my voice, my influence, and my ability to amplify the voices of those who we don’t hear from because they have been intentionally silenced. I want to use my social capital to make space for others and to give others more opportunities.

If there was one thing you could change about government/the public service, what would it be?

There are so many things I would change. First, I would decentre whiteness. Often in equity-seeking spaces, Black, Indigenous, and Racialized people who belong to that equity-seeking community are marginalized and face further exclusion. Often when GBA Plus work is done, the default impacted person is the white LGBT person or the white woman. For some reason the default is always white. That needs to change. We need to understand that within every community there is diversity and that some policy issues require centring a different perspective.

I also want us to have a public service where people are hired for what they are capable of doing and not just what they did in the past. There is so much untapped talent in the public service. I know too many talented public servants who are overqualified and under-classified. Especially in the regions. We need to be serious about equity and inclusion, and that requires us to apply anti-racism and anti-oppression approaches. Where we equip, in an equitable way, public servants with the work tools and learning opportunities (including language training and leadership training) so that folks can take on new challenges.

I want to see a public service where more faces look like mine at the decision-making tables, because I know the public service will only be the best version it can be when no talent is left behind.

How much does the Canadian government spend on IT contracts each year?

Wed, 31 Aug 2022 20:42:26 -0700

(The answer is: about $4.6 billion dollars in the most recent fiscal year.)

This week I’m coming up to the end of my Public Servant-in-Residence term at Carleton University. It’s been an absolute dream to work with Prof. Amanda Clarke and the School of Public Policy and Administration.

A key focus of our research work over the past few months has been analyzing Government of Canada procurement contracts as a way of exploring how the federal government spends money on information technology. Conveniently, contracts for IT – and every other area of government purchasing – are listed in a comprehensive open data set published on open.canada.ca. It is a fascinating resource, and I’m a huge fan of the open government team at TBS that maintains this data.

As is often the case with government datasets – this information is publicly available (and you can even search through it, contract by contract!) – but it can be hard to get an overall understanding of what the data looks like at a government-wide level. That’s particularly true in this case, with 925,000 entries in a 400MB CSV file. Excel doesn’t cut it, as the saying goes.

To make it easier to understand government contract spending at scale, our team is really excited to launch govcanadacontracts.ca, a research website that breaks down this data by vendor, by department, by category, and overall across government. You can explore trends over the past few fiscal years across each of these dimensions, and use the links to jump from department to vendor to category and back – as well as look up the original source data for each vendor’s contracts with links back to the entries on open.canada.ca.

The top ten vendors across core public service departments. See the full list.

You can learn more about how the data was analyzed and how the website was built on the Methodology page. This research expands on earlier work that some of you might remember from Ottawa Civic Tech – it’s been really wonderful to be able to revisit this from an academic standpoint. And to conduct the analysis in R, not, uh, PHP. (Long story!)

Check out the website, explore the data from your favourite government departments and contractors, and let us know what you think! If you see issues or errors, or if you have suggestions for data visualizations, website improvements, or future research, we’d love to hear from you.

I’m super grateful to Prof. Amanda Clarke, and to Anne Lajoie and Chantal Brousseau from our research team. We’ll have more to share in the weeks ahead from our research findings – stay tuned! Amanda and I will also be at FWD50 this year talking about our work and what the data tells us about the state of IT contracting in Canada – hope you can join!

Lastly: this kind of research would not be possible without all the work of R package developers and data science educators. You are all genuinely above and beyond – thank you. ❤️ Fellow Government of Canada folks: modern data science isn’t possible without the Tidyverse (or Anaconda, the Python equivalent). If it’s not available on your work computers, it should be. It is a wild and surreal set of game-changing data science tools, and a phenomenal community of practitioners.

Public service heroes: Aubrie McGibbon

Fri, 26 Aug 2022 07:21:47 -0700

Aubrie McGibbon is a long-time open data and public sector innovation expert with the Nova Scotia government. They’re currently the data strategy lead for the Nova Scotia Digital Service, and they previously co-led NS Govlab, Nova Scotia’s first social innovation lab. Aubrie and I have been Twitter friends since my very first month working in government; I’m so glad they could be part of the series. We chatted by email in June.

How did you get started in the public service?

My first exposure to government was as a landscaping labourer with the municipality I grew up in. It was rewarding to see the work I was doing serving others – even if it was limited to making sure the grass was cut. Both of my parents worked in public service and encouraged it as an option growing up.

I completed my undergraduate and graduate degrees in Ottawa and was able to complete an internship with the Department of Justice and was later bridged in as an indeterminate employee. After a few years of service with the Government of Canada, I had the opportunity to move to Halifax. I was able to secure a one-year contract with the provincial government, and 11 years later, that one-year contract turned into the opportunity to work with the Department of Economic Development, the Department of Justice, the Emergency Management Office, a social innovation lab and the Nova Scotia Digital Service.

Tell us about an inspiring or memorable moment in your public service career

My inspiring moment was appreciated in the moment, but I do not think I truly recognized the gift it was at the time. With the Research and Statistics Team at the Department of Justice Canada, research projects were a big chunk of the workplan. Junior Analysts were encouraged to bring forward ideas and contribute to the body of research. Everyone had at least one research project – the amount of projects and the sophistication of the methodology was often determined by rank and experience.

Regardless of the project, all ideas required a short proposal. These were submitted to Senior Researchers, then forwarded to the entire team. Once every two weeks (if memory serves), we met in a large boardroom and reviewed a batch of proposals. Everyone was expected to have reviewed the work and anyone could ask questions of the proposal. Many an interesting discussion occurred around that table.

In hindsight, the magic was the design of the meeting. Junior staff were expected to listen and learn and contribute. This was in the early days of web 2.0, so there was a very definite area for contribution not only with what we were learning with coursework, but also what we were learning from connecting with folks online and outside of a traditional network.

I recall the table being challenging, but honest and fair. I learned more from that experience than in some graduate courses. It was a masterclass in research, methods, navigating the bureaucratic system and weighing social ramifications and implications (regardless of political stripe holding office).

If there was one thing you could change about the public service, what would it be?

At a systems level, I would eliminate the amount of friction and discord that comes from the three peaks of bureaucratic death – HR, procurement and budget. I have lost count of the number of innovative, out-of-the-box and inspiring work and ideas that have fallen victim to at least one of these three peaks.

Working in the data space within a digital transformation context, this tension feels crushing some days.

At an individual level, I would fundamentally transform the current approach to recruitment and retention. In addition to not yielding the outcomes we need, I would like to see a much more diverse workforce. When I think about some of the friction and discomfort I experience, I often wonder how this translates to users. As an example, as someone who identifies as non-binary, pronouns are an Olympic sport for me. As I navigate the challenge(s) of using different pronouns in the workforce, I wonder how this shows up for trans and non-binary folks trying to access government services in a respectful and inclusive way.

I should add that my experience also includes a ton of privilege, so my experience is very different from others. Knowing this, the discomfort and sense of not being seen as I perceive myself reminds me how important my work is to supporting government products and services that are suited for everyone where they are currently at.

If you use project gating, you’re not agile

Wed, 24 Aug 2022 07:30:43 -0700

There’s been a lot of interest in adopting agile practices in the Canadian government over the past few years. Being more incremental, iterating more quickly, and breaking projects into smaller pieces are all really valuable approaches.

One of the major challenges facing digital teams in government is that – even if they organize their own work according to agile principles – they’re operating within a broader environment with a lot of constraints all built on waterfall thinking. “Waterfall” project management operates on the assumption that each step in building a thing or implementing a project can be done linearly, with all the planning done at the beginning and all the implementing done at the end.

Construction and engineering projects (building a bridge, for example) are the classic examples of waterfall project management. You know exactly what river you’re trying to cross, how much traffic the bridge will have to handle, and based on that you can plan out exactly what materials, people, and equipment you need, and build it according to those pre-planned specifications. (Don’t do this.)

Software development – including any government IT projects – doesn’t work like this (much as waterfall project managers would like to think that it does). Any software that actually works needs to account for the unpredictability of human behaviour. Doing that well involves repeatedly getting feedback from the actual people that will use your software, and using that to continually improve what you’re building. Short feedback loops are the secret to good software (and good IT projects), and years-long, pre-planned waterfall approaches are a fundamental barrier to achieving them.

Documentation off-ramps, not implementation off-ramps

In the Canadian government, the main pressure to follow waterfall project management styles (largely abandoned by software companies outside government) originates from financial management policies, rather than information technology policies.

“Project gating” is the main form this takes, where – in a series of detailed planning steps – departmental teams seek approval (one gate at a time) to initiate a project, to get funding, to outline a project plan, an implementation plan, and a variety of other steps that eventually lead to building or procuring an IT system. Project gating requirements might be enforced by a department’s CFO office, their CIO office, a major projects management office, or some combination of all three.

From the “Guide to Project Gating”. Implementation – actually building or procuring a system – isn’t explicitly listed but it’s somewhere between step 4 and 5.

The goals of project gating are ultimately to provide off-ramps where, for example, a poorly-defined or unnecessary project could be halted before it wastes more money. This is a worthwhile goal, and comparable in some ways to what I wrote about a couple weeks ago – splitting large projects into smaller ones that leaders feel more accountable for.

The critical difference, however, is that all of the project gating off-ramps take place in the planning stage, not the implementation stage. The careful, excruciating scrutiny that takes place at each gate – accompanied by hundreds of pages of documentation – all happen before any software is shipped, before any actual user sees it, and before any feedback or user research can come back in and improve what’s being built.

Teams going through the project gating process are challenged on the quality and comprehensiveness of their upfront planning documentation, which (in general) is not only a waste of teams’ time, it has a downstream effect of extensively solidifying or “baking” decisions into that documentation in a way that prevents the future iteration and responsiveness to feedback that’s required to build good software.

Project gating is designed to prevent expensive IT project failures, but it’s worth keeping in mind that all of the Canadian government’s most notable IT failures in the past decade successfully completed a project gating process. You may have heard of some of them.

The long way back

I was curious about the origins of project gating in the Canadian government, beyond the documentation that’s currently published on Canada.ca (last updated in 2021). The Internet Archive’s Wayback Machine is a fantastic resource for this.

The earliest reference I’ve seen to project gating is a 1997 TBS proposal for an “Enhanced Framework for the Management of Information Technology Projects”. It’s …not bad!

Gating also allows the department to control the cost of projects and minimize the financial loss on problem projects. In this approach, a designated senior departmental official, e.g., the project sponsor, manages the funds allocated to the project and releases only the funds needed to reach the next gate to the project leader. The performance of the project is reviewed at each gate, or when the released funds run out (to avoid delays, the designated official could release sufficient funds to permit work to continue on the project for a short time while this review and decision took place). After the review, departmental management can decide to proceed with the project as planned, modify the project and/or its funding, or even terminate the project limiting the loss to the amount previously allocated.

Projects and contracts will have to be structured to avoid incurring major penalties from the application of gating. By requiring the contractor to provide complete information on project performance and progress and also specifying in the contract when the scheduled reviews are to take place, the reviews could be conducted in a reasonable time without the need to stop work. By specifying the option to cancel the contract at the scheduled gates including the criteria on which such a decision would be made, in the contract, gating can be implemented without incurring major penalties.

Even from the outset – 25 years ago! – it’s noteworthy that TBS acknowledged the potential burden that project gating could incur. As written, this feels even more closely-aligned with the goal of breaking large projects into smaller components. (It presupposes, however, that work won’t be done in-house, which is both disappointing and prescient.)

Over the decades since, this idea transmuted into a more formalized set of gates, with increasingly-burdensome documentation requirements at each gate. This 2010 TBS document provides a detailed overview of what had by then become the “seven-gate model”. Departments, in turn, developed their own variations and frameworks based on the TBS guidance at the time, in some cases requiring teams to complete several competing project management frameworks simultaneously for the same project.

Caution, metaphors.

There is no waterfall-agile combo; it’s just waterfall

A lot has been written on the downsides of combining waterfall and agile approaches. Nevertheless this is probably the most common project management style seen in government today, as teams (like Honey’s) try to be as agile as they can within a broader financial and project management policy landscape that requires waterfall steps and documentation.

Here’s how Mike Bracken, the original director of the UK’s Government Digital Service, describes it:

Being agile doesn’t mean you give up on governance or deadlines. The idea that agile somehow “needs” a waterfall-type methodology to give it control and governance is nonsense. When you work in an agile way, governance is built into every step of what you do. You build and iterate based on ongoing user research. You build what users need, not what you guessed might be a good idea before you even started building. That means spending money throughout the lifecycle of a service. Not throwing a lot of money at a project upfront, without knowing if it’s going to be useful. Or not.

In my view, formalising a mishmash approach is going to end up giving you the worst of both worlds. You won’t get the thing you planned on the date you planned it, and you won’t get something that meets user needs either. You’ll end up with something that fails on both counts.

Paul Craig has an excellent post that speaks directly to the tension between shipping quickly – a key agile practice – and concerns around governance and oversight:

Is ‘Wagile’ a good idea? No. But how about starting fights with a bunch of people you work with and eventually having your project cancelled? Well, obviously that’s worse.

It’s not easy to subtract governance processes in an organization hyper-sensitive to risk (“let’s not do this documentation and still be allowed to release”). Removing something that looks safe (even a diagram that will soon be out of date) without an equivalent replacement is a tough sell.

Shipping early is the best argument you can make against the reality of waterfall, because, done right, you will save huge amounts of time and money. By the same token, the longer it takes you to get products built and released, the more you resemble the expensive waterfall processes you seek to replace.

This is why you need to move fast. In general, you want to define your MVP and then test it with users as soon as possible. Enterprise planning does not have a good answer to ‘user needs’, so it is important to prioritize early user engagement. User feedback both (a) gives you insight to improve your product and (b) functions as documentation you can share internally that other teams don’t typically have. Once you are confident that your product works, focus on what you need to do to get it released. It’s far better to have a released ‘alpha’ service than a highly-polished internal prototype.

Ashley Evans, Sarah Ingle and Jane Lu wrote a really fantastic post on a similar theme, on what it looks like to shift from planning to learning. They write:

The root problem is a desire to avoid failure by overplanning and creating a sense of false certainty.

From a structural perspective, this barrier shows up as excessive forms to fill out, briefings to give, or checklists to complete.

From a cultural or behavioural perspective, it shows up as top-down decision-making, discouragement of change, or critique without support to find an alternative.

We need to redesign go-live protocols and digital governance processes so that they are contextual, and encourage creativity, responsible design, and learning over compliance, oversight, and risk-avoidance.

Canada isn’t alone in having departmental funding models that reinforce outdated ways of working; written from the UK, Emma Stace’s excellent list of top issues facing government in implementing digital, data, and technology strategies captures this well:

Funding can be a root cause of poor technology. Technology funded as a capital investment or project with a start and finish date not only locks in legacy thinking about tech as a ‘cost centre’, it also increases cost, duplication and fragmentation by effectively starting from ‘0’ every time.

Change the way your organisation funds technology by determining its value, not its cost.

Waterfall opt-out strategies

For teams in government that want to be agile – hopefully that includes you! – one way to navigate these constraints is to not structure your work as projects, since formal project gating requirements originate in government-wide project management policies. Remy Bernard from ESDC’s IT Strategy team has a really interesting post that looks at this in more detail.

Projects by definition have a defined start and end date; most government services don’t “stop” at a specific point in the future. Structuring improvements to existing services (or the development of a new service) into a time-bound “project” is another waterfall side-effect that leads to semi-abandoned, legacy systems that still power critical public services but that don’t have an ongoing team or funding available to keep improving them. Projects are “done”, but software that’s actively being used by human beings never is.

In departments that have funding already available, teams might be able to describe their work – accurately – as an “initiative” or as a service, which is a better articulation of responsible stewardship of critical systems than a time-limited project would be. Some departments’ financial approval processes consider any initiative larger than $2 or $3 million a project “automatically”, making this strategy less feasible. If nothing else, that’s extra motivation to keep your IT initiatives small and incremental.

For departments that are seeking new funding, the strategy I’d strongly recommend is to seek funding for teams, not projects. This avoids baking untested assumptions into project plans and funding proposals. The team, once it forms, is better equipped to iterate, gather feedback, and change approach based on what they learn. And, ideally, they can continue incrementally improving their IT systems and services well into the future, beyond the constraints of a project end date.

One of the critiques of agile software development that frequently comes up is that “it’s workable for smaller, experimental projects, but it doesn’t work well for really big projects”. The truth (as one of Paul’s colleagues at GDS once said) is that no one has a process that works well for larger projects. Larger projects just tend to go wrong, whether you use agile or SAFe or PRINCE2 or any other project management approach. You just shouldn’t do mega-projects.

I’d love to see the project gating framework and related policy requirements be formally deprecated in the future; it’s a decades-old relic that has more downsides than benefits. Getting rid of project gating is asking a lot of senior public service leaders – to do things smaller and more incrementally, to trust their teams, and to relinquish a degree of control (especially if they’re in an oversight or gatekeeping role that’s outside a team’s own reporting hierarchy). But the longer we keep it, the longer we’ll be stuck in a non-agile past.

A huge amount of mental energy goes into ppl trying to justify/rationalize/inject waterfall thinking into Agile. Estimates, up-front architecture & other rigid plans, tactical roadmaps—all waterfall artifacts that hinder, not help. That energy would be better spent working.
— Allen Holub. https://linkedIn.com/in/allenholub (@allenholub) August 16, 2022

Interested in learning more? Unit 3 on Iteration of the Teaching Public Service in the Digital Age publicly-available syllabus is a great, in-depth read. This Beeck Center case study – Lessons from the Digital Transformation of the UK’s Universal Credit Programme – is also a fantastic summary of what doing this work well looks like.

Public service heroes: Chris Allison

Fri, 12 Aug 2022 07:39:07 -0700

In the federal public service, so many of the building blocks of digital government and tech modernization are thanks to Chris Allison. An early leader of the GCtools team and the CSPS Digital Academy, he’s now the Chief Data Officer at the Public Health Agency of Canada. He’s also perhaps the only senior federal public service leader who is fluent in Python programming. He’s a lifelong hero and inspiration of mine; we spoke on May 3.

Sean: For introductions, tell us who you are and where you work these days!

Chris: Hey! Chris Allison, I’m the Chief Data Officer and DG for data management, innovation, and analysis at the Public Health Agency of Canada.

Nice! I’m guessing that keeps you busy…!

It does! It does. The School was an amazing place to learn and grow, but PHAC is an exciting and very busy place to be.

I can imagine. As a lot of folks know – you were doing digital government since the earliest days, almost kind of before it was cool. How did you originally get started in the public service?

Oh – in the public service? I was living in Japan, in the year 2000, and I had been teaching there – teaching English as a Second Language in Osaka for a few years – and decided I should actually grow up at some point, so started looking around for jobs back in Canada. I applied to a Post-Secondary Recruitment campaign, ended up getting accepted for a couple of jobs, and started working with Immigration Canada as an Immigration Enforcement Officer in Toronto.

Whoa, no way. I did not know that. How did you eventually make the switch from what sounds like more front-line work to government tech?

It was a very gradual switch. I did three and a half years of front-line immigration enforcement, investigations, removals, war crimes work with CIC (Citizenship and Immigration Canada, now IRCC). I then quit and joined the Mounties. I was a Mountie for close to 4 years; then I quit the Mounties and joined the public service proper, and joined CBSA (Canada Border Services Agency).

And around that – a couple years later – I was a manager in CBSA, and I started doing a lot of work with Excel actually. And just kind of, really getting into first of all the functions and the way you could set up and automate things in Excel, and then into the macros you could use, and using it basically to do rudimentary data analysis, forecasting, things like that – that were super useful to the team and then to the organization. And that kind of started me on that pathway.

But then it was a few years later – I had joined Public Safety – I did a bunch of data analytics in Excel on HR and the PSES (Public Service Employee Survey) and then came back to CBSA, and I was responsible for a team that was supposed to build the first border app.

And I ended up in this labyrinthine Catch-22, where I was trying to work with the CIO organization to find out, “how much will it cost to build an application?” And their answer was, “well, we can’t tell you until you reach Gate 1”. Okay well, “How do I do that?” “You can’t reach Gate 1 until you have got approved funding for the work”.

So then I went to Finance and I said, “Okay, I need to have approved funding so I can get to Gate 1”, and they said, “how much money do you need?” And I said: “I don’t know. They won’t tell me.”

So I spent six months in this “Bermuda Triangle” trying to figure out, how on Earth can I get someone to tell me something about how to use technology in government? And nobody could or would.

And so I basically said, “screw it. I’ll need to figure this out myself.” At this point in time – I was playing too much MechWarrior Online – and I said, “I could probably be doing something more productive here” so I started learning how to program Python.

Wow, nice.

And that was the start of the path, I guess, to actually getting into dev and data and analytics proper.

Amazing, that’s phenomenal. That’s a cool origin story, I mean especially as one of the biggest champions if not the biggest champion of data science work in the government nowadays.

And maybe something important is, I was probably forty at the time, maybe forty-one? And no formal development training since high school when I was doing Java or something terrible. I was blown away by the ease of access and figuring things out – and then getting into projects, things that I wanted to do, and learning through those. The experience was phenomenal.

You’ve played a huge role in digital government work, from leading the GCtools team, launching the Digital Academy at CSPS, championing open source and modern tech in government from the earliest days… Have you seen a shift, from those early conversations with the CIO and finance people to, is technology work recognized at a public service-wide level? Or is it still for the most part, small teams, like “pockets of awesomeness”? Have you seen larger-scale changes over that time?

There are definitely larger-scale changes, in the acceptance and openness of government, that help, but are kind of peripheral to it in a way as well. We still haven’t dug ourselves out of the hole that probably occurred back when I was starting in government, when we thought we could outsource technology because it was this “thing” and the government would just buy it.

My feeling is, for the past twenty years, we have not had the capacity to do the technology and data work that we need to do in government, and so we’re always struggling. And when you throw a good solid dose of bureaucracy on top of that, it gets really hard to get things done.

And so you end up with a few people who are kind of the “bureaucracy hackers” – to pull on some of Nick Charney’s work – who also get technology, who are able to show up in a place and do things. And then they wow the people around them.

I’ve seen more and more of these places gaining traction, and doing amazing work once those skills are recognized, but it can still be really tricky depending on where you are.

That makes a lot of sense.

One thing I really like from your work is how tangible it is – a lot of efforts at digital government are often sort of, high-level like “here’s a giant strategy!” Versus, you have a list of awesome tips for data and AI work in government and it’s like: here’s the things you need, and it’s super down to earth. Do you find that that’s sort of a challenging space where people are at different levels on that?

No, I think it’s – definitely not challenging, I think it’s been super useful for my work and career. In terms of, thinking about value – strategies are great; you need to have one. But how much time do you need to build it? What does excellent look like? What are the opportunity costs of all the governance and planning work we do? What else could we achieve if we hit “good enough” and then got to work?

To frame this, practically, PHAC’s data strategy is really good. It was put together in 2019. It hits all of the things you need. You need interoperable systems. You need talent. You need people. You need access to good data. You need the tools and platforms so people can use the data.

And so coming in, even two and a half years later, we were able to look at it and say – you know something? This is good enough. It’s got all the basics that we need. We don’t need to spend another year and half reimagining the strategy. Let’s focus on executing it.

That’s awesome.

Bit of a jump but – if you had to choose just one moment in your public service career that was extra memorable or extra inspiring, what would that be?

That’s a great question. It would probably be the graduation of the first cohort from the Canada School of Public Service’s Digital Academy, the Digital Academy Premium.

Just seeing what public servants did, right? It was a hypothesis, we didn’t know if it was going to be true. But: what happens when you give public servants the tools they need? We gave them dev laptops, we trained them on Python, trained them on R, trained them on DevOps, trained them on design… We gave them time to do this stuff, without all of the constraints and other time sinks that we have in government, and gave them each other. We built these small multidisciplinary teams – taught them agile practically over the course of two weeks – and they absolutely rocked it. Fifteen teams.

This is what people can do. Folks in government. We’ve got the people we need; we need to give them the tools and the skills and invest in them, and just get the hell out of their way. Let them do amazing things.

Seeing that was awesome.

I really like that. It lines up really well with my own philosophy about how we can make the public service more awesome.

This is sort of a classic “Ask Me Anything” question that we have at CDS. If you could wave a magic wand and change one thing about the government or the public service, what would that be?

I ask that question too. But I don’t think it’s been asked to me in a long, long time.

I would crank up our tolerance to risk. And I’d actually change it to an appetite for risk. And not in a stupid way, but in a recognition that you don’t get to success in one hop. That it’s an iterative process.

And that everything we do – like, life is beta. Everything that we’re doing is, “hey, this is the thing that we’re going to do, and we’re going to do it, and we’re going to learn from it, and guess what: it’s gonna suck, because it’s the first thing we’ve done. But the second thing that we’ve done is going to come two weeks after that, and the next thing is going to come two weeks after that.”

And so we get out of the analysis paralysis space; we’re able to cross the execution gap because we’re not afraid of doing things. And I think, with that attitude, the people we’ve got – their ability to acquire those skills and do the things, and continue learning, based off that circuit – will really give us the workforce, the culture, and the proven track record of success, that government needs to have. And that our people in Canada deserve.

That’s a great way of putting it. I remember in an early CDS partnership, I think we were launching a website with a partner team, and there was lots of hubbub around “is the content perfect, is it finalized?” And I think it was Ryan Androsoff was like: “we can change it, after we launch”, and there was this jaws-dropping kind of moment. Of like, that’s a real change: things don’t have to be perfect the first time around, you can change them.

So I was actually with Ryan back in the GCtools, we had an overlap of four months when he was on his way out and I had come in. There was a moment in that point in time – and it’s kind of funny, because the GCtools team became a model for the multi-disciplinary team –

In a huge way, yeah.

But at that point in time, there was literally: one side was the business team, and there was a long empty hallway with nothing inside, just a long empty hallway, and the dev team was on the other side.

And the way that the team worked was, the business team would draft an MOU every year with “these are the deliverables that we need to have from the dev team”. And the dev team would update it, and then both directors would sign it, and then, that was basically it.

So the business team would be sitting there waiting for the dev team to do their stuff that was in the MOU.

Whoa, I did not know that!

So, one day there was a bug on the platform. The text in the search bar had turned to white for some reason. So you couldn’t see what you were typing, because of course the background colour is also white, so you’ve got white text and no one could see what the hell they were typing.

So it was like: oh my gosh, what are we going to do? Normally, we’d submit a ticket, but that takes time, it’s a process and our users were suffering here… So Ryan and I both walked down this long, straight, empty hallway, got to the other side, went around the corner, and said, “hey look, users are reporting this”.

And one of the devs, listened to us, said “oh, okay!” and they went in, tappity-tap, changed the font colour, and it was done.

It was like, “hold on, we can do that?” Yeah, you can do that. When you have the technology people, the devs, the data people, working with the business, you can do that. You can make the changes you need, you can iterate, and you can actually provide really, really good service.

Nice, that’s awesome.

Thanks for taking the time to chat – any last closing thoughts or closing ideas? Thoughts about the future of the public service?

Yeah! That’s where I’m going. The public service needs people with the skills for the future of government. A lot of those skills are technical. Honey has a great quote: “it’s not about the technology, until suddenly, it absolutely is”. Right?

It’s about the people, it’s about the culture, it’s about the business, it’s about the design, it’s about the service – what are you trying to do? But then, I mentioned the execution gap. We need to have the folks that can help us cross that gap.

Without the engineers and technologists, without the people who can actually do things with technology, government keeps getting to the point where we’ve got great ideas, we’ve thought about it, we’ve consulted, and we hit a point where we’ve basically got two options. One, we can do procurement, which will a) crush our souls and b) take two years; or, two, we can ask the CIO, who has a dozen priorities and a thousand problems. Our brilliant idea isn’t going to be on that priority list.

And so great ideas and better services perish.

We need to recognize that data and technology are core business to the Government of Canada. We can’t actually be successful without them. We need to start building skills and practices that support their use into our organizations, build it into the DNA of the orgs, and how we operate and how we hire and how we think. That’s what a modern government looks like, and that’s where, hopefully, we’re on the path to get to.

Shrink projects to fit leadership turnover rates

Tue, 09 Aug 2022 13:15:19 -0700

A few years back I remember reading about bike infrastructure improvements in Seville, Spain, where the city had built 80 kilometres of protected bicycle lanes in 18 months. (Ottawa’s protected bike lanes on Laurier Ave. and O’Connor St. are 1.5 and 2 kilometres respectively). The key to Seville’s approach was starting and finishing the infrastructure project within a single mayoral political term.

So many urban planning projects fall apart when city or regional government leadership changes take place. (Ottawa’s first attempt at a light-rail system – cancelled in 2006 after being approved by the previous city council – is a good example of this.) Engineering and construction projects can take a decade or more, from initial idea to completion. In Canada (where cities are chronically underfunded, and depend on provincial and federal funding for major infrastructure projects) that can mean two or three elections at each of the three levels of government over the course of a project.

If a project takes 10 years, an unfavourable outcome in just one of up to nine (!) elections could result in it getting paused, cancelled, relitigated or redesigned. There are a lot of examples of this. As the saying goes, that’s why we can’t have nice things.

For urban designers, the Seville approach is valuable because it gives citizens a chance to see the benefits of a project firsthand and in a tangible way. Years’ worth of mockups and project plans on paper don’t have the same effect. Other civic leaders – particularly New York’s former transportation commissioner, Janette Sadik-Khan – have run with this idea by prototyping new bike lanes and protected walking areas using inexpensive concrete barriers and pylons. Doing this demonstrates why something is valuable (especially if it’s controversial), and it can be done practically overnight – much faster and cheaper than, say, digging up and replacing an entire street.

A pedestrian-only street in Victoria created with pylons, planters, and wooden seating areas.

Government IT and the slow failure model

Large government IT projects have an entirely different set of problems, but the same Seville-inspired solution. (And yes, applying urban design ideas to public sector tech is pretty much my favourite.)

Much like major infrastructure projects, government IT projects are typically years long, cost millions of dollars, and are managed using a very linear, waterfall planning process. Even more so than physical infrastructure, government IT projects depend inherently on unpredictable human behaviour: how will people interact with the service the IT project enables? Will they be able to use it? If societal and political priorities change, how quickly can the IT project be updated to match? This human angle is partly why ideas taken from traditional infrastructure – like enterprise architecture, or waterfall planning in general – don’t work well for IT projects.

Government IT projects have a long track record of failure, and waterfall planning is a major root cause. Assumptions about how a system will work – and about how human beings will interact with it – are made without feedback from users, and baked in at the very outset of projects. Detailed project plans and approvals leave little to no room to iterate even when it becomes clear that something is on the wrong track. Complex and burdensome budget and approval requirements incentivize “everything and the kitchen sink” approaches to project design, where creating a large mega-project saves having to go through approval steps multiple times.

Compounding all of this is that most major IT projects outlast the executives that are nominally in charge of them. If a typical government IT project takes 3 to 6 years, from idea to completion, then it might go through two, or three, or four executive leaders at each layer of the management hierarchy. With no one dedicated at the helm, a project’s own momentum can easily carry it along a failure-bound trajectory. For years.

Deputy minister and assistant deputy minister turnover is estimated at 1-3 years in the same department, based on biographical data from announcements on changes in the senior ranks of the public service. For any given large IT project, senior leaders are likely to arrive after it has already started, and depart before it finishes. Being on deck when a project is “completed” and launches is, in fact, something most senior leaders would prefer to avoid – since, for waterfall projects, this is typically the point of first contact with real human users and the moment when a slow failure becomes a politically-damaging failure.

The high rate of leadership turnover and the years-long duration of projects means that no senior leader is personally responsible or accountable for a project’s success. On top of that, public sector organizations tend to create committees to govern or oversee major projects (often involving nested sets of committees at each layer of the management hierarchy). This further diffuses responsibility away from any single actor. As a result, no one individually takes the blame for failure (which is appealing), but no one is able to stop or meaningfully alter the direction of a clearly failure-bound project.

(In the private sector, this tends to look very different; Steve Jobs is the canonical example of a leader with a sense of complete and personal responsibility for every single part of a product. It’s easy to take this too far, as was likely the case for Jobs, but it was very clear who felt accountable for the success or failure of Apple’s products.)

Large government IT projects often end up with convoluted and unclear lines of accountability. They might be shared between several departments; they might have overlapping or conflicting responsibilities between teams within each of those departments. For each team and each department, it’s not unusual for everyone involved to say “our part worked” even when the project ends in disaster. These convoluted lines of accountability happen because no one wants to make difficult decisions about intra- or inter-departmental ownership of the project – where good outcomes require saying no to people. Instead, you end up with a massive set of involved stakeholders and organizational dependencies. Let that play out over several years – where each of the individual people involved changes several times, while the project continues apace – and it becomes a surprise when projects occasionally work out after all. Failure is the regular outcome.

Smaller and better

What does doing this better look like? There’s two overall remedies:

Reducing the number of stakeholders and oversight actors involved in a project
Shrinking the project timeline so that it fits into a smaller number of leadership turnover cycles (ideally, one)

In the first case, this includes eliminating committees, delegating decision-making powers down as close as possible to the product team actually doing the work, and removing dependencies on other teams and other departments (including, if you have one, your centralized IT infrastructure department). Each of these is intended to re-gather decision-making responsibilities and accountability to a smaller set of actors (ideally a single empowered leader who is formally responsible for the project achieving successful outcomes).

In the second case, this involves breaking up large projects into smaller pieces, each of which are shorter than the leadership turnover rate of your organization (e.g. less than 2 years, if that’s the average length of time an executive is in the same role). The really important requirement here is that each of those smaller pieces actually adds value on its own, rather than only being useful if all of them are completed at the very end.

Breaking a project into phases that will only be useful when the last phase is finished is “false incrementalism”. To be useful, each of the small projects actually need to be shipped – one at a time, as they’re finished – and deliver tangible value to the public, even if none of the subsequent future phases were to go ahead. There’s a great quote from Dan Milstein (via Paul Ramsey’s excellent Small IT presentation) that captures this:

Fortunately, there’s a very simple test to determine if you’re falling prey to the False Incrementalism: if after each increment, an Important Person were to ask your team to drop the project right at that moment, would the business have seen some value? That is the gold standard.

Shipping small projects regularly over time (instead of one mega-project at the end) has an additional benefit. You get feedback from the public – is it working? is it easy to use? – much earlier than in a traditional waterfall project. You then need to be willing and able to incorporate that feedback and make changes as a result, which is where having a single empowered leader rather than a diffused set of committees is particularly important.

How big is too big?

The research is pretty clear: IT projects larger than $10M have a consistently high rate of failure. Software experts in the US government suggest that, in order to be successful, IT projects should be delivered in less than 6 months and have budgets smaller than $2M.

The best overview of this that I’ve seen is Waldo Jaquith’s presentation to the Michigan Senate from early 2020, it’s a must-watch:

In Canada, we don’t have any consistently-published data on the size and timeline of federal government IT projects. On several occasions, however, Members of Parliament have submitted written questions asking departments for details on government IT projects over $1M. Together these paint a really interesting picture of Government of Canada IT spending.

Over three points in time – 2016, 2019, and 2022 – we can see the total budget and estimated completion date for each project. It’s an imperfect overview, in part since it doesn’t indicate when projects started (to gain a full picture of project timelines). For projects that reappear in more than one response dataset, we can see how their budgets and estimated timelines have changed over time.

The Government of Canada’s largest ongoing IT projects, as of April 2022. See the full list

Of the 192 projects that appear in more than one dataset, 86% are behind schedule, 9% are on schedule, and 5% are ahead of schedule based on the estimated completion dates provided.

Looking at the 2022 dataset, the average project duration is somewhere around 3.4 years and the average total budget is $14.6M. We have a long way to go if we want to achieve the recommendation to have projects that are less than 6 months with budgets smaller than $2M.

Making this happen in practice

The problems that governments seek to solve are complex; it’s easy to read this and think “that’s impossible, there’s no way we could achieve this goal in less than 6 months”. The key idea is, figuring out how to break a larger goal down into small, achievable, individually-useful parts.

Let’s take the Phoenix Pay System as an example, every public servant’s favourite project to armchair quarterback (mine too!). Phoenix took 8 years from idea to “completion”, when it launched in 2016, and it’s taken 6 years of work since to get to a place where it works almost smoothly. It was originally budgeted to cost $309M, and by 2018 had cost $1.2B.

What would it look like to deliver Phoenix (or a Phoenix replacement) as a set of small, incremental, less-than-$2M projects that were individually useful? Imagine it’s 2016. Here’s the small pieces that I’d have suggested building:

A calculator, that ingests a given set of pay information (classification, level, and step; union dues; leave information, etc.) and returns an example paystub for the requested date (approx. 6 months to implement)
- This could be done for one collective agreement group at a time, written in an easy to understand scripting language (such as Python), fully open source.
- Once a single collective agreement group’s set of pay rules was integrated, I’d run it as an online service where public servants could input their own pay situation (or an example situation) and generate example paystubs. It would be useful from this point on as a way of checking if existing paystubs (from Phoenix or its predecessor systems) were accurate, or if there were any errors in the calculator’s own pay rules.
- Entering each collective agreement’s pay rules would be a painstaking, but straightforward process. Making these open source would be critical, since it would let public servants at large confirm that they’re calculated properly (something, let’s be real, we’d all be highly motivated to do!)
A database, to store public servants’ pay information (approx. 3 months to implement, plus 9 to 12 months for security assessments and approvals)
- This would be built using an open source database (such as Postgres), hosted by a managed cloud service provider, with extensive audit logging and security controls.
- Keeping the calculator (above) as a standalone system that doesn’t store any public servants’ information would allow it to be shipped quickly and publicly tested out in parallel with the longer-term security work for the database.
A set of API connections and scheduled processes, to ingest updates from departments’ HR databases, send them to the calculator service above, and send the results to payment processing systems to pay public servants each payday (approx. 6 months to build, cumulatively, and 6 to 12 months to test before using in practice).
A user-friendly interface that lets public servants review their paystubs and pay history (approx. 6 months to build, plus continued iteration over time).
- In practice, an in-house team at PSPC built MyGCPay, a genuinely beautiful version of this several years later. It’s far and away the nicest and most professional online service to emerge from the Phoenix project.

Software systems can be intimidating, but ultimately they all consist of interfaces, data, and math. Each of these are pretty straightforward when you break them down into small enough pieces.

It’s easy to solutionize – especially with several years’ of hindsight! – and the danger of these kinds of exercises is getting too far into detail before learning anything from research with users. (That’s exactly the problem with waterfall planning, too.)

The main takeaway though is that, for any given project, my advice would invariably be: ship it to the public and learn from what happens. Do this as early and as frequently as possible, in a safe environment (e.g. through simulations, beta testing, sample data, clear processes in place to seamlessly revert errors, etc.). Break things into smaller pieces that let you gather feedback sooner, and that provide a tangible benefit to people one step at a time.

If nothing else, then as an IT leader going from one department to the next, you can show that you actually shipped something to the public, and that it actually helped people. All things considered, that’s a rare and wonderful thing.

Postscript: is fast possible?

Whether it’s urban infrastructure or government IT, it’s easy to get stuck thinking that years-long projects are the only possibility. When that’s all we see, it trains us over time to expect that that’s normal.

One of my favourite webpages on the internet is Patrick Collison’s Fast. Patrick is the CEO of Stripe, and his list of fast projects is a great reminder of what’s possible. The Empire State Building was built in 410 days. The 2,700km Alaska Highway was built in 234 days. The Eiffel Tower was built in 2 years and 2 months. The first US jet fighter was designed and built in 143 days. The first version of the Unix operating system was written in 3 weeks.

It can often seem like these kinds of quickly-delivered projects were only possible in the past, unencumbered by modern regulations and social or environmental protections, or accelerated by wars or other global events. To the extent that our regulations and processes slow things down today, I think the answer for major infrastructure projects is the same as for IT projects: break things into smaller parts that are still independently valuable.

If an infrastructure project is going to take a decade, do environmental assessments for several different variations of it, knowing that future decision-makers may choose differently when you’re no longer around. Make them all public. Gift ready-to-go options to your successors. If you’ve been elected into a decision-making role, have the humility to continue imperfect half-finished projects if they’ll deliver greater public good than harm. Do what you can to speed things up. Deliver useful things in incremental steps. Then, once people have had a chance to experience them, get feedback, learn as much as you can, and go from there.

Worth reading: Government from home & A Shared Future of Work

Sat, 30 Jul 2022 07:01:10 -0700

Public service departments’ “return to office” plans have been a hot topic over the past few weeks. After more than two years where a large proportion of the federal public service switched to working from home, departments are planning to require that staff come back into the office at least a certain number of days per week.

Meanwhile: COVID-19 is still happening.

The reaction to messages and town halls from public service leaders as these plans have been announced hasn’t been pretty. Amidst all of this, Michael Karlin and Steph Percival wrote a couple of pieces over the past week – Government from home and A Shared Future of Work – that capture the present moment incredibly well. Everyone in the federal public service should read them both.

In addition to the steps that government departments should take to make returning to offices safer – open data on exposures, CO2 meters on building floors and ventilation improvements, mandatory mask mandates, and changes to sick leave and additional sick days – Michael points out that a return to office along pre-2020 lines has implications for national security and government continuity that thus far haven’t been part of the conversation:

Looking beyond the individual worker lens, there are very real national security and continuity of government concerns to have teams brought together in a single, indoor physical space for mandatory “anchor” days. BA.5 being incredibly infectious, it can introduce the possibility that entire teams become infected, leading to a situation where work of that team simply stops or people are pressured to work through their illness. Public servants are incredibly dedicated and already I’ve seen several in different departments work through COVID infections or significant Long COVID symptoms at home. This unwavering dedication can make their symptoms last longer.

Moving beyond the pandemic — or at least this one (looking at you, monkeypox) — we have to think about climate change and infrastructure. 2022 has been a particularly wild weather year worldwide. It is highly probable that continued climate change will bring increased changes of extreme weather events that will test our infrastructure. Just look at the May 2022 Ottawa derecho that caused the most damage to our electric transmission infrastructure in history.

This means that even if there is a return to offices, teams should not return together to the same office. Ideally there is some degree of dispersion, and even more ideally this dispersion is beyond the same city. The strategy should be to minimize the threat surface to any given function of state. Therefore if there is a bad outbreak on a floor of an office it may only affect a small amount of capacity from several teams than a large amount of capacity from one.

There are a lot of benefits to working from home: reduced greenhouse gas and climate change impacts (from less commuting), more flexibility for parents and caregivers when they need it, a reduction in workplace harassment and discrimination, a more adaptable working environment for people with disabilities, and a public service that more broadly represents the geographic and cultural diversity of Canada.

Remote work is an accessibility issue. It can significantly reduce barriers to work for people with disabilities. The false narrative that working remotely, especially from home, is not "real work" or "lazy" is extremely ableist.
— Ahmed Ali (@DrAhmednurAli) July 21, 2022

If you think collaboration is best done in-person you might: be an extrovert, be neurotypical, be white, not have a disability, have not yet had a good digital collab experience.
— Rachel Muston (@rachelmuston) July 20, 2022

Even if none of these are sufficiently compelling arguments, then purely for the sake of business continuity departments and public service leaders should be thinking about a geographically-dispersed future workforce.

Workplaces where people thrive

Steph’s piece looks at the bigger picture of how workplace decisions are made, how they are implemented and communicated to staff, and what it means to have workplaces where people thrive:

The design challenge posed by modernizing how and where we work isn’t simple. The fact is there are people who thrive working from home, people who thrive working in a traditional office setting, and people who thrive from having the fluidity to move between the two with ease.

When it comes to building flexible workplaces, there’s an entire spectrum of work that needs to be considered, from location-specific roles that allow for little flexibility (think on-site service delivery, for example) to roles that can be effectively completed from home 100% of the time, and everything in between. Most organizations have roles that fall into every category on this spectrum, so even within a single department or agency, creating one standard to rule them seems insensible.

Yet it seems that many organizations are taking the approach of setting a 2-day in-office standard, even – bafflingly – for people who don’t work in the same city as the rest of their team, for the purposes of experimentation.

Given how the return to offices has been framed as an experiment, Steph looks at how experiments should be structured – as a process for systematic and transparent learning – and at ethics considerations when conducting experiments that involve people. Her reflections on what a better future could look like are absolutely spot-on.

Power dynamics and “hybrid” work

Conversations about the return to office and hybrid work have been confusing (to employees and executives alike) since the word “hybrid” tends to be so nebulously defined. Generally it tends to mean, “some mix of in-the-office and at-home work”, particularly in contrast to either fully remote or fully in-the-office approaches, as Steph describes above.

The challenge is that there is a large and fundamental difference between “a mix, but according to the instructions and schedule of the employer” and “a mix, but at the employee’s discretion”. The “what” might look identical in both cases (e.g. employees coming into the office some but not all of the time) – hence the confusion – but the power dynamics in both situations are near-opposites.

Being able to choose if and when to come into the office lets employees make choices that reflect their best working styles and their level of comfort or concern about COVID-19, and to adjust these individually as the pandemic continues to evolve. Progressive organizations will keep that level of employee choice when the pandemic ends, I’d expect, to improve employee happiness, productivity, and retention.

Knock-on effects

Decisions like these don’t happen in a vacuum. In the case of return-to-office plans, I can only guess that one of the upstream factors is public and political dissatisfaction with the quality of government service delivery over the past few months. Kathryn May’s newsletter offers a good summary of this.

In the face of widespread public dissatisfaction with overwhelmed passport processing, slow airport security and customs lines, and other disappointing points of interaction with the federal government, the idea that public servants are uniquely able to work from home adds another layer of resentment. Public perception that government workers are coddled or lazy has political consequences, especially when it is (even if inaccurately) seen as a root cause for poor-quality service delivery to citizens.

Essentially: a premature and unsafe return to office is the belated political cost (to working-level and executive public servants alike) of decades of under-investment in public-facing service delivery.

Avoiding this, of course, would have meant investing in significant improvements to public-facing services years ago – alongside changes to public service culture and organizational processes needed to make those improvements feasible. As the saying goes, the second-best time to make these changes happen is right now.

A loss of confidence…

The downstream effect of current return-to-office plans is also worth thinking about. The most immediately-visible result is a loss of confidence (on the part of working-level public servants) in public service leadership. Town halls and messaging has been perceived as out-of-touch and elitist. Underlying rationales and evidence (if any) behind decisions and timelines haven’t been shared. As other commentators have said – the concern isn’t just that leadership decision-making on return-to-office plans is out of touch; it’s that leadership decision-making in general is.

(As a caveat: my perspectives on this at the moment are all second-hand. Departments aren’t homogenous entities, and from what I’ve heard some public service leaders have shared the pressures they’re under with a lot of candour and openness. If that’s you, you’re awesome. Keep on rocking.)

For leaders across government, a pressing question is how to repair a sudden and significant loss of trust in the decisions that they’re making, on the part of their staff. I don’t know what that looks like (and I am, very gratefully, not a manager or executive) but I think a first step would be to admit that mistakes were made here, and to postpone or change at least some parts of return-to-office plans. And to thank working-level public servants for sharing their concerns and feedback! The public service has a very strong hierarchy, which could make it tempting for leaders to ignore these reactions and double-down on current plans; I think that would be an error. Daniel Blouin’s thread on how managers can protect their employees from poor-quality decisions made further up the hierarchy is also an important reminder.

…and a loss of good people

The longer-term downstream effect is, of course, the loss of talented and capable public servants to other employers (either to other levels of government, non-profits, or the private sector). It’s already incredibly difficult for the government to hire people in specialized technical fields (like data science and software development); forcing a return-to-office and relocation to the National Capital Region will definitely make this problem worse.

Archived tweet from Jordana Globerman

In the case of at-scale changes that have negative effects on employees (like hiring or salary freezes, workforce reductions, or, in this case, returning to physical offices during an airborne pandemic), there’s also a filtering mechanism that takes place. In the public service, despite an array of performance measurement activities (like annual PMAs), it can be hard to effectively differentiate high-performing and under-performing employees. High-performing employees (fast workers, creative thinkers, institutional memories and foundations of their teams, etc.) often don’t have the time or patience for individual performance-reporting activities, while under-performing employees can become adept over time at gaming these systems to appear more productive. The rates at which public sector organizations fire people is also vastly lower than in the private sector.

In that context, the best measure of high-performing versus under-performing employees is that high-performing employees can get jobs elsewhere, and will, when the working environment they’re in, in the public service, gets worse. Under-performing employees will stick around, and the overall capacity of the public service will get worse on average as a result. Learning that a team-wide, department-wide, or government-wide change in working environment has led to a great employee’s departure is a really unfortunate time to discover that.

Poor feedback loops between employees and senior public service leaders is a chronic problem. Given the hierarchy and power dynamics of the public service, this can only change from the top down.

An Aranet4 CO2 sensor on the corner of my desk. You can buy these online or at Canadian Tire. If you’re a federal public servant and you’re interested in getting one, send me an email! I don’t have any financial or personal interest in these companies; I just want you to stay healthy.

For perspectives on what a safer vision for adapting to COVID-19 would look like, Dr. Lisa Iannattone’s Twitter feed and Alanna Shaikh’s newsletter are both great resources.

Public service heroes: Madelaine Saginur & Melissa Toutloff

Mon, 11 Jul 2022 14:07:27 -0700

Madelaine Saginur and Melissa Toutloff work at the Privacy Management Division for Health Canada and PHAC. They’re two of the most kind and most brilliant public servants I’ve ever worked with. We worked together from the earliest days of COVID Alert onwards, and the app’s positive reception from Canadian privacy experts is very much credit to the two of them and their (equally brilliant) director Andréa Rousseau. I learned so much from them both on privacy policy and legislation along the way. We chatted on May 10.

Sean Boots (SB): Let’s jump into it! For introductions, tell us who you are and where you work! Whoever wants to go first.

Melissa Toutloff (MT): Go ahead, Madelaine.

Madelaine Saginur (MS): My name is Madelaine Saginur and I’m the policy manager at the Privacy Management Division for both Health Canada and the Public Health Agency of Canada. I worked with Sean for a couple years on the privacy analysis of the COVID Alert application.

SB: Woot! How about you, Melissa?

MT: I’m Melissa Toutloff, I’m the senior policy analyst at the Health Canada and Public Health Agency of Canada Privacy Management Division. I work with Madelaine, and I also worked with Sean on the privacy analyses for the COVID Alert application.

SB: Aw yeah! That was a very exciting time.

Both of you are next-level privacy experts. Even before that, how did you originally get started in the public service? What did your career journey look like off the bat? Melissa, did you want to go first?

MT: Sure! I started off in the public service as an FSWEP student, while I was in university in my undergrad. And then after graduating university, I was able to be bridged in. I was really lucky out of university that I got an indeterminate position.

My first position was as an administrative assistant in the ministerial planning and coordination division at Indigenous Affairs. My primary role was to help prepare the briefing binders for the minister and senior management. It’s basically, these massive binders with everything they needed to know for the week. Super old-school by today’s standards.

And my director in ministerial planning and coordination, while I was still there, moved on to the position of ATIP director at the same department, and she encouraged me to apply for a junior privacy policy officer position; they were rebuilding their privacy policy unit. She suggested that I apply and that’s actually how I got started in privacy, that was all fully back in 2011. So it’s been… 11 years.

SB: Amazing, that’s awesome! Madelaine, how about you?

MS: I’m not a career public servant. I worked outside the public service for over 10 years, before joining it. My interest in privacy – as well as data ethics and data stewardship – started while I was law school; I was a research assistant for a professor who was looking at the ethical, legal, and social issues related to genetics and genomics. A big issue – and this is in the early to mid-2000s – was privacy, not “how do we not do stuff to protect privacy,” but rather “how do we protect privacy so that we can do stuff?”

I worked with that professor for over three years, did a short stint in private practice, which was not for me, and then moved to a university research centre working at the intersection of law and technology. We looked at intellectual property, privacy and other issues that come up in digital spaces, like freedom of expression. While I worked there I snuck in an LL.M. in Law & Technology.

SB: Nice!

MS: I then joined the Office of the Privacy Commissioner as special advisor to the Senior General Counsel. I spent a few years there, and then joined the Privacy Management Division for the health portfolio.

SB: That’s awesome.

MS: I’m just going to add – even though it’s been six and a half years in the public service – I still feel like an outsider. I don’t feel like I have that “government mentality”.

MT: I think you should stay that way, Madelaine. Having an outside perspective is a good thing.

SB: 100%. I feel like I’ve been playing my “I’m new to government” card for like five or six years now, and at some point, people will be like “Sean, you can’t play that card anymore!”. That’s great.

Madelaine do you find – having a law background and working in tech – I feel like that’s a really useful intersection. Do you see more people taking that career path, or finding that half-law half-tech kind of role?

MS: It’s not a majority of law grads by any means, but there’s a growing number of people who are pursuing those kinds of roles, in the private sector, in government, in industry.

It’s a really interesting space because I think it works best when people with a lot of different backgrounds are involved. We need the people with the real tech expertise. It’s not going to work without them. But it is good to have people with legal backgrounds, policy backgrounds; I think we need more philosophers and ethicists at the table thinking about these issues.

SB: Melissa I was going to ask – as someone who ended up in the privacy field kind of by accident, would you have any tips for people who are early-career public servants or students who are interested in privacy policy? Like, here’s what you wish you knew when you were getting started?

MT: In terms of tips, I mean, if people want to get into it, there’s tons of opportunities; it’s a growing field. They can find contacts in ATIP offices. A lot of departments don’t have a separate privacy management division; their privacy policy function exists within their Access to Information and Privacy operations division. They can seek out contacts in those areas and there’s more hiring happening externally, so there’s definitely opportunities, and we’re always looking for people.

Really what we need is – we don’t need people with privacy expertise especially not when they’re starting out; you need people who are critical thinkers, who can analyze information, who can now, more than ever, think of privacy not just as its own issue, but in how it intersects with other social justice issues. For me, that was a point of interest. Privacy intersects with other social justice issues, like respect for democracy, avoiding biases and discrimination and prejudices; the world of privacy is really starting to encompass all of that, slowly but surely.

So, critical thinking skills, the ability to analyze; good writing skills, being able to take complex information and distilling it down to something that’s easy for non-experts to understand. A lot of skills that you learn if you’re in the social sciences area of study.

SB: That’s super helpful.

For both of you, if you had to choose one moment in your public service career that stands out as really inspiring or really memorable, what would that be? It doesn’t have to be COVID Alert, it could be anything. Melissa, did you want to go first?

MT: For me, it is kind of COVID Alert but in a broad sense. COVID Alert was definitely a major career highlight for me. Obviously it was an exciting file to work on; it was a tool that we knew would get a lot of attention, and that would also have a direct impact on addressing the pandemic. It was exciting for those reasons.

But it was also a novel initiative, and how we approached it from a privacy perspective was also novel. It really forced us to think outside the box as to how we were going to assess the privacy implications. Because we have all of these tools that we can use when we’re looking into, you know, activities and initiatives that involve a clear-cut collection of personal information.

But when it came to COVID Alert, there wasn’t a collection of personally-identifying information, but there were still some significant privacy implications to address. Particularly when it came to potential concerns from the public, and so in terms of “how do we assess this”, we had to sort of start from scratch.

And so we used the privacy principles that were developed by Canada’s privacy commissioners around COVID-19 initiatives, and in consultation with the Canadian Digital Service, you Sean and your team, we drafted a privacy assessment, and the entirety of which we posted online. Which for me was really exciting because – as far as I know – this wasn’t done in government before.

And we could have easily said, “there’s no personally-identifying information involved, the Privacy Act is not engaged; you know, see you later, we don’t need to be involved further”. And more broadly what was exciting for me is that a lot of the principles and ideas that Madelaine and I had been discussing over the past year, so even pre-pandemic, on how to address privacy implications in this digital era, overlapped with other issues we were thinking about like Gender-Based Analysis+. And doing so despite operating with an woefully outdated and ill-equipped Privacy Act, COVID Alert helped us put some of those ideas into practice. And so that was exciting.

And on a selfish note, when I have friends and family who are curious about what I do, I can tell them to look at the Privacy Assessment online, that I helped to write on COVID Alert, and that gives them a good idea, hopefully, of what I do.

SB: That’s awesome.

MT: But ultimately, too, it helped us to think about pushing past traditional ways of thinking around addressing privacy issues that are beyond a strict Privacy Act compliance perspective. If we continue to do things the way we always have, we may miss opportunities to take a deeper dive into initiatives that kind of sit in this grey area of whether the Privacy Act applies and whether there are privacy implications. And I think this ultimately helps build trust with Canadians when it comes to government use of data and their personal information.

SB: Super cool, both the fact that privacy work was the angle to public trust and buy-in, and yeah! Also nice when you can – for all of us as public servants! – when our families are like “what do you do?!” it’s like, “it’s hard to explain!” So the fact that that’s out in the world is super cool, for sure. Madelaine, how about you?

MS: COVID Alert was a highlight of my public service career too! But because it’s taken…

Something that I’ve been working on, in an ongoing way for the last few years, is Privacy Act reform work. So this work is led by the Department of Justice; it’s their job to propose a new law, but they consult a lot with departments. They say, you know, we’ve written a whitepaper about this aspect of the Privacy Act, how do you feel about it? And we can write submissions back. I’ve written all the submissions for Health Canada and PHAC to the Department of Justice on Privacy Act reform.

SB: Awesome.

MS: Our Privacy Act is from 1983. And it’s just not really up-to-date anymore, to say the least. There’s a lot of things that it didn’t anticipate, and so in some ways, the Act is inadequate. For example it doesn’t say anything at all about security safeguards. There’s no requirement to have good security measures or encryption or anything. Why? Because when it was written, we stored paper things, and so you had to lock your cabinet and then you’re good to go.

And in other ways, it limits what you can do when in actual fact those things might have huge benefit and be low-risk from a privacy point of view.

So thinking about, not, “do we comply with the law or do we not comply with the law” in a specific instance, but, “what should the law look like? What do we want the law to be?” That’s definitely my happy place.

A big issue has to do with de-identified data. Everyone agrees, when the information very clearly identifies individuals, you have to comply with the whole regime of the Privacy Act in order to collect, use, and disclose that data. But what about when it’s more de-identified? Should the same rules apply? What if it’s really de-identified such that the risk of anyone being re-identified is approaching zero?

How can we facilitate things that are in the public good – in a way where we’re still really good data stewards – and we’re preventing actual privacy harms from occurring, or at least minimizing the risk of those harms?

SB: Solid. That’s exciting!

MS: It really is.

SB: Looking forward to where that all goes.

MS: I think we’re still a ways away from a bill, it’s all sort of background work now, but we’re hoping…

SB: I’ll add some future links in there, like, two years from now.

MS: Hopefully! If it’s two years from now, I’ll be delighted.

SB: Nice, amazing.

This is a question we often ask at our CDS “Ask Me Anythings” – if there’s one thing you could change, if you could wave a magic wand and change one thing about the public service – what would that be? Madelaine, did you want to go first?

MS: So I’m going to give a two-part answer.

First, it would be the way, most of the time, the public service thinks about risk. It’s not that I think we should be “risky”, it’s not that I think the “move fast and break things” mantra of high-tech companies is appropriate for government. We’re using public funds; we have different obligations; we fulfill a different role within society. I think it’s appropriate that we are on the more risk-averse side.

But what I find is that we only think about the risk of doing things. We don’t really talk about what the risks are of not doing things. If there’s a risk because, say, we can’t take that action and that might mean that something good doesn’t happen, that’s a negative effect as well.

So if I could wave my magical public service wand, it would be to change every single time risk is being considered, that both the risk of doing something and also the risk of not doing it factor into that analysis.

And second – something that makes me pull my hair out – is the level of reviews that are required, and how sometimes they are not exactly proportional, in my opinion, to the risk involved. It just adds a lot of time in terms of getting things done, and I think there’s a little bit too much of that.

SB: That’s a super great way of putting it. Melissa, how about you?

MT: My thoughts kind of dovetail nicely with what Madelaine was saying. The thing that comes to mind initially is, it’s always frustrating how much red tape there is in government. The numerous levels of approvals that things have to go through; how long it takes to get something off the ground… and on some level, like you were saying, Madelaine, you understand why it’s the case. Because we are public servants and we should be held to a higher standard of accountability, and that risk aversion can be a good thing that we’re not just jumping head-first into everything.

But, I want to see more meaningful transparency about what we’re doing. Why is it that posting the entire COVID Alert privacy assessment was unprecedented? I don’t think there’s a lack of meaningful transparency because there’s anything to hide, or there’s no willingness to do it; I do think that sometimes people are a little afraid of what the public reaction or media reaction may be. And of course there’s some limits to transparency, you know, such as security or national security issues. But I think this should be the exception rather than the rule.

By meaningful transparency, I mean: what are the ways that we can use to actually reach Canadians? Posting something on a website is one thing, but we may also need to go beyond the confines of our usual channels for informing Canadians. So, you know, what are the different tools that we can leverage to communicate information in public, and then use the appropriate language so that it’s meaningful and well-understood.

And I think that – when it comes to privacy, and really all the things that government wants to do – I think trust is essential, and that being more transparent will help build that trust. So I think, or hope, maybe, that going forward we’ll see more examples of transparency like we did with COVID Alert. Not just in my department or agency, but across government.

SB: Nice, that’s awesome. Completely agree on all of that. I’d love to see it. Thank you to you both for taking the time to chat!

Public service heroes: Beth Fox

Sun, 26 Jun 2022 22:00:25 -0700

Beth Fox is a service designer and digital strategy lead at the Nova Scotia Digital Service. She’s an amazing public speaker, a champion for users, an occasional blogger, a maker of awesome stickers and buttons, and one of my first-ever public service Twitter friends. We chatted on May 3. Ask her about her (excellent) sound-check warm-up phrases.

Sean: Tell us who you are and where you work these days!

Beth: I am Beth Fox, I currently work for the province of Nova Scotia. Specifically, I’m in the strategy, policy, and governance team as part of the Nova Scotia Digital Service.

You’ve been in the digital government space since before it really had a name – how did you originally get started in this kind of work?

It’s really interesting, I was thinking back – my actual first start in public service was in an employment insurance training work placement. I graduated university in the late 90s – so there, I’m dating myself – in a recession, with a bachelor’s in philosophy and a hard job market.

I got laid off from a really terrible service job, and I ended up on EI, but they sent me on this course for AutoCAD – electronic drafting before there was, like, iPads and things you could use. I actually landed a placement at Public Works and Government Services Canada (now PSPC). I’m mentioning that because I think we often underestimate pathways, and the value of those, for young people – and I was still young then – to get a taste of public service careers.

While I was working in that job, I took a bunch of training in web development on the weekends. And that led me to eventually join a really great team of web folks in Real Property services, in that department. We were doing what, at the time, was super leading-edge things, like building dynamic content before there was such a thing as content management. We were publishing web content, internally and externally. And when I was thinking back on this the other day, I’d say we really were laying the groundwork for what we might call a digital service team nowadays.

I was in a project management role, but I really functioned as a translator in that team. I was identifying needs, I was building information architectures, functional QA, feedback back and forth… and when I look back on that I realize, that was actually the beginnings of service design and digital strategy, we just didn’t have those labels back then.

What brought you from there to Nova Scotia?

Later, my partner and I relocated from Ottawa to Nova Scotia; I had to wave goodbye to Place du Portage. We started a family; I spent some time in the private sector, but I really missed being a part of a mission that mattered to me and the people around me that I cared about. Working in agency life, it just wasn’t for me.

And so luckily, I found my way back – into the Nova Scotia public service, in 2014, and joined to do UX work.

I remember, I think in 2017, seeing your CanUX presentation on UX (user experience) being more than a checkbox, which was phenomenal.

How not to be a checkbox!

Yeah! In your view, has design work become more established in government organizations since then? Does it have more of a home? Or does it sometimes feel like people still see it as a checkbox?

It’s tricky because – I think that the idea of UX has found a home. Living through COVID, we saw that: if you have bad UX, you’re going to blow up your call centre, all those kinds of things.

I think what’s interesting is: the transition from UX to service design has really made it so that – service design has a good foothold, but what happens then is that service design starts digging in on harder problem spaces. And that’s where we start to hit that friction against – I’ve actually literally been working on a presentation called, “Your UX isn’t pretty, it just looks that way.” Right?

Because when we’re only focused on the visual aspect and stuff we can see on the client interface or user interface, that part is getting easier to do, and to do well. The part behind the scenes, and the hard work to make things accessible, and getting government jargon out of content, background processes – all the stuff that’s not the stuff you see? That stuff is super hard, and it continues to be hard. And I think that’s just because you’re literally talking about systems change.

You’ve been a really big part of connecting public servants working in technology and design across Canada, like the Slack community that you launched with Susie Floresco – as far as I know, it’s the biggest community of public servants working in digital government in Canada. What’s it been like, building a cross-jurisdiction community of public servants?

I’m thinking back to that day when you were on a personal device [to use Slack], and we were having some kind of conversation about how there were so many barriers. Honestly? It’s been really self-serving, if I can be totally honest, which I know is going to sound off-brand for what people might think of me.

But: I was alone! I was a team of one, in this little jurisdiction, and I didn’t have people who knew what I was talking about, or they didn’t understand me. And so, building that community was really just, like: I needed to find people to connect with.

And of course, in the digital government space, there’s no competitive advantage between you having code, me not having the code, or whatever. And so I don’t think it took very much to just create the space for people to pile in. And to realize: we need each other, and we need that community, and we need those safe spaces where we can be empathetic with each other about the barriers and the hard stuff in digital government.

There’s been a lot of pressure over the years to say, can we just open this up? And it’s like, you know what? Sometimes you need a bit of a space where people get it, and where people can share without needing to worry about going to go and ask permission. Because that is the death knell of any good collaboration.

There’s lots of FPT (federal/provincial/territorial) tables and big structures, but I think about stuff that was happening during COVID, with Rumon’s team out in BC, and the Ontario peeps were doing cool stuff, and we were building stuff, and PEI was like: “we don’t have anybody to build stuff!” And we were like, “here’s the code!” I think all of us are working on the same things, and so building that community, for me, started as finding a place to feel less alone in the work.

And then it just took on a life of its own and became a thing that fed that need for everybody. And, spoiler alert: you could be in a giant jurisdiction, in a huge organization, and still feel really, really alone. And sometimes that’s a way to find people who are going to just be like: hey, it’s alright, keep going. Or: here’s the thing, I just saved you ten clicks. Whatever the case may be.

That’s a great way of putting it. There’s the sort of: you’re not facing this alone, you’re not the only person who is running into these challenges – the team spirit of, there’s a bunch of people cheering for you, even if they’re across the country.

And I experienced that internationally, too. The peeps at GDS, USDS, and Australia, and all those jurisdictions, they just openly shared stuff so readily. And I was like, why are we not doing that with Manitoba?!

If you had to choose just one moment in your public service career that was really inspiring or memorable, what stands out?

I think there’s a TSN Turning Point that I carry around in my head. I might have only been a year or two into my time at Nova Scotia, and I had joined this team with the intention of bringing human-centred approaches into online services. And I’m sure a lot of your readers will appreciate, that’s sometimes really hard to do in practice, especially as a team of one.

But anyhow! I’d been invited to speak at the annual meeting for something called GoverNEXT, I had just kind of connected with some of those folks. It was essentially, young keeners and change-makers in government, and they had this annual meeting. And they asked if I would share a keynote about being user-centred and user research. And was like: right on! I’m going to build a Prezi, which again, is like, who uses that –

Cutting-edge, at the time!

– and put all the smartest things I can think about in there, about why we need to shift mindsets. And at that point, I was admittedly, as a team of one, still pretty light on my own case studies. But there was enough material there.

But I also arranged to have 200 sets of my own custom buttons, the “Empathy Starter Pack”, I don’t know if you remember that – it’s the, “I am not the user”, “You are not the user”, “Let’s ask the user” – so I literally put those all on together in little sets. They were on every table. And, that was the big rally cry at the end of my presentation.

So I kind of showed up as my fully, authentic, most nerdy version of myself. But what I didn’t know, and probably it’s a gift that I didn’t know this going in, is that right after my keynote, in the organization of that day, the event organizers had this “Coffee with deputies” for all the people attending the meeting.

That actually meant that most of the most-influential senior leaders from across our provincial public service were just, in that room, for most if not all of my presentation.

Oh snap. No pressure.

And so I stood up to deliver this decidedly counter-culture sort of keynote, and I look up and I make eye contact at the back of the room with my relatively new-ish deputy of my department. Who I didn’t really know very well, and certainly wasn’t expecting to see at the back of the room, staring me in the eyes, along with the Clerk and a whole bunch of other deputies.

I took a big gulp, and then I continued, and I presented, in a fully-authentic way, without worrying about who was in the room. But I think I actually did make an impression on some people in that room. The deputy in charge of IT services was wearing one of my buttons later on, and I was like, oh, that’s amazing!

That moment, when I look back on it – it really helped make space, for sure within my own department, to give some of the air cover that I really needed for that early work. To show the value of user research, in particular; I was still, at that point, trying to convince people to let me leave the building. Our deputy is passionate about client service excellence. So the link between what she was focused on, and my proposal to “ask the user” – that wasn’t a hard stretch for her to see it was compatible, and make some space for it.

I think that opened a little bit of space for me to then actually start demonstrating the value of the work. Which is why, for me, I feel: as soon as you can get to “Show, don’t tell”, that’s when you turn the corner on things.

That was definitely a moment – I remember seeing her at the back of the room and thinking, “oh! I guess we’ll see how this goes”. I think I had bleeped out the swear words on some of the slides, so the swear word was there but it wasn’t written out, and I was kind of relieved that I had done that, at least.

That’s amazing. Sometimes, depending on the government organization, you often feel like there’s this big gap between people at the working level, or front-line staff, who really understand where things are broken, and it’s hard to communicate those things up to the very, very top. You did that, maybe almost by accident, but, that’s massive.

I think the Clerk may have, later on, like a year or two later, been talking to our CDO, and referred to me as “you know, the girl with the buttons!”

Iconic!

The beauty of this, for people who don’t know me – I’m totally into stickers and buttons. I have this whole collection of stuff. I mean, you and I have exchanged stuff; the “I know Sean Boots” button is one of my most favourite buttons. But anyway! That’s a non-threatening way to kind of – it’s really propaganda – it’s a non-threatening sort of “gimme” that you can get people thinking about stuff.

Definitely a turning point, I think, for what I was trying to message.

I have one of your “You are not your user” stickers on my CDS laptop.

The buttons got expensive, so we started making stickers after that.

If there’s one thing that you could change about the government or the public service writ-large, if you could wave a magic wand and change one thing, what would it be?

I’ve thought about that question – it’s a hard one to answer, because the systems thinker in me is like: well, how far do you want to zoom in or out, in the system?

Root cause, I think incentive structures are really what’s holding back so much. That’s what I would change.

It’s human nature to always do what gets positive feedback, or gets rewarded. Within public service, from what I’ve seen in Westminster public service, we have a lot of perverse and counter-productive defaults that are baked in to the fabric of how everything gets done. And a lot of this goes completely unexamined.

There’s a lot of what I would call normative culture entrenched into quote-unquote “successful public servants” and how they look and what they do. And our systems promote this so-called “professionalism” but that’s really just code for: don’t be emotional, or, be hyper-organized. People who make good presentations in front of large groups are labelled as leaders.

The unsaid flipside of that is: we’re excluding people who might process information differently. And those people are often more reflective, or thoughtful, than people like me who are just a really good showman. Or sometimes, we promote the people who “get shit done”, no matter the cost either to themselves or to other people. When I say that the incentives are skewed, that’s what I mean.

And, I would add that, in most cases, our current definition of what we consider to be desirable is based on one world view, that’s usually white, cis, het, not disabled, and neurotypical. And we really have to move past those ideas. Because they’re not only not-inclusive, but they’re harmful to everybody, including the people in that group. And I’m someone who benefits from all those things that I just mentioned, right? I’m part of the power that holds those defaults in place, and so I really consider it my responsibility to actively work to change those defaults.

I was thinking about incentives, and what would be different, like, how would public service be different if we incentivized totally different defaults?

What if we incentivized distributed decision-making, instead of being in the room?

What if we incentivized reflection and thoughtful response, over fast reaction times?

Or radical candour, over the comfort of people who hold power?

Or continuous progress, over, “we’re all done!”

Being an ally in the moment, versus being seen as being nice?

Or, learning and adaptability through failure, over this “knowing, certainty, minimized risks”. That’s one of those incentives that’s, just, totally backwards.

That’s massive.

It sounds like a lot; I realize, that’s a heavy list of things, but, I don’t think anyone is ever going to just come along and flip that switch or have that magic wand. And so I really think: for me, I’ve found that I can actually change my own default, and make space for, just, the people that are around me.

And, each and everyone of us can shift our own defaults. Not big, symbolic flourishes, but, literally holding ourselves accountable for what we incentivize in every interaction, every day, over time. That’s what’s going to have that big impact.

I like that. The sort of, making a difference in the small things, and then having that add up.

If you think of the idea of a fractal – when I talked at the beginning, zooming in and zooming out, what would I change? It’s like: what’s the pattern that’s repeating at every single scale?

When you zoom in really close, it’s the little pattern of, me and you and how we interact. And as you scale out into your team, and then into your ecosystem of teams, and then beyond your particular organization into the rest of government… If you’re repeating a crappy pattern at the small scale, it’s probably showing up at the big scale.

Really on-point. That was all the questions – awesome of you to take the time to chat! Any closing words?

I might just say: this notion of heroics, or, if that’s the label we’re putting on it? To me, I see so many people around me that are just, showing up, and continuing to show up every day and do all of these things.

If I can make Sean Boots’ list, I literally think anybody could. Don’t put on a cape… just keep doing what you can and take care of your mental health while you do that… and take care of each other, because we need good people to not burn out.

Enterprise architecture is dead

Thu, 23 Jun 2022 08:23:45 -0700

I wrote this piece in April, suggested by some friends who used to work as enterprise architects. Agree or disagree with the post? I’d love to hear your feedback!

When I rejoined the federal government in 2016, our team’s desks were (for a few months) around the corner from a large team working on a financial management transformation project. The walls in their area were covered in mesmerizing, plotter-printed posters detailing a web of interconnected IT systems, SAP S/4HANA icons in abundance. This was my first introduction to enterprise architecture (EA). If you haven’t worked in government IT, it can be hard to describe, but if you’ve seen business capability models, target state architectures, TOGAF frameworks, or architecture review committee presentation decks, hello. You’ve met enterprise architecture.

Coming from a tech startup, I found this all fascinating. We had architecture, we just didn’t have the posters and paperwork and processes that “enterprise” architecture had. In fact, we had a lot of architecture: building a mobile phone-based communications platform (voice/IVR and SMS) for use in developing countries around the world, you needed it.

We had our product’s online platform and interface running on AWS infrastructure in North America, and then we had in-country servers in almost a dozen countries in sub-Saharan Africa and parts of Asia (by time I wrapped up) that could interface with local telecom operator systems and APIs. Servers located in data centres in some of those countries had days-long network outages on a regular basis (“two nines” would have been a major improvement, as overseas network cables or centralized national telecom infrastructure sporadically went down). In 2014, we re-engineered our entire tech stack (splitting our platform into two software products) so that our in-country servers could operate fully independently of our AWS infrastructure, working locally and queuing up survey responses and system notifications to send back once the network came online.

None of this was standalone “architecture” work, even though in hindsight we could have made some cool plotter-printed posters. It was just a normal part of doing full-stack software development. You have infrastructure of different types in different places, and part of writing good code (and using managed services thoughtfully) is making sure it can reliably work together. To the extent that this is architecture work, it certainly isn’t a siloed, distinct role that’s separate from software development.

Promoted out of “doing” and into “watching”

In government tech work, standalone roles are all too common. Full-time enterprise architecture roles are an example of this, made more complicated by how they fit in the (now IT) CS classification framework. Here’s what a typical career progression might look like as a software developer in the federal government:

CS-01 (now IT-01) Junior developer, writing software or web applications with a lot of supervision.
CS-02 Developer, writing software as part of a team.
CS-03 Team lead (managing a small team of software developers), or technical advisor, or enterprise architect. (There’s some variety both in how these roles are labelled and in the types of work they entail.)
CS-04 Senior enterprise architect (or other specialist field, like IT security or database administration, as a senior technical advisor).
CS-05 Director-equivalent management role in an IT division.

In practice there might be years or a decade at each of these steps, partly because of limited internal career progression opportunities. (In many departments, you’ll need 10 years’ experience to qualify for CS-03 pools, let alone progressing to CS-04 roles and beyond.)

What that means is that, by time someone reaches the CS-04 level and is working as a senior enterprise architect, five or ten years might have gone by since they last wrote software code on a regular basis.

Life as an EA

What do people then do as an enterprise architect? By and large, they act as a reviewer or gatekeeper of other teams’ IT projects and solutions:

Do the projects adhere to the department’s standard set of technology choices and frameworks?
Did the project team sufficiently map out how they fulfill the organization’s business capabilities?
Does the project create some kind of org-wide redundancy that could be resolved if they used a different set of technology solutions?

In between reviewing projects, enterprise architects might work to map out the existing technology solutions in their department, identify systems that could be consolidated, do market research on IT solutions and trends, model the organization and its systems using bespoke EA diagramming tools, and in some cases write IT strategy documents. In a typical department, an enterprise architecture group’s close proximity to departmental CIOs gives them a lot of influence or veto power over the work of other programs and teams.

Enterprise architecture’s focus on standardization and consistency (or “alignment”), in government tech settings, often leads to consistency with outdated ideas and solutions, because these are already widely-established in the organization. Enterprise architecture then acts as a persistent barrier to modernization efforts. If a small dev team is trying to adopt a modern tech stack, using software and tools widely-used in the private sector, it will be seen as inconsistent with EA-led efforts to standardize which technology solutions are used in the department. Once again, things are made mandatory before they are good, or, in this case, kept mandatory for years after they are no longer the best choice.

Overall, enterprise architecture reinforces a larger world of waterfall software development, heavy upfront planning, and IT project gating, all of which have largely been rejected by the technology world outside of government. These processes have stuck around long after they’re useful, in a self-reinforcing cycle, because people’s specific jobs and roles depend on the processes existing. I’d also guess that enterprise architecture – with its models and poster-sized system diagrams – also contributes to the government’s addiction to large software projects that are correspondingly more likely to fail (along with other incentives, like budget and program approvals).

In all these areas, enterprise architect work involves making the switch from “doing” to “watching” (to use Mark Schwartz’s terms) alongside other reviewing and gatekeeping roles. That lack of “doing”, combined with the insularity of the public service, leads over time to a lack of knowledge of how technology work (particularly software development) is done outside of government institutions. Because EA roles are fairly far up the CS/IT hierarchy, it’s difficult for more up-to-date (but correspondingly more junior) software developers and teams to push back on or appeal decisions made by EA gatekeepers. Enterprise architects are more likely to be informed by trade publications and conferences (from a small number of highly-recognizable vendors) than by the day-to-day realities of “hands on keyboards” software development work.

There are exceptions; some of the best government tech folks I know have found themselves in EA roles partly by accident or partly as an unavoidable stepping stone to IT leadership roles. At best, working in an EA role or on an EA committee is a chance to shape a department’s technology choices for the better. In large part, though, this involves reducing the potential damage of EA gatekeeping processes themselves, by promoting autonomy and empowered decision-making for the software development and product teams who are much closer to actual users and their needs.

A blueprint on display at the Bear Creek historic site. Not pictured: enterprise architecture diagrams.

What should we do instead?

If you’re an enterprise architect in government, you’re probably reading this with a mix of resentment and dread. (Or anger! I’m so sorry.) None of this is your fault; it’s a structural issue in how the public service has designed the CS/IT career progression framework, in how government IT projects are managed and reviewed, and in how slow we’ve collectively been to adapt to how IT and software development work is done outside of government. Not to mention, how far we’ve tilted the focus of government tech towards internal rule- and process-following and away from user needs.

The future is empowered, multidisciplinary product teams that deliver services using modern tech approaches and tools, learn from their users, and iterate and deploy frequently, the same way that product teams in leading tech companies would. Actually making that happen, in government departments, involves removing external gatekeepers and dependencies wherever possible.

Individually

At an individual level, if you’re currently an enterprise architect, there’s a few directions you could go in. One approach is to refresh your software development skills and plan to move into an individual contributor software dev role, as these begin to emerge in government. If you do that, do it with a lot of humility and openness to learning from much more junior public service developers. Another approach is to move into other specialized senior roles, like IT security or cloud infrastructure, if you have expertise in these areas. Modelling and mapping systems might also be a useful stepping stone to data science and analytics fields, if it’s of interest. (Making a change like this can be scary, and it’s made more difficult by the lack of senior-level individual contributor roles in departments. Moving back into hands-on, higher-impact work is really fulfilling, though.)

Few companies outside public sector institutions still have enterprise architecture roles, but many have a small number of technology strategy roles. There’s a lot of overlap here with EA work, identifying tech solutions and approaches that organizations might benefit from early on. Departments could continue to hire technology strategists (and to be honest, they’d benefit from this expertise in a lot of areas outside traditional IT divisions) even as enterprise architecture roles are slowly deprecated. The work remains relevant – how to help organizations make good technology choices – even if the terminology and specific methods of EA may no longer be useful.

The recent CS-to-IT classification update didn’t make any significant changes to the public service’s tech career progression framework (outside of formalizing education requirements in a counter-productive way). The classification and its collective bargaining union includes software developers along with other IT roles (IT help desk staff, database administrators, and so on). Many of these other roles are paid well compared to market rates, while software developers in government are significantly underpaid. Until there are non-management/individual contributor senior software developer roles available across the public service, and until these are offered compensation closer to market rates, this will continue to be a problem.

Institutionally

Enterprise architecture is baked into government IT processes all over. Departments have EA committees and architecture review boards that gatekeep new or redesigned technology solutions and the public launch of new projects. The government as a whole has a Government of Canada Enterprise Architecture Review Board (GC EARB), chaired by senior leadership from the Office of the CIO and Shared Services Canada. Each of these are mandated by the TBS Policy on Service and Digital.

Do these committees add value? Do they help avoid expensive IT project failures? It’s unclear. Part of the inspiration at least for the GC EARB may have been the United Kingdom’s spend control process, which between 2011 and 2016 saved the UK government an estimated £1.3 billion ($2.1 billion CAD). The spend control function exercised by GDS in the UK was “bloody and ruthless”, as a friend described it once, with years-long, multi-million £ projects from departments getting axed mid-flight because they were considered wasteful or didn’t sufficiently meet users’ needs.

Achieving those kinds of savings involves a willingness to (metaphorically) burn bridges, absorb hits, and disappoint senior colleagues that I haven’t seen in Canadian senior public servants. Certainly if GC EARB had saved millions of dollars by cancelling ill-fated IT projects, we’d have heard about it publicly by now. As is, shaky-looking IT projects were probably asked to come back with more extensive documentation; the punishment is (at best, and at worst) more paperwork.

The goals of these review processes are laudable; the federal government has a history of large IT project failures that certainly merits more scrutiny. But if enterprise architecture review boards aren’t actually stopping bad projects, then at best, they’re just adding delays and performative paperwork requirements to the good projects. At worst, they’re likely enforcing outdated standards and poor technology choices in the name of consistency.

The key theme of government IT project failures is that the projects are big. If you want an IT project to succeed, scope out something useful you can do – useful to actual users – in six months or less, and for less than a couple million dollars. (Waldo Jaquith’s tech procurement advice to the Michigan state government is a great summary.) Ship it, get feedback, and then decide what to do next. If we did this in government on a regular basis, we wouldn’t need giant architecture diagrams plotter-printed and put up on the walls, and we wouldn’t need architecture review committees either.

Archived tweet from Dare Obasanjo

It’s dead, Jim

I’m not the first to write this; I’m not even the first to title a blog post with this. (Google brings up 18 million hits.) Enterprise architecture roles – both in the CS/IT career progression framework and in departmental IT processes – aren’t going to go away anytime soon. But they’re a relic of another time, and if you’re currently in one, it’d be good to start planning for the future.

My old company now has offices and staff in 95 countries on 5 continents; the technology choices our team made and software code we wrote (and continued iterating on) made that scale-up possible. I’m not sure how many more places it has in-country servers in nowadays, or if data centre connections in sub-Saharan Africa have since become more reliable.

Years later and after spending $59 million, the financial management transformation project from the team around the corner was quietly paused.

If you found this interesting, be sure to read Marianne Bellotti’s piece, Five Koans of Software Architecture. As always, really grateful for any feedback!

A quick follow-up on digital identity

Thu, 16 Jun 2022 11:14:41 -0700

A couple of months ago I wrote a post on my hopes for the future of digital identity in Canada. As someone who has lived in three different provinces and territories, and spent several years working outside of Canada, I have some thoughts on what I’d like it to look like!

Most of the ideas I wrote were related to technical implementation details (to be fast, to be cross-department, to work with my authenticator app). The broader theme, though, was that I’d like to see the federal government play a bigger role, instead of (as has historically been the case) deferring responsibility to provinces and territories.

The post prompted a few responses, including two blog posts from Michael Karlin and Tim Bouma, respectively (two public servants that I’ve looked up to for years).

Michael’s piece looks at the long history of policy and technical work done within the federal government on digital ID. It includes a great summary of why digital ID work in Canada is so hard:

Identity information management is complicated in Canada. We have no national identity program so different orders of government have to share information about you regularly. If you were born in Canada, the authority of your identity information is the province of your birth. If you’re born outside of Canada, it’s the federal government via the information you provided during your immigration process. Provinces and territories share information between them as well; after all, many people don’t live in the province of their birth.

Michael’s look back at previous attempts (including those of his own team) is an absolute must-read. It also helps explain how digital identity will likely (eventually) serve as the foundation for future online interactions well beyond government. And what the potential harms are if it’s done poorly, and a few ways of mitigating them.

Tim’s piece helps provide an easy-to-understand introduction to what digital identity is.

You’ll notice the word ‘trusted’ is an integral part of the definition. It’s one thing for you to have a digital identity to use, but it is entirely another thing for a federal program or service to trust that it is you using that digital identity and not someone else that is trying to be you. That’s why the definition of trusted digital identity was introduced, it must be trusted by government programs and services.

In the past, digital identity was conceptualized as very narrow IT-centric means of logging into a system or service with little regard to who you were as an individual. Fast forward to today, the concept of digital identity is evolving toward a more holistic view of what is actually needed by the individual so that they can have the best experience possible, without barriers, and in a way that empowers them.

Tim provides a really great overview of the current Government of Canada digital ID landscape, as well as efforts in the works by a variety of provinces.

Politics has entered the chat

In the weeks after I wrote the earlier post, I was a bit surprised to see references to digital ID show up in political news coverage. On the political right, there are concerns that digital ID programs would be used to track people, their movements, or their finances. In the meantime, the Saskatchewan government announced that they were suspending work on a provincial digital ID.

As a non-partisan public servant, it’s often tempting to ignore the political landscape around our work entirely. Particularly for public servants working in technology modernization, our work tends to feel very politically-neutral: replacing old and fragile IT systems, trying to reduce costs, and trying to make government services easier to use are (by and large) goals that span across political divides. I often wish that political leaders across party lines would pay more attention to government technology issues. (Too often, they’re seen as unimportant, boring, or niche, despite their impact on people, businesses, and public trust.)

For once, sort of unexpectedly, that has happened. Being aware of the political dialogue around digital ID (or any public sector technology topic that makes the news) is definitely useful. It would not surprise me if – after almost two decades without much progress – the federal public service finally makes some great strides on digital ID implementation, only to have it crash upon the rocks of unanticipated political opposition. For all we know, this might be what recently happened in Saskatchewan.

On the other hand, as Michael hints at in his piece, there’s a longer-term danger that comes from governments ceding this field completely to unregulated and less accountable private sector companies, in everything from authentication to identity verification to age assurance.

What does this mean for digital ID efforts at the federal level? My advice would be the same as in the original post from April: don’t start with digital ID at all. Start with authentication. Build a robust, easy-to-use login system, something comparable to the US’s login.gov. Make sure that it doesn’t accidentally exclude people. Use modern tech, test it extensively with everyday people, and roll it out across federal departments to replace the mishmash of current login systems.

Start small, build something that’s useful, and from there, keep going at the pace of public trust.

For more on digital ID, Public Digital’s series of blog posts from the UK is excellent.

Public service heroes: Honey Dacanay

Sun, 12 Jun 2022 08:40:59 -0700

Honey Dacanay is a digital government legend in Canada – part of the founding team at the Ontario Digital Service, and an early leader of the CSPS Digital Academy. She currently works on Service Canada’s Digital & Client Data team and teaches at McMaster’s Public Policy in Digital Society program. Honey is a longtime inspiration both for her digital policy and legislation work, and for her writing and speaking on digital government. We chatted on April 25.

Sean: For introductions, tell us who you are and where you work these days!

Honey: Honey Dacanay, currently with Service Canada, here with the Government of Canada via the Interchange Program. My substantive is still with the Ontario Public Service.

You were at the Ontario Digital Service in the early days, can you tell us what that was like?

I feel like my time in the Ontario Public Service got defined by my time at the Ontario Digital Service. Meaning that, all the other places I worked at were almost, preparation for the time there, or lead-ups to, or waiting for the ODS to exist.

I was one of the founding members in the Ontario Digital Service. We started as a team of seven or eight people in that inaugural form – trying to reimagine what government would look like, and coming up with a plan to expand. Joining us shortly thereafter was the Ontario.ca product team, which was our precursor for a larger digital government mandate.

Those early days were at once exciting but also tough. There were a lot of important decisions around what work we took on, what work we had to turn away, and then also defining who we were and what digital government was going to mean – like, digitization versus modernization or large-scale transformation. Also where the Ontario Digital Service was going to sit in the organization.

And then hiring our Chief Digital Officer and making sure that it wasn’t another executive “as usual”, and that we didn’t follow the playbook of a lot of the public service reform initiatives or change management initiatives that had happened just before ODS existed. The playbook was usually, well, part one, have the big announcement; part two, have a roadshow deck, do the road show with the gold-plated pilot; and part three, run the compliance exercise. Meaning, send a spreadsheet of some kind or a tracking thing across to all departments and ask them to report on how well they’d complied. We knew that was not going to be the thing that we needed to scale up or communicate our change.

Was there something particular that was like, here’s how we’re going to be different?

I think so – the first was that the type of executive that we brought on was somebody who was very committed to setting the tone for how we were going to operate. The biggest theory of change was that – for the ODS as far back at 2016 – if we could get government to care about the user experience, about how people experience government services and policies, we will change government. And so, coming from that place of wanting to be inclusive and accessible from the get-go, and serving everybody. I think that was a big part of our logic model, and how we staffed and how our organizations grew at the time.

Around our team, how else were we different? When we started implementing digital service standards, I think we knew that the quickest way would have been just to enforce it, create some kind of rule or policy document, but we wanted to make sure we had a lot of institutional supports in place. We also took our own medicine and did the user research on our own standards.

Nice.

We really wanted to make the good path easy, so it wasn’t just about enforcement levers.

Even stepping back before your ODS days – how did you originally get started in the public service? What was the start of your public service journey?

From university, I worked at a community services organization called Findhelp Information Services, in Toronto. It was originally called “Community Information Toronto”, it was a precursor to 211. Then from there, I responded to an ad for a job called “New media coordinator” as a lot of digital jobs were called at the time. It was to manage the Government of Ontario’s digital presence for youth. This was back in 2006, when the going theory was that you needed a separate web presence for youth.

It was a very strange time; that first job challenged the way I understood government. It was for Cabinet Office communications, so the job was part of the communications team that was supporting the Premier of Ontario. It was really a bit of everything at the time. I had to do a lot of photography, videography, post photos and videos online and then analyze all the web analytics data. Alongside that, I was setting up a photography internship program with universities and colleges for Ontario’s first stock photo library – a supply of stock photography that reflected real Ontarians on all of the province’s official communications materials.

In a niche way I’m really impressed because, one of my pet peeves is the incredibly generic stock photography on most government websites, clearly from some random stock photo provider and it just does not look like real people. That’s awesome.

It was really fun, and I learned so much about Ontario and about setting up common resources for public servants.

Nowadays, you’re teaching a course at McMaster’s Masters in Public Policy program, to students who are interested in digital government. Are you seeing more of an interest in that intersection of government and technology work, from public admin or public policy students?

This was the first cohort that went through the Public Policy in a Digital Society program from McMaster. The course actually just wrapped up.

I found with this group, there’s still a much heavier interest in public policy versus public admin. However, there was this palpable recognition – that not understanding digital, and not understanding data, was not going to fly no matter where they ended up after the program. Whether they ended up in government, whether they ended up working for the private sector or elsewhere.

That’s cool to hear. That’s something that I don’t think I quite realized at the time, but in my own public policy program, the absence of technology or data knowledge and understanding – in hindsight, it’s noteworthy, when it’s something that’s an important part of any public service job.

It makes me hopeful for the future. And – I’m not going to lie – there is a bit of a therapy, there’s a bit of subversiveness that’s part of the activity of teaching.

It’s one of the things that I hope becomes templated – the privilege that I get to have a half-day a week spending teaching – can very easily be part of somebody else’s performance plan, like a variation of the Public Servant-in-Residence program, where it’s typically an opportunity that’s not well known, usually given to people who are closer to retirement, and not mid-career public servants. And also not as widely available; it’s usually the case where not a lot of people could afford to take six months or a whole year to participate. I hope that this is another variation of it that could be offered.

You’ve worked in a lot of places, a lot of different teams and programs. If you had to choose just one moment in your career that really stands out or was really inspiring, what would that be? A moment when you really felt, “this is what being a public servant is about”.

Please, can I pick two?

The first, from Ontario, is our team enshrining our standards in legislation in Ontario, because at the time that was sort of impossible, or next to impossible. It was a moonshot on our side. It was one of the ideas that we pitched that we knew we weren’t sure what was going to happen, how far we could have proposed that type of change.

That was something that I think surprised even our own team, and also changed the nature of the ODS and put it on a very different kind of footing. The legislation also signaled on the decision-making side that we weren’t going to shy away from institutional change and machinery of government reform at scale. But beyond legislation, the standards are embedded in our policy and Treasury Board decision making processes. And the ODS also stood up proactive supports: setting up the discovery and alpha service vendors of record, in-house discovery and alpha as a service labs in Kitchener and Toronto, providing foundational staff and leadership training at a time when learning budgets were frozen.

And, if there were policy barriers, helping coordinate getting a bunch of omnibus bills in place. Like: bring us your policy barriers, we would actually work with you to get these through. Usually there’s no appetite for tiny changes in legislation, and all of a sudden we had that as a mechanism to do so.

That’s the first one. The second one that comes to mind has to do with my current work at Service Canada.

You’ll recall I wrote some year-end reflections on digital government mostly in response to your post and Paul’s.

I remember that!

Not long afterwards, our team had a reorg, and now we are embarking on year one of a two-year agile governance pilot.

That is, take everything we have been preaching about when it comes to setting up teams to succeed and stand up the requisite supports and remove institutional blockers so that our digital team at Service Canada could deliver.

To receive a mandate to do this is no small thing, and I know that this requires a significant amount of work on our part to change existing defaults. This is about establishing a new status quo, after all, and it’s not the type of thing that will happen overnight.

I have begun reaching out to partners across Canada to get their support with standing up digital assessments – so that they’re done by assessors with digital delivery experience and expertise who can provide hands-on advice to help us improve products – to partners at Treasury Board to ensure that we report on learnings, not just how well we are following a process, and to external partners who might want to objectively document what we’re learning about how to make digital governance work in large, complex organizations like ours. In addition, we anticipate having an accompanying digital talent strategy.

As with all inspirational stories, it’s with the recognition that we’re not the first and we definitely won’t be the last. There were generations of public servants before us that have tried to make government work better, and there will be others after us that will do so as well.

If there was one thing you could change about the government or the public service – and this could be, any level of government, governments in general, a specific government, whichever you’d like – if you could wave a magic wand and change one thing, what would it be?

Probably closer to my current Interchange assignment – I think a mindset that values learning versus planning is probably the thing I would love to see change most.

The current thinking still is: almost everything in our processes, our incentives, our traditions all value sticking very rigidly and unquestioningly to a plan, and don’t account for uncertainty and how we methodically work through it. We need to be able to adapt. The last two going on three years have taught us that uncertainty is more pervasive than we’d like to think it is.

That’s a good way of putting it.

We need to create that ability, to invest in the capacity to cope with uncertainty, and to learn from it. We haven’t reckoned with lessons from the pandemic; we’ve yet to do a giant, government-wide, multi-government retro about what happened.

That’s a great point.

It’s not mine, somebody actually made that point that in one of my classes – Jessica Cole from the US Digital Response, she talks about that quite a bit.

And then again, learning with that sense of compassion. All of our analogies are still mechanistic. If we adopt the attitude that there’s still so much to learn, and there’s always every opportunity to learn – not just by taking a course but by having that as an attitude of how to go about doing the work of public service – we would be so much further ahead than we currently are.

Really awesome of you to take the time to chat. Any last closing thoughts?

Agreed with Rumon that it’s less about heroics, more about: let’s create the conditions for this to work. We still don’t collaborate enough. And oh my gosh, the inertia is real. Any way that we can join up efforts to break that, I’m all for it.

“FYN Unscripted” podcast with Sidra Mahmood and Brittaney Lewis

Fri, 10 Jun 2022 14:12:57 -0700

A few weeks ago I was part of the second English-language episode of the FYN Unscripted podcast, organized and run by the Federal Youth Network. Brittaney Lewis from DND hosted a conversation with Sidra Mahmood from ESDC and I.

The topic for the episode was “Building a reputation remotely”, and from there we dove into our early public service career experiences, finding friends across the public service and building a community, social media and blogging as a public servant, and our experiences working remotely and how this has contributed to our public service careers. And crying at work! And accidentally ending up in the news, and other adventures in the public service.

All told it was a lot of fun, and a great reminder of how having a community of fellow public servants means so much.

You can listen to the full episode here:

FYN Unscripted episodes are available on Spotify, on Apple Podcasts, on Google Podcasts, on Amazon Music, and on Pocket Casts. The French version of this episode (with Katherine LeBlanc, Jennifer Thorne, and Véronique Aumont) is also available. Marc-André LeBlanc is the producer and audio engineer who made it happen behind the scenes; outside of work he also creates the Yousque t’es rendu? podcast on Acadian life.

Team purple hair represent (with a bit of help from Affinity Photo)!

Public service heroes: Rumon Carter

Wed, 25 May 2022 07:06:23 -0230

I’m really thrilled to be kicking off this series of blog posts with Rumon Carter, a hero of mine for years since I first saw his work with the BC Dev Exchange. He replied immediately after I reached out, rejected the “hero” label entirely, and we chatted the following day on April 21.

Sean: Tell us about yourself!

Rumon: My name’s Rumon Carter, I work for BC Parks within the BC provincial public service. In those auspices, with BC Parks, I’m described as the executive lead for service transformation. My job is to lead and support initiatives to improve Parks’ service offerings, and more broadly, its operating model.

What’s it like doing digital services work on a provincial parks team?

It’s a fun juxtaposition. The work of parks agencies – the work of protecting trees and caribou, and supporting sustainable human recreation – is all very analog on first blush. And, to be perfectly frank about it, the organization itself is pretty analog as well – the incredible, impassioned folks in BC Parks are all high performing professionals, but by and large they haven’t had any exposure to the kind of, digital-era thinking, scholarship, change, and ways of working that you and I both work in and are super geeky about. Bringing these worlds together, in service of fulfilling the critical mission of parks, has been a privilege… and a challenge!

I’d pitched this series as “Public sector heroes” which is my own shorthand for public servants that I really look up to, yourself included. It’s a lot of people who champion open source, or build really cool digital services, in this niche of my own little world. I think it’s something you do really well, but you’re not a fan of the “hero” label.

Well… if I understand now that this is about your personal heroes, rather than the notion of “public sector heroes” generally, then maybe I can’t reject the label so strongly, though I’d do so with an awkward smile and rosy embarrassment on my cheeks. I don’t know how easily I could take that on, to be a personal hero of yours.

No pressure!

Generally, though, and the reason I initially balked at the label, is that I think that the culture of heroes, and the lionizing of heroism, are anti-patterns. And I really think that that’s especially the case in public service, which I think more than most any other profession needs to be grounded in humility and a deep belief and mindset and professional operating model where we don’t see ourselves as heroes. That we see ourselves to truly be people who are in service of public priorities and in service of our peers who support the delivery of those priorities.

Even more specific to our digital domain, I recall a couple years ago, the last time I was at a FWD50 conference in person, I was part of the regional government convening. I was invited to sit on a panel about bureaucracy hacking, and the topic of “cool kids” came up – the suggestion that the “digerati”, those of us at conferences like FWD50, are the cool kids, and I just had to throw a hard stop on that.

To explain, I think we should absolutely take pride in the work that we seek to do, because it really is hard mission-centred work, work deserving of grounded self-satisfaction. There may be truth in the observation that change-driving public servants show up differently, and it’s definitely easy and understandable for us to take an underdog position in this work, to self-identify as disruptors. But if we extend this self-identification to thinking that our difference, our disruption, our innovations make us “cool,” if we show up like that amid our thousands of peers who aren’t in this work – yet – with all its privileges and its challenges, it sets us up for dismissal. It sets us up for not bringing more people into this work, into this change and this effort, and I think we’d all agree that this work needs more people, not people being put off, excluded or left to feel “uncool” because they haven’t yet adopted our mindsets or ways of working.

Again, I get it, this work is so hard, and so it makes sense that we slip into ways of self-referencing that buoy us up from being pushed down, but we need to be more inclusive, we need to be more open, and in every way in which we show up, including our language, we need to militate against notions of heroism or coolness, and militate in favour of mindsets and practices of inclusivity, humility, and meeting people where they are.

So if you force me to accept that I’m a personal hero of yours, I’ll embarrassedly take it on, but I will absolutely reject the notion that any of us in this work are heroes.

Talking about humility and meeting people where they are, is it sometimes hard to balance that versus compromising on the things that you want to do differently, to role model new ways of doing it?

Absolutely. I grapple with that every day, including today. It’s easy from an evidence-informed perspective to be able to argue and advocate for different ways of working being, you know, more optimal ways of working.

And so any diminutions in the pace with which those ways of working are adopted and taken on? It’s hard! And again it’s just like, this is my work, my practice is: every day is regrounding myself in that this is the work. Like David Foster Wallace: this is our water, this is what we’ve chosen to do, to be in, to swim in. It’s going to take time and repeatedly showing up and doing everything we can to do rather than to say. And to model rather than push people into this work. It’s hard.

Bringing people more into this work – do you find that there are more people joining the public service these days? Are there things that we could do to make it a more appealing career path for people?

I want to speak from a place of evidence; I want to see the numbers, and I don’t have those. So what I’m about to observe is anecdotal, and it cuts in two directions. I am both seeing a lot of new professionals or, I was seeing a lot of new professionals, who are – on the research – disproportionately drawn to mission versus money, coming into the public service.

This is where we in government have a differentiation proposition – as I heard again the other day in an interview with Matt Cutts the other day – we have mission. We have meaning. We have – subject to all the challenges of getting this work done – we have impact on our side. That’s amazing. People get a taste of that, new professionals especially, and they’re into it.

And so, especially when I was at the Exchange Lab, I was seeing a bunch of new professionals coming into government. People were super excited about what we were doing and how we were working. Similarly, here in BC Parks, it’s super easy for us to recruit when we have vacancies – the mission here is one that is highly resonant.

And yet, the world is changing so fast. The labour market in the past couple years, our economics, the cost of inflation, the matter of whether public service organizations will support distributed ways of working… these days, even with mission in our favour, if we give potential public service employees more reasons not to work with us, it’s going to get continually harder.

So, yes, I’m seeing people leaving right now; I’m seeing great people leaving. And I’m hearing evidence, especially in this digital space – developers and other folks in related roles – that we’re having a hard time recruiting and retaining. They’re leaving or choosing to take on roles out of school that offer them two or three times what the public sector can pay. And when you reach the point – as we’re reaching in many areas – that simply meeting your basic needs, to say nothing of owning a home and raising a family, requires more money than a government job can pay… let’s just say you can’t eat mission.

All to say that I think the public sector is at a point of inflection, one in which it needs to consider not simply its wage, retention and succession strategies, to ensure that its hiring and workplace policies aren’t doing anything to turn people away, but also how it can open the tent to a greater diversity of contributors to public impact missions, no matter where you get your pay cheque.

How about your own public service career journey? How did you get started?

I’m a kid who grew up with a forest in his backyard; psychologically, emotionally, and health-wise it gave me so many gifts. That led me into a wildlife biology career and research. I worked a while in research, but felt that I was working on symptoms, rather than systems. I wanted to work at a systems level.

That’s what led me to law school. I had no idea what I was going to do with it, but I wanted to learn more about social ordering and decision-making and governance. I didn’t ever think I’d practice. And then I got really into – I geeked out – on law school, specifically public law, and more specifically the Charter and most specifically constitutional litigation, as a mechanism for change.

I learned how that lever of bringing forward public interest actions, plaintiff-based actions for change, is highly effective in moving the needle towards what we might define as progress. I tried to get a job with the province’s leading public interest litigator; he only ever hired one person, typically the gold-medallist in the class, which wasn’t me. And so my next option was to pursue learning within the “heart of darkness”, government itself.

So I came to government to learn how government worked – to better inform myself, and then to leave and pursue public interest litigation, to sue government for change.

Wow, no way!

And then early days in my legal career in government, by dint of a couple of things, I got recruited into our Premier’s Office. I got asked if I wanted to work on a file that was called “Government 2.0”, giving you the air quotes.

I said yes, then I looked up what Government 2.0 was, which led me to look up what “Web 2.0” was. Which gives you a sense of how much I knew, i.e. nothing, about what I was getting into. I’m a total accidental technologist, accidental now-digital guy, but that’s how I got my start right in government, and on what we now call this digital transformation trajectory.

It’s interesting the number of people you meet in the government tech space that have a law background. (For example Aaron Snow, the original CEO at CDS, also did law school back in the day.) Having that understanding of the systems and structures that are built around society seems really useful for a lot of things.

We could get geekier and get all fractal and talk about systems… it’s all systems and they’re all interconnected. That goes from the individual systems of our brains and mindset and how we show up, to our interpersonal systems of two and teams and communities, and et cetera. And nowadays, these human and social systems are interwoven implicitly with technical systems.

All the way back to my biology schooling and reading Michael Crichton’s Jurassic Park or Dave Snowden’s Cynefin Framework in my formative years, those were the gateways to a deep interest in complexity and complex adaptive systems. That’s the thing that I’ve been circling around this whole career.

For dark levity, consider this quote from Crichton’s Ian Malcolm character, written 32 years ago: “In the information society, nobody thinks. We expected to banish paper, but we actually banished thought.”

If you had to choose a particular moment in your public service career that really stood out, really inspiring or memorable, what would that be?

The experiences that jump to mind, plural, are all about people. I guess I’m speaking to the converted given the subheading of your blog, but all the best times have mostly been about people.

It’s when I’ve seen teams, like true Teams – capital T – come together around a mission and get lit up – with digging into that mission, with working together, truly collaboratively and cross-functionally. It’s those times. But while working within a single team has typically been my jam, as an introvert, what I’m growing increasingly interested in and focused on is how we move beyond those individual units of delivery to coordinated networks of broader impact.

So a concrete and recent example, and a bit of context: As is the case for many government agencies, for reasons that are well-documented, when I arrived at BC Parks I found it had a pretty segregated disposition. Uniformly great people, some stellar examples of teamwork, but challenges operating, consistently, as a team-of-teams.

Over this past winter, our political leaders presented us with a hard problem, one at the continuingly challenging interface for parks agencies of recreation and conservation. The problem space had responsibilities spread within at least three or four different domains within Parks, spread across multiple geographic locations. There was no way we were going to move with the kind of pace and intent that we needed in order to deliver if we worked in the typical, serial fashion, with multiple hand-offs, approval layers and all the rest.

Skipping the details, we adopted a number of methods and practices of progressive operating models to clarify goals and responsibilities, to speed communications and to run product, policy development and governance in parallel. It was hard off the bat to shift the ways of working and lean into an approach of shared consciousness (to steal from Stanley McChrystal), but this came to be one of the times that I’ve really seen a true team-of-teams come together, and orient around that shared mission, and make space for everyone to show up with their gifts. And the team crushed it. And, I dare say, had fun in the process.

They went so fast, so effectively – all their work was informed by user-centred research, it was evidence-informed, and it was built on tech that applied platform approaches and reused pre-existing common components. In doing so, they delivered a solution in five weeks, and that wasn’t just the tech. That was policy and everything. It was awesome.

And it feels good. You hear that from people, like, “wow, that was great! I loved working in that way.” It was so effective. We all feel positive when we’re, like, chopping wood and carrying water, as opposed to sitting in meetings. That crew moved the needle. When you can do that, in a truly shared and connected fashion, that makes work a joy. Hearing that joy, seeing those results, that was a massive highlight for me.

There’s that feeling when you can feel that energy, when people are like, “this might just work!” That’s huge.

Yeah… it makes me think of an analogy. Knowing where you live, Sean, do you paddle canoes? You have to have the right canoe for this, a really lightweight boat to pull it off, but if you really hammer in a canoe, it actually starts to plane, on top of the water. It’s no longer going through the water, it’s sitting on top. It feels so good, the paddling actually becomes easier after that initial hard effort, and you’re rocking along the water… that’s what jumps to mind for me when we talk about these ways of working.

When you can do that with people, and with teams, and with work? So good.

One last question, it’s something we always ask at our CDS “Ask me anything” sessions. If you could wave a magic wand and change one thing about government or about the public service, what would that be?

I’ll welcome you to push me on this one, because my immediate answer might seem like a hedge. It’s not. It is truly something that I wish I had the power to change, and I do my best every time I speak to people.

It’s less about government; it’s about the perception of public servants. I’d change that.

Maybe it’s earned, in certain quarters, and maybe I’ve been disproportionately privileged in my experience at work in government, but throughout my public service career I’ve worked with such amazing human beings. They are the best kind. And they do incredible work. In the face of – and within a system – which is designed, as you know, and we’ve talked within our community about, as Honey says: bureaucracy is a system feature, not a bug. Talk to Max Weber. We’re going for stability here, right?

And so in that context, people show up with their gifts, their mission focus, their abilities, and they do incredible work, objectively. But people can’t see that; folks can’t see that context. And so public servants get denigrated, we see Edelmann Barometer readings on the public service going down, and honestly, it breaks my heart.

Because – it ties back to the conversation earlier about hiring, even; it becomes a thing that works against our hiring, that sense of what it’s like in here. And it’s true, in government, it is hard.

But if people feel like if they’re going to a dinner party, and the response to answering the question “where do you work” is “government”, and people are like “ughh, womp womp”. Like, “I know you, you show up at 8:31 and leave at 4:29…”

I’d change that perception, so that – again – we could have more of that humility-grounded pride within our organizations. Because, I don’t know what you’re feeling, or seeing, but I see a lot of tired folks. I see a lot of folks who are proud of themselves and their work, but they feel like they’re pushing a rock up a hill, and when they hear that sense of blame, or being called out in the media and whatnot, it’s a disincentive to stick around. And I think we need our best people here.

Long-winded, maybe feels like a hedge, but, I’d change that.

I like it. Any last closing thoughts or closing words?

You can keep this in or not, depending on how much you yourself want to align with the notion of being a hero. I think we need more of you, and by that I mean we need more people who understand the fact, and are supporting it, that the nature of the work is changing.

I know you strike a balance with your disclaimers and otherwise on your blog, but I guess it goes back to my last point – I think we need to share a greater understanding of what the work is, and how to make that work better, and more effective. So I think we need more folks like you who are openly and humbly and capably grappling with these issues, speaking about them, seeking to address them, and making all of that okay. And allowing this community to find each other so that we can do our best possible work, individually and collectively.

Interested in more of Rumon’s work? Check out the in-development beta version of BC Parks’ content platform, which, in his words, “actually expresses the hours of user experience research feedback we’ve received, in terms of supporting a more coherent user journey, applying the design guides we’ve established to support and speed our development efforts, versus the rabbit warren of accreted information still found at bcparks.ca.”

A small series: Public service heroes

Sun, 22 May 2022 20:44:55 -0230

It’s been more than two years now since I started blogging here. Part of the motivation for writing was to fill a bit of a void, trying to make up for the spontaneous conversations with fellow public servants and techies that were a highlight of everyday life in Ottawa. Over time it’s become a neat way to spark or contribute to public conversations about government IT and how to improve the public service.

Writing about government IT, it’s easy to get a bit submerged in negativity; there’s so much that’s broken. On the other hand, something I’ve tried to avoid since the start is the sort of uncritical cheerleading (“everything is great!”) that’s often the safest way to operate as a publicly-visible public servant. Navigating that balance is a constant challenge, and I often worry that I might be role-modelling a level of public critical-ness that isn’t safely replicable by public servants in other teams, environments, and organizations.

I feel very lucky to have the latitude and autonomy that I have, to write critical (hopefully useful) commentary while employed as a public servant. I really want the public service to be excellent, and that’s the underlying motivation behind all of this. Having a team (at my day job in the federal government) that’s also cheerfully counter-cultural also helps.

Shining a light on inspiring public servants

One thing that’s stood out – throughout my public service career so far – is that although our processes and systems and institutions are full of systemic issues and barriers to change, the people within public service organizations are brilliant and inspiring. I’m really lucky to have met public servants that are lifelong inspirations, from the very start of my career to today. Over the months ahead, I’ll be sharing small interviews with public servants that I really look up to. I’ve had the first of these conversations in the past couple of weeks, and I’m really excited to share them with you. Nilay Patel’s Decoder interviews in The Verge were a big inspiration.

I’m calling this series “Public service heroes”, because I think we should celebrate the awesome and often unsung work that public servants do. To be clear: there are so many public service heroes – the pandemic has shown that in countless ways. The medical professionals, teachers, utility workers, emergency planners, front-line service centre staff and so many more who kept our society running over the past couple years deserve the public service hero label a hundred times over.

The people I’m interviewing are specifically my own public service heroes. (I feel astonishingly lucky to have a chance to chat with them!) They’re heroes from the particular and sometimes peculiar niche that I work in: champions of open source and open data in government, people who have built and led outstanding teams, people who have made brilliant products, shared inspiring stories, and challenged the status quo of their organizations.

And it’s also worth saying: the people I’m interviewing are a non-exclusive set of my heroes! I have many public service heroes (people that inspire me tremendously) that I’m not interviewing: people that I work directly with (otherwise I’d be interviewing my entire organization!), people that aren’t able to be interviewed because of constraints on their end, people who have left government for the private sector or politics (to avoid accidentally cheerleading for specific companies, and to stay politically neutral as a public servant), and so on. If you’re awesome (you are!) and I haven’t interviewed you, please know that you’re still awesome.

There are also a ton of inspiring people who make an enormous, positive difference on the public sector from the outside: from the academic world, from change-oriented private sector companies, from civic tech and open data communities, and from non-profit and activist and political organizations. Those are all interviews I’d love to see, knowing that as a public servant they’re not all ones I could do myself.

All that said! I hope you enjoy reading the interviews coming up as much as I enjoyed having them. A massive thank you to everyone who has been able to be part of this (and likewise thank you even to those who couldn’t). All the brilliant ideas are theirs; all the questionable ones are mine. Check back later this week for the first interview!

Everything is broken and no one seems to mind

Tue, 17 May 2022 21:40:15 -0230

Last week, Kathryn May published an article in Policy Options titled “Speaking truth to power discouraged in public service”. The article recaps a recent report from the Institute on Governance that surveyed senior public servants and examined their views on trust in government in the context of current social issues.

The report includes insights from public service executives in all three levels of government in Canada (municipal, provincial/territorial, and federal) on a range of topics. The key takeaways in Kathryn May’s article – which stood out to me likewise – relate to the relationship between public servants and political leaders.

An impartial public service is a cornerstone of Canada’s democracy. Bureaucrats are supposed to speak truth to power. The ethos of “fearless advice and loyal implementation” is its motto, and public servants take an oath to uphold it when hired. [Note: as a friend pointed out, the actual oath doesn’t mention fearless advice; its focus is loyal implementation and respecting information confidentiality]

“The participants felt rational thought and evidence-based decision-making are being circumvented by politicization, polarization and disinformation,” said [Stephen] Van Dine.

“Do public servants have access to enough truth to give fearless advice? If all their information is coming from above rather than from networks in and outside government, how much truth is there really? What happened to the role of public education in the policy development process?”

Public servants’ limited ability to communicate bad news upwards is a known problem. A public service culture – particularly in the federal government – that prioritizes compliance over critical thinking is also a widespread issue. All of these are problems within the public service, however, rather than outcomes that emerge entirely from the relationship between senior public service executives and politicians. Public servants are frequently unable to provide fearless advice to the more senior public servants above them, let alone to political leaders and ministers several steps further removed.

As Daniel Blouin points out,

Thought-provoking and interesting article that nonetheless, I believe, misdiagnoses the problem. Remove the political level from the equation and I would argue the same issues are present in PSC-to-PSC conversations as well. Public service survey results reflect this. https://t.co/pyb5G39Xt7
— Daniel Blouin (@danielblouin) May 11, 2022

I would suggest the issue is systemic; partly cultural, but mostly the result of a development and promotional system that is functioning precisely as it was designed, i.e., not in a manner that selects for people capable of providing fearless advice or displaying moral courage.
— Daniel Blouin (@danielblouin) May 11, 2022

The status quo wins again

As an example of what this can look like in practice – last week the CBC published an article on the watered-down end of an effort to reform prescription drug regulations and pricing.

Canada was trying something new to control drug prices, and the outcome might have set an international precedent. That put the global pharmaceutical giants on high alert, experts note.

With those new tools Canada would become one of the first countries in the world to require proof that the pharmaceutical industry’s most expensive new drugs provide value for money.

The new policy would also force pharmaceutical companies to tell the truth about their prices. The final prices are decided only after closed-door negotiations — becoming closely guarded corporate secrets. That means Canada’s drug price agency doesn’t know the actual prices it is mandated to evaluate.

Ultimately, five years later, very little of this panned out:

The pharmaceutical lobby hit back with a constitutional challenge, two federal court challenges and a series of threats, including trade disputes, job losses and a warning that they would delay the launch of new drugs in Canada.

The federal government delayed the regulations ⁠four more times over the next two years, putting Canada at odds with the international pharmaceutical industry at an awkward time — in the middle of a pandemic, competing with the world for vaccines.

The lone surviving policy — the list of 11 comparator countries — is scheduled to come into force on July 1, five years, four delays, and three court challenges later. The estimated drug price savings have been reduced to around $3 billion over 10 years, a third of the original estimates.

There are clearly a lot of factors that led to this outcome: court challenges, stakeholder lobbying, a change in ministerial leadership, dependencies on major pharmaceutical companies to respond urgently to the pandemic. Whether the public servants (senior-level and not) working on the file were pushing for or against the proposed changes isn’t clear from the outside.

But it’s illustrative of a trend that I would guess happens more frequently than it makes the news: an ambitious plan for change, clearly beneficial to Canadians, championed by political leaders… and then, years later, a disappointing and milquetoast outcome. There’s a number of examples I can think of (not limited to the federal government) where a minister championed a new way of doing something, and an unenthusiastic public service hierarchy simply waited them out rather than change.

It reminds me of one of Paul Wells’ rules of Canadian politics (written in 2003!),

Rule 1: For any given situation, Canadian politics will tend toward the least exciting possible outcome.

The same appears to be true for public service work, likewise. Curious how an internal proposal or transformation plan will turn out? Assume it will end up as unexciting and status quo-oriented as possible, and you’re likely to be right.

Formative leadership experiences

We live in a time where having an effective and responsive public service is more important than ever. From climate change to international conflict to supply-chain economic issues to a pandemic that is still very, very much not over, governments’ abilities to do things are critically important. As Brian Kelcey, Paul Wells, Alanna Shaikh, Ezra Klein, and others have written about recently, “state capacity” (or the lack of it) is something keeping policy wonks up at night.

This is particularly an issue for the federal government, as Rishi Maharaj points out:

The biggest difference between provincial and federal governments is that for all their warts, provinces have internalized that some things they do (hospitals, policing, etc.) are truly essential and have to work all of the time. Ottawa is incapable of urgency.
— Rishi Maharaj (@9x19) April 23, 2022

The emergency department of a hospital and the refugee department of an immigration ministry both deal with life and death situations. But only one of them has internalized that.
— Rishi Maharaj (@9x19) April 23, 2022

Being able to do things that respond to unprecedented global and social issues depends on having a public service that is able to think creatively and critically. To propose outside-of-the-box ideas, to take risks, to disagree with established processes, to make the case for faster and more nimble (delegated) decision-making. All of that, in turn, depends on public servants being able to “speak truth to power” to more senior public servants. This isn’t specific to government technology work (although its absence is especially noticeable there). It’s an issue in any domain of public service work.

In conversations with friends across the public service, a few (very speculative) theories come up around why senior public service leaders have such a strong tendency to stick to the status quo.

One theory is that (in the federal government, and in some provincial jurisdictions), the current generation of senior public service leadership “grew up” during an era of heavily-politicized, centralized message control and limited public service autonomy. Public service leaders who would have pushed for more independence and creative thinking may have left during that time, and the “survivors” are now in senior leadership positions today.
Another theory is that many “lifers” – people who have spent their entire careers in the public service – began in specific job classifications that rewarded a strong adherence to process. (Administrative roles, for example, or analyst roles – including my own EC classification! – where being able to carefully compile budget and funding templates is often rewarded more than creative ideas.)
A third theory relates to how senior public servants’ performance is reviewed. At the highest levels, deputy ministers review and sign off on each others’ annual performance reviews. As a result, everyone is strongly disincentivized from critiquing each others’ work – no one wants to be the downer in the room, or to set themselves up for counter-critiques of their own work (with performance pay on the line!).

It’s hard to have these conversations in more detail, partly since the activities and culture of senior public servants are quite opaque further down the hierarchy. Some of them relate – in a kind of “anthropology of the public service” sense – to reactions to, and relationships with, the political leadership of the day. As a nonpartisan public servant, I’ll leave that to others to explore further.

Doing things better

What would it look like for the public service to work differently, and to encourage more creative problem-solving? Here’s a few possibilities: more autonomy, down to front-line levels of the public service; fewer approvals; simpler processes; less prescriptiveness and less compliance paperwork; more of an emphasis on implementation and actual delivery rather than plans and ideas and announceable communications. All of this takes a higher level of trust in their teams from public service leaders; it takes ownership and follow-through, rather than diffused responsibility and committees; it takes a much, much higher appetite for risk among executives than tends to typically be demonstrated. And, it takes a dedicated, persistent effort – starting from the top – to build more empowering structures, to reduce the number of organizational layers, to improve psychological safety in public service teams, to encourage dissent, and to shift power dynamics downwards, working against decades of established public service norms and inertia.

In the rare discussions that I’ve had with senior public servants (which, despite everything written above, I really appreciate!) I often try to get a sense of what the general perception is of “the state of the public service” at that level.

This came up in a recent conversation with an ADM, who replied that generally speaking, things are looking pretty decent. In their words, the public service did a great job overall in the COVID response; a lot of technology modernization happened way more quickly than it would have otherwise; there are a lot of wins and a lot of momentum. Almost bittersweetly, they pointed out that it can be hard to make the case to improve things when things are going along as well as they currently are.

From my end, it was the opposite of what I wanted to hear. If I had heard: the Clerk is gripped with these issues; limited public service capacity is what all of us are talking about at the ADM and DM levels; we really need to streamline our processes and throw out a lot of our old ways of working… That would have been a lot more encouraging, simply to know that senior public servants are as concerned about our effectiveness as a public service as I am.

It’s possible that the “things are decent” perspective is one that gets shared downwards – a complement to the tendency not to share bad news upwards – to avoid spooking working-level public servants who have been through a lot over the past two years (and in many areas are working at an overwhelming pace today as travel and the economy reopens).

But I’d hope that, at least somewhere, frank conversations are happening among senior public servants – acknowledging that how we work is broken, that there’s a lot to fix, and the severity of the issues we face in the world today make all of this urgent.

These issues aren’t unique to the federal government – William Gagnon’s departure from the Government of the Northwest Territories is an important example from another Canadian jurisdiction. And, for an in-depth look at a specific federal department, Daniel Livermore’s recent assessment of Global Affairs Canada is a must-read.

Small hopes for the future of digital ID in Canada

Thu, 21 Apr 2022 10:18:59 -0700

It’s April, so like most Canadians, I spent a lot of time logging in to the Canada Revenue Agency (CRA) and other government websites. As an experience, it was okay – the CRA’s login system is better than that of most federal government departments (and there are almost 60 separate login systems, at least!).

Last year the CRA added two-factor authentication by text message or phone call, after a series of cyberattacks, but their login system still doesn’t support authenticator apps which are a lot more robust. And if you’re using your own device, you can ask it to remember you for a maximum of eight hours which I can only guess came from a horribly outdated ITSG-33 recommendation somewhere. That’s the high bar for Government of Canada login systems, and it’s not much. The 60 or so other login systems are older, less secure, and less user-friendly.

Fortunately – and colleagues at TBS and other government departments were really happy to see this – there’s a specific commitment to improve this in the most recent mandate letter for the President of the Treasury Board:

“Working towards a common and secure approach for a trusted digital identity platform to support seamless service delivery to Canadians across the country.”

Digital identity is hard. It’s particularly hard for countries like Canada, the United States, and the United Kingdom that don’t have national citizen identity cards (which are in use in most countries around the world). Even the term “digital identity” (or digital ID) can often mean more than one thing at once:

Authentication, or sign-on (securely logging in with, for example, the same username and password you used last time)
Identity verification (confirming that you’re really the real “you”)
Authorization (providing you with access to specific services, or not, depending on who you are)

On top of that, different services and websites have different expectations in terms of the sensitivity of the information you can access online, or the activities you can do (often called “levels of assurance”). For example, ordering a national park pass online isn’t as sensitive as applying for a passport.

The experience of other countries is a helpful guide as Canada starts to prioritize digital ID work. In the United Kingdom, the Government Digital Service is working on their second attempt at a sign-on service (their first, which focused heavily on identity verification, floundered without seeing a high level of public uptake). The United States focused specifically on authentication with their open source login.gov service, which I’d consider the best role model out there. (Login.gov added an identity verification option several years after launching, which is a really smart approach.)

Much like the US’s approach with login.gov, and the UK’s new second attempt, I think we should park identity verification and leave it as a future problem to solve, once we have a modern, user-friendly authentication system up and running. And, widely adopted by federal departments. With digital ID as a mandate letter priority, here’s my own small hopes for what I’d like to see here in Canada.

1. I want to log in directly through a government system

In 2012, the Government of Canada and a third-party service provider launched an external sign-in service, following a competitive procurement. If you sign in to the CRA (or other government websites) via your bank account login, you’ve used the service.

It’s secure, it’s reasonably convenient. I don’t like it. If my bank’s website is down, or my bank account gets compromised or suspended, I don’t want that to stop me from accessing government services. Even more so, logging in through banking companies adds an uncomfortable dependency on corporate providers as the “front door” to accessing critical public services. Not to mention: there are a lot of federal government services (particularly for immigration and visa applications, but also national parks and other use-cases) that people outside of Canada need to be able to access. If a Canadian bank account is the most prominent login option for government websites, that’s a recipe for a lot of confusion. It’s also an important equity issue, given that almost a million Canadians don’t have access to bank accounts. People in vulnerable situations often face the most government bureaucracy, and we should work to remove barriers wherever we can.

For all these reasons: I want the future, default option to be a regular login directly through a government website, similar to the US’s login.gov.

I can’t help but wonder if there was any design research done when the external sign-in procurement was done. I doubt it. Today, the external sign-in service contract and the contract to run the government’s regular, internal sign-in systems are with two companies that are now both owned by Interac (the debit card processor), which makes me worry about long-term vendor lock-in.

2. I want it to be fast

This goes without saying, but the future digital ID service should be lightweight and really fast. It can take two or three minutes (or more!) to go through all the steps of logging in through the government’s current login systems, with a series of “Please wait…” screens along the way.

Think about how long it takes you to log in to your Google or Microsoft account: a few seconds at most. That’s the speed we should be aiming for, if we want people to have a good experience using the service. Logging in is just a necessary, slightly painful step along the way to what the person logging in actually wants to do; it should slow them down as little as possible. Modern, scalable cloud infrastructure makes it possible to do that even when millions of people might be logging in at once (hello, April tax season!).

Signing up for a brand-new login, the very first time, should also be fast. Working in government tech, you hear a lot of anecdotes from people who got halfway through signing up for an account (for any of the government’s many services and login systems), and after ten minutes of struggling, gave up and called the call centre instead. There’s a lot we could improve.

3. I want it to work across government services without re-signing in

The 60 or so separate logins currently used by Government of Canada departments is a clear organizational failure. It’s also an added level of frustration to users, who might have to sign into different government websites several times in the same day.

If I’ve logged into one government department using the future digital ID service, I’d like to already be logged in to any other government department and service I visit. That means moving to one centralized digital ID service (the one exception to my usual skepticism of standardization), implemented in a way that maintains a persistent login state. If you’re logged into your Gmail account, you don’t have to log in again to access Google Docs or your Google Calendar. Government services should be just as straightforward.

The CRA and ESDC briefly had a login “bridge” that let you access your account on the other department’s secure website after logging into the first; it’s not currently available but it was a useful proof of concept. In the long run, I’d like to see a centralized, government-wide equivalent of accounts.google.com (or the equivalents from other platform providers) – a home for my security and login settings, my connected apps and services, and a quick way of jumping to the various government services I regularly use.

Google and its peers also have a smart approach to “re-authentication”. You’re essentially signed in all the time, without needing a “remember me” checkbox or having a painfully short several-hour timeout, but if you go to change your account settings, or view your saved passwords, or some other more sensitive function, you’re asked to re-sign in again first as a safety measure. Unusual activity (like suddenly accessing your account from a network on the other side of the world) might trigger a similar re-authentication process.

Using that kind of approach, I want my login state to last for days (or weeks, or months!) on my personal device, not just a few hours. If it works for Gmail (and don’t forget, people buy houses via email and DocuSign), with all the fraud detection and cybersecurity protections they have, we can make it work for government websites too.

4. I want it to work with my authenticator app

Two-factor authentication via text messages (SMS) or phone calls is better than nothing, but there are a lot of reported cases of people fraudulently transferring other people’s phone numbers to new SIM cards to bypass this protection.

A more secure approach is two-factor authentication via an authenticator app (like Google Authenticator, LastPass Authenticator, or similar apps). Once set up, these can’t be compromised the same way that text message or phone call authentication can be. Security experts actually recommend turning off text message-based two-factor authentication once you have an authenticator app set up and configured.

The highest gold standard is hardware-backed two-factor authentication, using physical tokens like Yubikeys. I’d like to see the federal government’s future digital ID service support both authenticator apps and hardware tokens, as well as provide an option to turn off text message-based authentication.

That said, with any form of two-factor authentication – including the text message and phone call authentication used today – we need to think really carefully about who might be accidentally excluded, and how to make sure they can still easily access government services.

5. I want to log in to provincial services through a federal ID, not the other way around

Over the past five or ten years, there have been a few efforts to let you log in to Government of Canada websites using your provincial login accounts. The CRA and ESDC both let you log in nowadays with your British Columbia services card or Alberta digital ID. As other provinces and territories roll out digital ID systems, these might also become available.

I’d like to see the exact opposite happen: I’d like to have one Government of Canada digital ID, and I’d like to be able to use it to access provincial or territorial websites and services. Why? People move around. People move across Canada for work, for education, for families and partners’ job and life opportunities. People moving around helps keep the Canadian economy going, as job opportunities open up in one part of the country or another. Anything that governments can do to facilitate moving from one province or territory to another is valuable, if for no other reason than to reduce unemployment and boost the economy.

As my friend Nisa and I joked back in grad school: you end up with a student card from one university/province; a health card from another (still valid when you’re a post-secondary student!); a drivers’ license from the province before that; and your birth certificate, social insurance card, and other paperwork somewhere back home with your family.

Having your canonical digital ID exist at the provincial level makes all of that incredibly cumbersome. It’s more user-friendly, instead, to have it exist at the widest-possible organizational level – in Canada’s case, at the federal level. Similarly if I lived in Europe, I’d want a digital ID at the European Union level. If I moved from, say, Finland to Sweden, I wouldn’t want to have to restart from scratch with a new digital ID. (For full disclosure: I’m a federal public servant, so maybe of course I’d argue for this…!)

Making this happen depends on building a reliable, interoperable digital ID at the federal level (and having it work well!), then having provinces and territories adopt it as a login option for provincial and territorial services. That depends on a level of federal-provincial/territorial collaboration that seems to always be incredibly messy. Provinces and territories also hold the vital statistics information for most Canadians, adding another layer of organizational complexity.

Still: as someone who grew up in Saskatchewan, went to grad school in Ontario, worked overseas for a few years and now lives in the Yukon… we can always hope!

Where are we at today?

Digital ID at the federal level is in some ways a good representation of our overall challenges with technology. We have a hodgepodge of 60-some separate login systems that mostly work, most of the time, but are slow and unfriendly to users. We have a lot of documentation: the 43-page User authentication guidance for information technology systems, published in 2018; the 30-page Guideline on Defining Authentication Requirements, published in 2012; the 45-page Guideline on Identity Assurance, published in 2016; and the 4-page Directive on Identity Management (and accompanying 4-page Standard on Identity and Credential Assurance) updated in 2019.

Beyond all of these, there’s the Pan-Canadian Trust Framework (PCTF), shepherded by a group of industry and government stakeholders and designed to promote interoperable digital ID solutions from multiple providers. The PCTF has been in the works for more than a decade; a friend in the public service worked on it thoughtfully for years. Ultimately, though, I think it’s a good reminder that careful planning will only get us so far, without the implementation capacity that the public service has historically been lacking. To which some might say: let’s leave digital ID fully to the private sector. I disagree; that’s a recipe for vendor lock-in and corporate capture, and a corresponding loss of public trust in government institutions. Bianca Wylie’s piece last October on digital ID (in the context of the Government of Ontario’s provincial consultations) is an excellent read that addresses this issue directly.

In the decade that we spent planning and writing documents, the United States built and launched login.gov; the United Kingdom built, abandoned, and built another sign-in system (the latter admittedly still a work in progress). We could learn from their experiences: start small, with just authentication (not identity verification), and use open source software libraries that are already available and battle-tested. We could adopt the open source code for login.gov, repackage it, and deploy it on cloud infrastructure very quickly compared to building something from scratch. (It’s already available in both English and French!) The more challenging part, of course, is updating each web application and IT system across departments to work with it, one at a time. That’s something where login.gov provides a great role model, too: the developer documentation on how to connect other systems to it is publicly-available and second to none.

Lastly: under our current approach, both the internal login and external sign-in systems are operated by external service providers and managed by SSC. SSC charges cost-recovery fees to departments that, from what I’ve heard anecdotally, are hard for departments to predict and plan for. Any future digital ID system, if we want departments to adopt it (which we should!) should be funded centrally and free for departments to use. Incentives matter; it has to be easier and cheaper to use the centralized future digital ID service than to run a small login system for each departmental application. And, once it’s up and running, it should be free for provinces and territories to leverage too.

That’s what I’d like to see: a modern, secure, and easy to use federal digital ID system. I don’t want to log in through my bank or insurance company. I don’t want to have to sign-in over and over again for each department, or over and over again later the same week. I do want the system to work with my authenticator app. And I want to log in to provincial services through a federal ID, not the other way around.

And no, I don’t want it to use blockchain. Come on, people. 😜

Michael Karlin’s follow-up piece – The long road of digital identity – is a must-read, as is Tim Bouma’s What is Digital Identity?. As always, I’d love to hear your thoughts and reactions!

Three suggestions for the next President of SSC

Wed, 06 Apr 2022 10:21:22 -0700

Update: Last week the prime minister announced new senior leadership at SSC. All the best to the incoming team!

In early 2022, the President of Shared Services Canada (SSC) announced that he was retiring. In what has accidentally become a tradition, below are some suggestions for the next president to take on the role.

SSC was created in 2011 and is the centralized IT infrastructure department of the Canadian federal government. A lot has been written on SSC and its creation and evolution; I won’t recap it here but it’s a fascinating public administration and tech case study. For most of its history, SSC has struggled with both morale and technical capability; that’s started to improve in part under the most recent president. A few friends and public servants that I look up to highly work at SSC; from their stories, there are a lot of really great people who work there, but they often spend a lot of time fighting uphill battles against the organization’s long-established workplace culture and processes. Nowadays about 8,000 people work at SSC, making it the largest IT-focused organization in the federal government (in comparison, about 400 people work at the Office of the CIO, and about 110 people work at the Canadian Digital Service).

The suggestions below are some quick thoughts on where SSC could go from here. If you have ideas to add, give me a shout anytime.

1. Start moving to zero trust networking and away from perimeter defence

Network infrastructure and security has been a big part of SSC’s DNA since it was created. Like other traditional corporate networks, the government’s networks are heavily focused on perimeter defence and monitoring (what my friend Mike once called the “crunchy outside / gooey inside” model of IT security).
Other governments around the world, particularly the United States, United Kingdom, and other allies, are moving away from perimeter defence and towards a “zero trust” cybersecurity model (something I’ve written about before here).
Particularly as the Canadian government adopts cloud services at scale (a key enabler that kept the public service operating throughout the pandemic, and something SSC deserves a lot of credit for), perimeter defence makes less and less sense.
- In practice, this can often mean piping internet connections from (very fast, very scalable) cloud providers back into (much, much slower) corporate networks in Ottawa before piping it back out to employees across the country connected over VPN.
- Given the extensive security controls and monitoring tools that large-scale cloud providers have built into their own infrastructure, the added (perceived) security of traditional network monitoring tools isn’t worth the heavy cost in employee speed, reliability, and productivity. This includes “secure cloud to ground” systems that likewise aren’t worth the cost and complication.
- Traditional network monitoring tools are also a great way to create a single point of failure for attackers.
The United States’ recently-announced approach is a great model to follow; I’d love to see SSC take the lead on implementing something similar in Canada.

2. Enable the rapid, secure adoption of third-party software-as-a-service tools at scale

Despite a 2018 OCIO directive encouraging public servants to use online collaboration tools, and the GC Cloud Adoption Strategy recommending software-as-a-service (SaaS) solutions as the government’s primary cloud approach, there are still a wide range of barriers to adopting, paying for, and scaling up their use.
- These online tools – like Slack, Trello, Miro, and more – helped public servants continue to work, collaborate, and communicate throughout the pandemic. Departments that enable and encourage their use are going to continue to have more effective and more motivated employees than ones that don’t.
- To SSC’s credit, its own employees have access to a wide range of online tools; this is great to see and something other departments should strive to emulate.
In collaboration with OCIO, SSC runs the government-wide employee login system (MyKey, which is somewhat ancient). This system is currently limited to on-premise networks.
SSC could play a major role in at-scale adoption of third-party SaaS tools by providing a government-wide employee login that is compatible with third-party single sign-on (SSO) connections. Enterprise-grade SaaS solutions often provide an option for external SSO logins, handing off account management to companies’ directory management systems and reducing the need to manage separate sets of users. For this to work, the government-wide SSO login needs to be available to cloud services (and to use modern, extensible protocols).
SSC could also work with the Canadian Centre for Cyber Security and Public Services and Procurement Canada to pre-emptively approve a large range of SaaS software for Protected B information. (It’s worth noting: departments can approve this themselves under the Directive on Security Management, but having a centralized list of pre-cleared SaaS tools would significantly help with uptake). To avoid concerns about favouritism for specific tools (or vendor lock-in), SSC could publish regular updates on what tools public servants across government are asking for, and prioritize security reviews accordingly.
- Doing this continuously, rather than as a one-off exercise, would be critical to ensure that the list of reviewed software is up-to-date and relevant.
- OCIO could publish complementary guidance and standards instructing that if a tool is approved for Protected B information in one department, it wouldn’t need to be reviewed separately by other departments (to avoid redundant security review efforts).
- As much security documentation as possible should be publicly disclosed, for transparency and to support SaaS adoption efforts by other governments and jurisdictions who could reuse and build off this work.

3. Incrementally make SSC services optional instead of mandatory

This would begin the most significant change in SSC’s operating model since it was created. As I’ve written about before, making enterprise services optional instead of mandatory is a way of creating essential feedback loops and organizational incentives. Other organizations do this deliberately in order to raise the quality and competitiveness of their in-house tools and solutions.
In the Canadian government (and SSC is not the only example of this), we have a habit of making enterprise systems mandatory before we make them good. That eliminates feedback loops and makes it harder to make the case for continued improvements, because users and clients can’t choose to go elsewhere or use other options.
SSC provides a huge range of important services to departments; for many of these, a single provider really is the best approach (network cabling between office buildings, for example, is a natural monopoly that a single organization is best suited to handle).
- For specialized services, however – from satellite monitoring to high-performance computing to field or offshore radio equipment to robotics – departments and teams have needs that consistently aren’t well-met through a single provider.
- Likewise for emerging technology needs, public service teams need the ability to experiment with non-standard systems and devices. Requesting these through processes that are designed for highly-standardized devices and equipment adds delays and administrative burdens. It’s easy to forget how diverse the operations and services of the entire public service are; diverse technology is an important way of enabling these activities.
SSC’s intake process for requests from departments (via business requirements documents and months- or years-long timeframes) reinforces waterfall IT project management approaches that are decades out of date.
- Switching to a catalogue model (where services are available instantly through automated processes, pre-approved without needing additional human approvals) would substantially improve SSC’s efficiency and reputation.
- For bespoke or highly-specialized services that can’t be integrated into a standard catalogue (and where departments are currently dependent on SSC), these should be a high priority to migrate staff, expertise, and responsibility back from SSC to the department that needs them.
For areas where SSC acts as a contract holder and reseller – for cloud infrastructure, for example – it should be just as fast to acquire these services through SSC than to get them directly from the original vendor.
- In practice, this means waiting less than 10 minutes from start to having an operational cloud service; anything longer isn’t worth it.
- If SSC and PSPC provide more SaaS options, these likewise need to be just as fast to spin up (and pay for) as going directly to the vendor. SSC and PSPC can still provide a valuable role here by overcoming the “missing middle” problem in SaaS procurement.
Given SSC’s size and responsibilities, making its services optional “overnight” would introduce a lot of uncertainty and confusion. SSC should create a 1-3 year roadmap with incremental timelines for making each of its service areas optional (with any remaining exceptions, like physical network cabling, clearly laid out). An update to SSC’s enabling legislation or Order-in-Council directions would help support this approach.

The technology world has changed a lot in the past 11 years. For teams that deliver software and build online services, one of the biggest shifts has been bringing together software development and system administration responsibilities into the same roles. DevOps (as this is called) is how the world’s leading tech companies build and operate services used by millions of people. This includes using automated systems (particularly infrastructure as code) and SRE techniques that help ensure that services are reliable, secure, and scalable. In the Canadian public service, genuine DevOps approaches are used by a vanishingly small number of teams, because our organizational structures don’t allow it.

As SSC moves towards making services optional instead of mandatory, it should also plan for the gradual migration of (some, but not all) SSC staff back into departments. This shouldn’t necessarily be a migration into departmental IT groups; embedding tech expertise and capabilities and responsibilities directly into program teams is where the future is going. DevOps with the “Ops” part in a separate team isn’t genuine DevOps (much like the case today, where it lives in a separate department at SSC). SSC’s sysadmins and IT professionals have a tremendous amount of expertise and institutional memory that departmental teams would benefit from.

Joining an organization and scaling it down, in part, might not be the most exciting goal for new leadership. But in SSC’s case, it’s a rare opportunity to reinvigorate the broader public service’s technology capabilities. Switching to modern zero trust networks, enabling at-scale use of software-as-a-service tools, and creating feedback loops and incentives by switching to an optional service delivery model – it’s the beginning of creating the tech-equipped overall public service that Canada needs.

Digital Accelerator Demo Day

Thu, 31 Mar 2022 10:20:31 -0700

Last week I was invited to be a panelist for the Canada School of Public Service’s Spring 2022 Digital Accelerator Demo Day, along with Manu Kabahizi, Nadine Davis, and Kathy Graham. It was a really fascinating and inspiring event!

Each of the teams that were part of the Digital Accelerator program had spent the previous 10 weeks working on a digital initiative; across the teams they represented a really interesting range of topic areas, from public facing services to data aggregation and visualization to potential career development programs. The teams all did a great job of describing the issue or problem space they were working to address, and had put together some really interesting proposals and prototypes.

You can watch a livestream of the full event here (1 hour 54 minutes):

One of the presentations that stood out the most was a project to provide dangerous goods inspectors with safer reporting tools (namely, fireproof and spark-proof “intrinsically safe” smartphones, and an online reporting interface, rather than paper notes). The project team had an inspector who normally works at industrial sites across Ontario as part of their team, and hearing his firsthand perspective was a real mic-drop moment. It was a great reminder both of the wide range of work that the federal government does, and of the value of having a multidisciplinary team putting users’ perspective at the heart of their thinking.

Another common theme throughout the presentations was better ways to handle, aggregate, and communicate data. One team had a slide titled “Data is available, but not user friendly” which sums up a lot of my own experiences with federal government data (!). Seeing these presentations was particularly exciting. Often, discussions on data in the public service tend to stay in the very theoretical “data strategy” and “data governance” worlds, divorced from more tangible, practical considerations like: Can we actually access and use the data we need? Can we link and compare it to other datasets we have? Can we improve our tooling, and can we develop automated pipelines? The Demo Day presentations that focused on data were very concrete and operational, which made them all the more inspiring.

As Taki Sarantakis, the president of CSPS, said at the beginning of the event: “digital” in 2022 is just another way of saying modern, effective, and efficient. That, as public servants, we have to get faster at the things we do – the world is not going to get any slower.

The Demo Day presentations gave me a renewed sense of hope in the public service, and in how we’re doing at getting faster at the things we do. (I had… not been feeling very optimistic lately!) The other panelists were a joy to work with, and the CSPS team did a great job of organizing the event.

Two questions stayed in my head as the event wrapped up. The first was: how do these teams get their projects to stick, when their Digital Accelerator session concludes and they return to their previous roles? It’s a huge challenge in the federal government to go from a prototype to an actively-used product. (Paul Craig’s post last week talks about some of these systemic challenges.) The second was: for the people that have been part of these Digital Accelerator teams, will they be supported in their regular roles and responsibilities to keep on doing cutting-edge work? Or will it be back to a typical status quo of slow progress, burdensome processes, and a lack of willingness to change?

It reminded me of past anecdotes about Code for America’s early Fellowship program, which would train up municipal governments staff in modern digital and data techniques. More often than not, the story goes, after staff who participated in the program became more digitally-savvy, they’d realize how slow and frustrating their day-to-day work environment was, and they’d leave their municipal government employers shortly afterwards to go work in a more modern, fast-paced workplace (usually outside the public sector). It wouldn’t be a complete surprise to see a similar experience take place on the part of some of the Digital Accelerator participants.

Fortunately, that doesn’t completely seem to be the case here; my colleague Manu (one of the Demo Day panelists) has actually worked with past Digital Accelerator participants in other departments as part of his partnership consulting work at CDS, and he spoke very highly of them. If the Digital Accelerator is beefing up the skills and confidence of public servants, and they’re able to keep practicing their newly acquired skills in their home departments, that’s really amazing to see.

The CSPS Digital Accelerator folks are looking right now at how they can improve the program in the future; if you have any thoughts or feedback you can give them a shout at accelerator-accelerateur@csps-efpc.gc.ca.

Why IT vendors?

Fri, 18 Mar 2022 11:27:51 -0400

During my Public Servant-in-Residence term at Carleton University, I’ll be working with Prof. Amanda Clarke as part of her larger research project on Trustworthy Digital Government. I’ll be studying the role and influence of information technology (IT) vendors in the public sector – the companies that provide software, technology equipment, cloud infrastructure, and professional services to governments.

Why study IT vendors?

The Government of Canada spends more than $6.8 billion dollars each year on IT – more than the per-year cost of the new Canada-wide Early Learning and Child Care Plan. A significant portion of this is spent on external IT vendors (including IT providers, management consultants, and temporary help agencies). Spending this money well is good public service stewardship.
A lack of digital expertise in the public sector means that it can be a challenge to manage these external vendors and contractors. We have a long history of public sector IT failures in Canada (across governments and jurisdictions), and understanding the relationship between vendors and how they are managed by public sector leadership could help reduce the likelihood of future failures.
As more and more public services are accessed through digital means, IT vendors often become the interface between the public and the government services we depend on. This has important implications for public trust and accountability. Once IT vendors become the doorway to public sector services, they can also be hard to dislodge or remove because of vendor lock-in dynamics.

Studying IT vendors is also an interesting way of looking at the career path of technology-focused public servants (a category I count myself in!). There are a lot of benefits that come from cross-pollination between the private and public sectors – people moving back and forth and learning from best practices and cutting-edge approaches in both sectors. But there are also potential risks related to lobbying and corporate influence from the “revolving door” effect.

I find IT vendors particularly compelling because procuring their services is an area of government I’m familiar with. During my time in the public service I’ve worked (in a policy role) on procurements for professional services providers, for strategic advice, and for cloud infrastructure and software-as-a-service tools. There are areas of government procurement that are larger, on a financial basis – defence and security materiel, or real property, for example – but information technology is the field I know best.

There’s some great writing on IT vendors (including management consultants that provide IT services) from a number of authors. Bianca Wiley in particular writes excellent pieces on the tension between public sector use of IT companies and public accountability. Smaller-scale Canadian tech firms have written about how hard it is to navigate Government of Canada procurement processes. Outside of Canada, Prof. Andrew Sturdy has written about the “management consultancy effect” (or “demand inflation”) and Prof. Mariana Mazzucato writes frequently about public sector dependency on consulting companies. Part of the challenge of examining IT vendors and their roles in a Canadian context is the wide range of activities (IT-focused and not) that can be performed by the same large-scale companies.

As an initial step in my research work, I’m looking forward to analyzing publicly available contracting data to explore this field in more detail. (Who are the major players? What do trends look like year-over-year? Did COVID change IT procurement spending patterns?) This is something that friends at Ottawa Civic Tech and I had dug into several years ago as a volunteer civic tech project. You can see our original analysis here – I’m looking forward to diving into this data with a bit more focus (and, er, academic rigour) than I could contribute as a volunteer weekend project.

IT services and software play a large and under-examined role in how governments deliver services to the public. Given the role that IT vendors frequently play in designing, delivering, and operating these services, I think there’s a lot of value in examining the sector in more detail. I’m really looking forward to it.

If you have thoughts or suggestions about things I should look at or people I should talk to, I’d love to hear them! You can reach me during my Public Servant-in-Residence term by sending me an email, or (as usual!) sending me a message on Twitter. Thanks so much!

Joining Carleton University as a Public Servant-in-Residence

Wed, 16 Mar 2022 22:36:20 -0400

This past week I officially joined Carleton University as a Public Servant-in-Residence (PSIR), working with Prof. Amanda Clarke. I’m really thrilled to be joining the School of Public Policy and Administration (SPPA), and the faculty and staff have been tremendously welcoming. You can read more about what I’ll be doing on the SPPA website:

“Research and teaching on public management requires dialogue between the public sector and universities,” says SPPA Director Jennifer Stewart. “The Public Servant-in-Residence Initiative provides space for collaboration between academics and experienced public servants, which benefits faculty and students at SPPA.”

Boots will be working with SPPA Prof. Amanda Clarke and her team of research assistants and data scientists studying Trustworthy Digital Government. This research spans digital service teams in government, public service effectiveness and modernization, open government and transparency, and accountability and public confidence in the public sector. It provides an in-depth look at Canadian public sector capacity in the digital space, the role and influence of private sector firms, and the potential outcomes and consequences for public trust and Canadian society.

“Our students and faculty will benefit immensely from Sean’s time with us as a Public Servant-in-Residence,” says Clarke. “He brings a wealth of practical experience and a sharp, critical perspective on the big opportunities and challenges facing governments in the digital age. I’m really excited to have the chance to draw on Sean’s expertise to strengthen my teaching and research, and to support his research and writing during his time with us at SPPA.”

I’ve written before about bridging the technology-policy gap – how important it is to bring digital topics into public policy and admin programs, and likewise to bring a better understanding of government and public services into technology and design programs. Prof. Clarke is at the forefront of doing this in Canada, and friends and colleagues in digital services teams who have taken her courses or studied with her in the past are a testament to this. It’s a dream come true to be able to work with her.

The team at the Canada School of Public Service who manage the Public Servant-in-Residence program are absolute heroes; I’m really thankful for their support as this came together. I’m really grateful likewise to my managers and leadership at CDS and TBS for their support, particularly John, Nisa, and Anatole. To everyone who has encouraged and cheered me on (you know who you are!) I can’t thank you enough. I hope I can live up to everyone’s hopes and expectations in the months ahead (…just kidding, but not really!). And to my wife Heather, who months ago suggested I give Prof. Clarke a shout – you’re the very best, always.

I’ll be joining Carleton’s School of Public Policy and Administration remotely from here in Whitehorse; when my PSIR term wraps up in the fall I’ll return to my previous work at CDS.

More to come in future blog posts about what I’ll be researching and working on – thanks for reading!

Public service tech tip: Get better home wi-fi routers

Thu, 10 Mar 2022 11:39:56 -0700

(More on my Public Servant-in-Residence work to come next week.)

Why yes, I am writing this as a distraction from everything happening in the world lately.

As public servants, we’ve mostly all been working from home for almost two years now. That might change to some extent in the months ahead, but I think it’s safe to say that some form of hybrid work (working at least part of the week from home) will be normal from here on in. Which is good!

That means: meetings by MS Teams and Google Meet and Skype and WebEx are going to be a regular part of our working lives. And as I’m sure you’ve seen: when your internet is working well, these can be really great; when your internet is struggling, it’s not a good time. Ditto if your colleagues’ internet isn’t working well, as their video and audio glitches and freezes up while the rest of your team is otherwise able to have a normal conversation.

As the saying goes: the best time to upgrade your home wi-fi was March 2020; the second best time is now. Read on!

What determines your internet speed?

I’m using these terms all very loosely; in practice, the internet speed that you actually experience at home is determined by two categories of things. The first category is, your actual internet speed as determined by your Internet Service Provider (ISP) and which plan you pay for. (The marketing materials talk about download and upload speeds in “Mbps”; we’ll come back to that later. Larger numbers are faster.)

The second category is, your home wi-fi router – and, relatedly, the number of people in your house using it at the same time, and what they’re using it for. This has been one of the common challenges of the pandemic shift to working from home: in a lot of households, both parents might be on separate work videoconferencing calls at the same time, plus kids on video calls with their school classes, or watching Youtube movies, or playing computer games.

The internet speed that you experience is determined by whichever of these two categories is slower. To use everyone’s favourite network metaphor: your internet is only as fast as the smallest “tube” that it goes through. (If you’re connecting through a work VPN, your work’s network bandwidth and security monitoring equipment is a third category, almost guaranteed to be the slowest overall. That’s one of several reasons why I think corporate networks should be a thing of the past.)

Growing up, once home wi-fi routers were available, they were significantly faster than the internet connection from our local ISP. That has changed: nowadays, counterintuitively, your internet connection from your ISP may very likely be faster than what your home wi-fi router can keep up with, given a house full of several people using it for video calls at the same time. (It’s worth noting: if you live outside of urban areas this may not be true; Canada still has a very large geographic disparity in internet speeds.)

What that means is: if you live in a city, the slow internet speed you experience likely isn’t your ISP being slow; it’s probably the result of your home wi-fi router not being able to keep up.

Get yourself a better router

If you notice that your internet is struggling when you’re on a video call – or if your colleagues frequently tell you that your audio or video is breaking up – it’s probably time for a new wi-fi router. That’s especially true if you’re still using that old D-Link router you bought a decade ago, or, worse yet, the built-in wi-fi router in the modem that you got from your ISP when you signed up for their internet service. (If your ISP offers to rent a wi-fi router along with your internet plan, it is definitely not worth it. Buy your own better one.)

Wi-fi technology and marketing, let’s be real, is pretty confusing. (“Does this router support MIMO? Is 802.11n better than 802.11ac? Or is it the other way around?!”) The short summary is that (of course) newer wi-fi routers are significantly faster and can support a lot more devices at the same time than older routers. That makes a big difference now that – on top of our personal and work computers – everyone in your house also has a smartphone connected to the wi-fi network, plus an Alexa or Google Home and some smart plugins, and so on.

But, and this is important, newer routers basically don’t have any longer range than older routers do. By range I mean, how far away you can be from the router and still have your computer or smartphone connect to it reliably. Wi-fi routers have a range of about 30 feet (or 10 metres) without any walls or obstructions in the way, and newer more powerful routers actually have a slightly shorter range than older ones. Practically speaking, your house or apartment with all the walls and floors and other things in the way means that your wi-fi router’s range will be shorter than this.

The solution to this – and it really only became widely available about five years ago – is a technology called “mesh networking”, where instead of one single wi-fi router (hidden behind your TV where your internet connection comes in), you have a series of small routers that talk to each other, spread out around your house. Your computers and smartphones talk to whichever small router is closest, and those routers then talk to each other until they reach the one that is plugged into the internet connection from your ISP. You can arrange these routers so that each one is close enough to their respective router friends (less than 30 feet), and they work together to quickly send information along to and from your internet connection.

Examples of mesh routers

You can find reviews of mesh routers for home use on websites like Wirecutter (obligatory Dan Hon reference). In my own experience I’ve used two different brands and both have worked well:

At home, Heather and I have Google Wi-Fi mesh router “pucks”, one connected to our Northwestel modem downstairs and the other one on the main floor near our kitchen. They are much, much faster than the non-mesh router we had originally bought when we moved into our previous apartment (and it was a fancy one, with 4 antennas!). I’ve heard mixed reviews about the Nest Wi-Fi mesh routers that are slated to replace the original Google Wi-Fi mesh routers, but the originals are still available.
Over the holidays, I set up a series of Eero Pro 6 mesh routers at Heather’s parents’ house. They’re a bit more expensive but have also worked really well; they do a good job of reaching corners of the house where the wi-fi used to be patchy or unreliable. Eero routers also have a network-wide ad-blocking feature that’s part of an annual subscription service; I’d love to see other brands of routers build in similar functionality.

Both of these mesh router brands work with companion apps that you run on your smartphone, and setting them up is quick and straightforward (much simpler than setting up a wi-fi router back in the day!). The general approach is:

Install the companion app on your smartphone.
Temporarily turn off your internet modem (the box from your ISP that has a telephone line or cable TV cable going into it), usually by just unplugging the power cable.
Disconnect and remove your existing wi-fi router, if you have one that’s separate from your internet modem.
Plug in the mesh router that will connect to the internet modem, and follow the first-time setup instructions in the companion app.
Turn your internet modem back on and wait for it to reconnect to your ISP.
Follow the instructions in the companion app to add other mesh routers throughout your house.

If your internet modem (the box from your ISP) has a built-in wi-fi router – which many of them do nowadays – you’ll probably want to go into the modem’s settings and turn the wi-fi functionality off. That way, the modem’s built-in wi-fi router and your new mesh router won’t “compete” for the same frequencies and airspace, especially when they’re sitting right next to each other. The only exception is, if you have a more complicated home setup from your ISP – like, for example, a home security system or internet-based home phone – it might be easier to just leave both wi-fi routers running next to each other so that those other systems keep working properly. Mesh router manufacturers also recommend placing the routers out in the open, rather than, say, on the floor or behind your TV or other obstructions that can partly block their signals.

When you create a new wi-fi network using the mesh routers, you should give it a different wi-fi name than your previous wi-fi network (even something as simple as putting a “2” or different number at the end of your old network name). Yes, that means you’ll have to individually connect all your computers and phones and smart home devices to the new network, one at a time. But, it helps make sure that your devices don’t get confused about the details and security settings of the new network, which could otherwise happen if you re-used the old name for your new network.

If this all seems intimidating: don’t worry. The companion apps for mesh routers make it very easy to set them up. We set up the mesh routers at my in-laws’ the evening before we flew back to the Yukon, which I generally wouldn’t recommend (!) but they ended up working perfectly. If you’re using an old wi-fi router, or the one built into the modem from your ISP, I think you’ll be genuinely astonished at how much more smoothly your home internet works after you make the switch to mesh routers.

Give me some numbers

When it comes to things like, several people in the same house using video calls at the same time, the limiting factor is actually your upload speed (how quickly you can send information up to your ISP, rather than download speeds, which are usually advertised more prominently). If your video call is “maxing out” your upload speed, it also means that other requests to download information (like visiting a webpage) can’t get through, and your house’s entire internet can grind to a halt.

You can test your internet upload and download speeds on websites like speedtest.net. To be super-precise, you’d want to run a test while no one else in your house is using the internet, and (ideally) while your computer is plugged right into your router or modem with a physical ethernet cable. That’s not really feasible nowadays when laptops aren’t built with ethernet ports, so doing the test from your wi-fi network (sitting close to the router) is close enough.

An example speed test from our home in Whitehorse, Yukon. Try it out

Here in Whitehorse, we’re on a Northwestel monthly plan with 100 Mbps download speeds and 10 Mbps upload speeds. (Yes, it’s $140 per month; no, we don’t have unlimited bandwidth. But generally we’re really happy with it.) A typical speed test – while connected through our Google mesh wi-fi pucks, which are great – will be about 70 to 90 Mbps download, and 8 or 9 Mbps upload. (Mbps stands for “megabits per second”, a measurement of network speed. Just like fuel mileage for cars, real-life network speeds are always a bit less than what’s advertised on paper.)

8 or 9 Mbps of upload speed is fast enough for Heather and I to both be on work videoconference calls at the time, without any noticeable issues. A typical Google Meet video call needs an upload speed of about 3 Mbps; an MS Teams video call needs about 2 Mbps. (These both vary a bit based on the number of participants, the quality settings for audio and video, and so on.)

What that means is that, if your upload speed averages 9 Mbps, you could have three people in your house doing a 2 or 3 Mbps video call at the same time. If you have more people simultaneously using the internet than that (particularly for video calls, where upload speeds are the limiting factor), you’ll need a faster internet plan from your ISP or one of their competitors.

But: if your internet plan already has a much higher upload speed (especially if, say, you’re on a fiber line with a 500 Mbps upload speed!), then your internet plan is fine. You probably just need better wi-fi routers.

If you make the switch, I’d love to hear what your experience is like. Sending good internet vibes!

Things I’d like to see in upcoming EC collective agreement negotiations

Sat, 05 Mar 2022 19:11:13 -0700

Update: As of May 18, 2023, a tentative agreement was reached between CAPE and TBS. It was ratified by EC members on June 17. You can read more about the agreement on the CAPE website (PDF). For an unofficial salary change calculator, you can use Lucas’s online Observable notebook.

Later this month, collective bargaining agreement negotiations are starting for the Economics and Social Science Services group (the EC classification) that I’m a member of. I’ve worked full-time in government since fall 2016 but it was only last year that I realized I should sign up for emails and updates from my union, the Canadian Association of Professional Employees (CAPE). Local #527 represent!

Being part of a union nowadays – kind of like, er, having a pension – feels like a weird and fantastic historical anachronism, but in a good way. It’s a huge privilege and I’m really grateful to the CAPE staff and volunteers who advocate on our behalf.

With collective agreement negotiations on the horizon, here are some things I’d like to see as part of the conversation. These are just my own views (not my union’s, and not my employer’s) and they’re definitely worth taking with a grain of salt.

Less pay, more time off

As other public service friends have pointed out, discussions on public sector pay can get political fast and usually end badly for everybody. We’re very lucky as public servants to have the pension and benefits that we have, on top of our salaries. Public sector salaries also span a huge range depending on your field of work and level of experience; they can be unusually generous in some areas and very uncompetitive in others (notably, senior-level software development and tech roles in the CS/IT classification that are paid far less than equivalent private sector rates).

As an EC, we’re …paid really well. (This is why I’m not on the negotiating team, you’re all welcome.) It’s easy for me to say that given that Heather and I don’t have kids or other family responsibilities at the moment, especially while other folks might be struggling with steep inflation and cost-of-living increases (not to mention a completely broken rental and housing market). What we don’t have is time, and I’d love to see a bigger focus on that (compared to what might be a typical focus on year-over-year percentage salary increases). I’d like to see:

1. More vacation days.

In the federal public service (in most classifications), you get 3 weeks of vacation a year. After eight years of service, that increases to 4 weeks. In contrast – a friend who joined our team a couple years back from France pointed out that French public servants start with 6.5 weeks of vacation days, plus bank holidays and so on. European public servants with income averaging might have 10 or 12 weeks of vacation each year.
For Canadian public servants whose families aren’t in the Ottawa/Gatineau area, it’s easy to burn through those 3 weeks of vacation just trying to visit family over the course of a year. At least 5 weeks of paid vacation each year would be a good minimum starting point; I’d happily take an equivalent pay cut to make that happen.

2. Clear (and encouraged) 3-day or 4-day workweek options.

Countries and companies around the world are beginning to introduce formal 4-day workweeks. All of the evidence coming in shows that employee productivity basically stays the same, while reducing burnout and increasing employee happiness.
Even if a broader shift to 4-day workweeks doesn’t happen, making it possible (and genuinely encouraged) to switch on an individual basis to 3-day or 4-day workweeks (taking, for example, a reduction to 60% or 80% salary) would be a major improvement. I love my work and my team, and I would still switch to a 4-day workweek (and 20% pay cut) in an instant.
My wife’s team in the Yukon government has several people working on 60% or 80% time (referred to as “0.6” or “0.8” schedules), in order to have more time to spend with their kids or family members. We should formalize and normalize that in the federal government too.

3. More flexible and longer-term leave without pay (LWOP) options.

As we all try to modernize the public service and how we work, more cross-pollination between the public, private, and not-for-profit and academic sectors is really valuable. Making the process for taking leave without pay simpler and easier to access would help a lot.
ECs are able to take leave without pay specifically for educational opportunities, in 1-year increments; we can also take up to 1 year in leave without pay for personal needs. Expanding this to two years – reusable on a recurring basis – would help increase opportunities for ECs to explore work in other sectors, and then bring that expertise back to their departments and teams.

A better experience for new public servants

Joining the federal government can be an overwhelming experience. From bizarre acronyms to complex processes to, well, dealing with Phoenix, it’s not a smooth experience. A lot of the early issues that new public servants run into are directly related to pay and benefits, and could be addressed through updates to collective agreements. Here’s what I’d like to see:

4. Automatic opt-in to both health care and dental.

For some reason, public servants are automatically opted in to dental coverage, but not health coverage. Presumably that comes from the range of health coverage levels you can opt into (Level 1 to 3), but the result is that new public servants are unable to receive health insurance coverage for potentially weeks or months – either while they wait to be able to access Phoenix and opt in, or because they aren’t sure how to apply through the paper form process. If they’re dealing with chronic health conditions, or are injured in-between, that delay could have major consequences.
Public servants should have full health care plan coverage automatically from day one (like dental coverage), at the basic “Level 1” level, and that should be baked into collective agreements as soon as possible.

5. Guaranteed access to Phoenix within 3 weeks of joining.

It usually takes 4 to 6 weeks from when you join the public service to when you can log into Phoenix for the first time. Accessing Phoenix is important for a number of reasons, not least opting into health coverage online, but also being able to see your pay stubs and being able to confirm if you’re getting paid properly! When I first joined the public service, I wasn’t able to access Phoenix for the first couple months of work. I finally logged in for the first time 6 or 7 months later, only to realize I had been paid wrong the whole time.
By the time you’re a month into your job, checking if your pay is correct is (hopefully) the last thing on your mind. Guaranteeing access to Phoenix within 3 weeks of joining, in collective agreements, would be a way of making sure that this delay is fixed as a priority.

6. Emailed pay stubs immediately from the start (and onwards!).

In the Yukon government, my wife gets an email every two weeks with a PDF of her pay stub – sent to the personal email she configured. If she ever had a pay issue (less likely, without Phoenix), she already has all the pay documentation she would need to deal with it. As a federal public servant, your only option is to download individual PDFs from one of the CWA apps one at a time. It’s clunky and time-consuming. And if you’ve left the public service, you’re not able to do that either.
We should have pay stubs emailed to us automatically, to a personal email address that we specify, from the very beginning. This would also help with identifying initial pay issues early, above. (If any public servants are concerned about the security of their own personal email inboxes, they can simply choose not to opt in.) If other employers can do it, we can figure it out too.

7. Bonus vacation days in your first year.

In your first year as a public servant, your vacation days are pro-rated down to match when you started. If you join in September, you’ll have half the vacation days you’d have had if you joined in March at the start of the fiscal year. That can be a challenge, that first year, to (for example) return home to visit family at Christmastime or be part of celebrations with family and friends with just 1.5 weeks of vacation.
Even if overall vacation amounts are increased (above), adding a bonus number of days (scaled proportionally) to public servants’ first years would be helpful.

Permanent remote work options, and access to modern tools

The pandemic showed that federal public servants, in a large majority of classifications and roles, can effectively work remotely and from home. In surveys, 85% of public servants want to continue remote and hybrid work options. Shifting to a remote and distributed workforce increases the diversity and representativeness of the public service, making it possible to hire public servants across the country and bring more diverse views and experiences into our teams and departments. It also provides more potential flexibility for work-life balance and being able to care for kids and family members. For EC staff, our work lends itself particularly well to being able to work from anywhere.

8. Permanent “work from anywhere” options, with very limited exceptions.

Departments are beginning to plan the return to offices, and their approaches vary significantly from one department to the next. Being able to work from home permanently, at employees’ individual preference, should be formalized as the default in EC collective bargaining, given the nature of our work and in order to reduce disparities between departments. Any individual exceptions (where working from the office is required) should be limited and require a detailed written justification.

9. Access to modern tools for data science, for everyone.

It wouldn’t be a blog post from me if I didn’t mention this! A lot of our work as ECs involves data analysis, budget planning, corporate reporting, and other areas where data science expertise and tooling is essential. Excel is not enough. (PowerBI and other commercial tools are not enough either.) Our collective bargaining agreement should reflect this, given that access to tools affects how productive we are as much as any other aspect of our working environment, pay, and benefits. Having access to modern data science tools – that are equivalent or better than those regularly used in the private sector – should be enshrined in our collective bargaining agreement.
A working group similar to, or part of, the National Joint Councils (which determines travel per diems, for example) should be set up to determine the specifics of what these tools are, and ensure that they are made available across every GC department within the next year. (If world-class open source data science tools like Python and R Studio – with their library of critical packages like Anaconda and Tidyverse included – aren’t on their list, they’re doing it wrong.)

From what I can tell, opposition to “work from anywhere” options comes from a few places: downtown Ottawa/Gatineau businesses worried about the loss of income, and city council members representing them; real property groups in government nervous about the sunk cost of long-term leases or building maintenance; and middle managers who aren’t sure how to manage employees remotely (or who aren’t as necessary now that remote-friendly tools make flat organizational communication easier).

There are federal public service jobs that can’t work remotely – border guards, health practitioners, national security staff, food and transport inspectors, and front-line service center staff as examples. But as ECs doing research, analysis, and writing work – we can do this from anywhere, and we have an important opportunity to enshrine this into our collective agreement and to role-model how beneficial it is to other classification groups.

FWD50 guest post: Conversations for the year ahead

Wed, 23 Feb 2022 14:30:46 -0700

Last week the FWD50 team launched their annual survey on the future of digital government. If you haven’t already filled it out, don’t miss sharing your perspective. It’s something I look forward to each year, partly since I genuinely love filling out surveys (hello, fellow public servants) and partly since the results are always fascinating. They’re a deep look at how we all see and imagine the future of the public service – both how we work, and what issues we’ll be working on. The FWD50 team uses the survey results to plan the content for this year’s conference.

Thinking ahead to this year (“how is it 2022 already”), there’s a few big topics that I think will come up a lot. Whether you look at the state of the world, at public health, at Canadian society and the economy, or just out your window (if you live in Ottawa or in a provincial capital) it’s clear that an effective and adaptive public service is really important to help respond to the issues we’re being confronted with.

From inside the public service, here’s what I think will be big this year…

Read the full post on the FWD50 website (également offert en français ici) and fill out the annual content survey to share your thoughts!

Reflections on the Ottawa protest, but mostly on Ottawa

Fri, 11 Feb 2022 10:42:23 -0700

I’m not quite sure how to start this piece. As I write this, we’re coming up on the third weekend of ongoing anti-government protests in Ottawa. These protests are different than past protests in a lot of ways: more dangerous, and more disruptive to the everyday lives of people who live near Parliament Hill. Others have written about this better than I can: Lucas’ newsletter from a couple weeks ago gives a first-hand overview; and Justin Ling, Judy Trinh, and Ian Austen have all provided excellent coverage.

Heather and I moved from Ottawa to Whitehorse in 2019; I haven’t been back in Ottawa since the pandemic began. But seeing the photos and news coverage of trucks and protestors on the streets where I lived and worked (and hearing stories from colleagues who are directly affected) has been really discouraging.

What I feel most is concern for the safety and well-being of friends and colleagues who live and work near the protest areas. But the feeling right alongside that one is sadness: sadness for the protestors, really, which is a hard feeling to explain. For protestors coming to Ottawa from other parts of the country – particularly from western Canada, where I grew up – it dawned on me that many of them had probably never been to Ottawa. And the sadness that I feel, somehow, is that the experiences I’ve had visiting Ottawa at different points throughout my life aren’t the experiences they’re having.

I grew up in Moose Jaw, and the first time I ever travelled to Ottawa was between Grade 5 and 6 for a national Heritage Fair. Flying in with the small delegation of Saskatchewan students and chaperones was the first time I had travelled on an airplane without my parents. At the end of the week I’d be presenting my “Farm machinery in our heritage” display complete with model tractors and combines borrowed from the Acklands-Grainger dealership, a balsa wood plow pulled behind two plasticine oxen, and stories from my mom and grandpa growing up on a farm.

My memories of the trip are pretty vague but I remember arriving at the luggage area of the Ottawa airport in time to watch two old ladies walk out the exit doors with my suitcase. 11-year-old me was too shy to ask them about it, and I waited to see their identical flower-patterned suitcase arrive on the luggage carousel instead (mine was a hand-me-down from my grandparents; classic). The Heritage Fair organizers set me up with a borrowed sleeping bag and somehow tracked down my original luggage by the next morning. The rest of the week was a whirlwind of kid-friendly Ottawa tourist sites (the Museum of Nature, a cabane à sucre), and then presenting our displays in the main hall of the Museum of Civilization (now Museum of History).

My second visit to Ottawa was in between Grade 9 and 10; our high school had been selected to represent Saskatchewan at a Canada Day choir festival of some kind, where – alongside other school choirs representing each province and territory – we’d perform at the National Arts Centre. Pinchas Zukerman (then the NAC Orchestra conductor) led the performance, and we practiced Canadian folk and contemporary songs – Un canadien errant, a song about Ontario that I can’t quite remember – all week leading up to it.

Getting to Ottawa with the school choir was an adventure of its own; to save money, the parents and students had collectively decided to take a Greyhound bus from Moose Jaw to Ottawa instead of flying. The forty-hour trip included a lot of northern Ontario rocks and trees, a very distressed-sounding bus transmission, and half of the choir getting food poisoning from the diner in the Thunder Bay bus depot. Which was …not a pretty sight.

But we made it to Ottawa, we explored the Byward Market and the museums and we practiced our song repertoire in churches and cathedrals; we performed at the NAC on Canada Day and we watched the fireworks and celebrations on Parliament Hill. The cheer and enthusiasm and happiness that we all felt as we got back on the busses at the end of the night – our choir and others spontaneously breaking into song together – was surreal. As my dad (one of the chaperones on the trip) said, everyone in Canada should experience Canada Day on Parliament Hill at least once.

When I finished undergrad, I moved from Saskatoon to Ottawa for grad school. There, I found kindred spirits who were just as much of politics and public service nerds as I was. Our crew at the University of Ottawa’s Graduate School of Public and International Affairs, we told ourselves, was more chill and down-to-earth than our contemporaries across town. The professors and guest lectures and academic events regularly knocked my socks off: here were real live diplomats and retired public servants and journalists coming and talking to our classes. On days when it was too snowy to bike in, my bus route to the university would go right by Parliament Hill. Even after a year of classes it was still a novelty.

I left Ottawa for work and came back a few years later; from then until 2019 it was home, and so many of Heather and I’s friends still live there. That’s why the protest news coverage has been so jarring: those are the streets I biked to school on; that’s the Byward Market corner where I’d meet up with a friend for gelato; that’s the building two buildings down from my old office.

For the protestors coming into Ottawa over the past two or three weeks – many of them coming from western Canada, where I grew up – I wonder: what was the experience like to arrive? What did they think or feel when they saw the Parliament buildings, pulling in? What kind of place did they think they arrived in?

From a distance, I could imagine it being something like arriving in enemy territory, this foreign place where “the government” lives and is out to get you. An enemy map in a video game, where you emerge – armed with your truck horn – ready to do as much damage as you can before the authorities shut you down.

But then …they never do. And if this is a video game, the NPCs aren’t NPCs: they’re real people with normal everyday lives, that just happen to live in the blocks near Wellington or Sussex. They’re collateral damage for the unhappiness you’re expressing, a nebulous target for things that have made your life unhappy – largely, provincial public health protections that were put in place by different governments in, say, Edmonton or Regina or Toronto.

And this is where my warm, fuzzy memories of Ottawa clash with the clear imperfections it has, as a city. The Ottawa Police, for example – known to have a systemic racism problem – have been conspicuously hands-off as a bunch of white supremacist (or white supremacist-adjacent) protestors arrived in town. The tepid police response has been stunningly different from the heavy-handed reaction to past, peaceful demonstrations by Indigenous and Black Lives Matter advocates.

And Ottawa itself, shaped politically by a 90s amalgamation process that disenfranchized the citizens of its urban core at the expense of its suburban and rural areas, has done little to compensate for this inadequate response, and little to support and protect beleaguered downtown residents. (Despite the continuing efforts of the city’s urban city councillors, who are brilliant – Catherine McKenney in particular, who would make a phenomenal mayor.) It could all be a lot better.

I’m frustrated; I’m worried for friends and colleagues. But mostly I’m sad, that the protestors who have camped out for the past few weeks never experienced the genuine joy that I felt each time I arrived in Ottawa, from a child to a grad student to a somehow grown-up person. The Ottawa of Canada Day celebrations and national museums, of indie shows at the Bronson Centre or orchestras at the NAC; the Ottawa of biking along the canal; the Ottawa of Jericho restaurant and Kettleman’s Bagels and Italian grocery stores; the Ottawa of Rideau Centre food court food on the way from work to a civic tech meetup.

There’s a lot that I worry about, these days, and the past few weeks of Ottawa protests have made me realize that we have even more to worry about: gaps in our society where white supremacy has grown; fear and misunderstanding of public institutions; misinformation and conspiracy theories winning out over evidence-based policies; systemic racism deeply embedded in police forces and in Canadian society at large. Addressing each of these issues are years and decades’ worth of work ahead.

In the meantime, I’ll end with this. Ottawa: it’s a real city, with real people in it, and it’s a city that I love a lot.

Is this blocked in my department: 2021 year in review

Sat, 01 Jan 2022 01:31:46 -0500

Another year has gone by, and it’s been a weird one. The pandemic is still very much happening, and most federal public servants are still working from home.

Using online collaboration tools has been a big part of making it possible to work from home. That’s a big change for Government of Canada departments, who have historically been very reluctant to allow access to these tools. Since 2019, I’ve tracked where online services are allowed or blocked at Is this blocked in my department.ca, with a set of anonymous submission forms that let people report which sites they can access in each department.

Below is the 2021 “Is this blocked in my department” year in review; you can read the 2020 year in review here.

Traffic by month

Like last year, traffic to the website varied quite a bit from month to month based on social media coverage. In 2021, “Is this blocked” had 10,600 pageviews, compared to 11,500 in 2020. Similarly, the “Should it be blocked in my department” companion site had 1,800 pageviews in 2021 compared to 2,000 pageviews in 2020.

Pageviews by month. Source data

Submissions by month

Data for each department is submitted anonymously by public servants, using one of the four suggestion forms. In 2021, people sent in 108 suggested updates, more than the 72 updates sent in in 2020.

This included 11 suggestions for new services, and 5 suggestions to add new departments and agencies.

All five of these organizations have now been added; if you sent in a request to add a new department, be sure to come back and send in an update on which services are available or blocked in that department!

Crowd-sourced data submissions by month. Source data

Submissions by department

Not counting suggestions to add a new service or to add a new organization, there were 92 suggested updates to data for specific departments.

Crowd-sourced data submissions by department. Source data

The quality of the data gets better the more submissions are sent in. Big thanks to everyone who contributed updates in 2021!

Highest- and lowest-scoring departments

As new services were added to the dataset, the highest possible score (for 100% services open by default) increased from 114 last year to 129 this year.

Transport Canada retained its 2020 title, as the highest-scoring department in 2021 as well. Congrats to everyone at TC who worked on opening up access to modern tools in the department! Parks Canada moved from third place last year to second place this year, while Veterans Affairs Canada and Global Affairs Canada moved up into the top rankings.

Several departments tied for fifth-highest place: FedDev Ontario; Innovation, Science and Economic Development Canada; Indigenous Services Canada & Crown-Indigenous Relations and Northern Affairs Canada.

Not surprisingly, security-related departments and agencies tended to have the lowest scores, with the Royal Canadian Mounted Police likewise retaining its last-place finish from last year:

Highest- and lowest-scoring departments. Source data

Most- and least-improved departments

One of my favourite categories from last year’s analysis was looking at which departments and agencies improved the most (or least) since the previous year.

The five most-improved and five least-improved departments in 2021 are shown below; the number overlaid on each row is the positive or negative score change since last year. (Specifically between the Dec. 8, 2020 update and the most recent update from Dec. 26, 2021.)

Most- and least-improved departments. Source data

Three departments had overall lower scores than last year: Correctional Service Canada; Department of Justice Canada; and the Royal Canadian Mounted Police.

Most-frequently blocked and restricted services

New this year is a look at which online tools and services are the most likely to be blocked in departments. The top twenty most-frequently blocked and restricted services are shown below.

Although the main focus of “Is this blocked” is online services accessed through a web browser, installed software programs are also critical to the work of public servants. These programs show up fairly highly in the list of most-blocked services: Skype for videoconferencing, Python and R Studio for data analysis, and the Mozilla Firefox and Google Chrome web browsers.

The online services in the most-blocked list cover a wide range of use-cases, from videoconferencing to social media to document sharing and team collaboration. Over time, I hope this list gets smaller and smaller.

Most-frequently blocked and restricted services. Source data

Services that are marked as “restricted” in the data set include cases where only specific staff in a department can access the service (for example, only comms staff being able to access social media websites, or only IT staff being able to use data analysis tools).

If there are several submissions from the same department that disagree, within a similar timespan, the “restricted” category is also used as a tie-breaker, since this situation usually indicates that access to the service is uneven across the department. “Restricted” is also used if staff need to request permission to access a service (for example by sending in an IT service ticket), rather than it being available by default.

“Blocked” – where services aren’t available within a department at all, even when staff ask for them – is weighted twice as heavily as “restricted” in the chart above, since this situation is the most likely to significantly hamper public servants’ work.

If you’re in an IT management, desktop services, or leadership role in a department, you should think seriously about making each of these services open by default. Reducing barriers to using modern tools makes public servants more capable, more effective, and more productive. Not to mention: happier, and more likely to want to work in your department!

To 2022!

I’m always thrilled to see new updates come in to Is this blocked in my department. If you’ve sent in suggestions over the past year, thanks so much for having made the site better!

As always, if you see any errors or missing entries on the site, please send in your suggestions! If you have other thoughts or feedback, you can email isthisblockedinmydepartment@gmail.com or give me a shout on Twitter.

Please stay safe and healthy – happy new year to you and yours!

Public service tech tip: If you create “vanity URLs”, expect people to spell them wrong

Fri, 24 Dec 2021 11:35:14 -0500

If you’re working in government communications, you’ve probably come across “vanity URLs” before. These are easily-written-out shortcuts to webpages that typically have longer, more complex web addresses. You’ll often see them in TV or online advertisements, spoken out on radio ads, or included on billboards, posters, and other printed communications. They’re really handy.

An example of a vanity URL for the Government of Canada’s webpage on COVID-19 vaccines. Source: YouTube

Vanity URLs are a standard part of the Government of Canada’s web communications guidelines. They’re just another name for redirects, which have been around since the early days of the web.

The name “vanity URL” seems to originate from the Adobe content management system that powers Canada.ca (although other systems and providers occasionally also use the term). It’s a bit of a weird name (“are these URLs …vain?”). I usually just call them “redirects”, going back to the start of my web developer days, but I’ll use “vanity URLs” in this post.

What’s noteworthy about vanity URLs is that – unlike links that are shared in emails or other webpages – people are frequently typing them in “by hand”, in the address bar of their web browser. That’s partly why they’re useful (and more useful the shorter and more memorable they are). But it also means that people are very likely to type them incorrectly. That’s something worth planning for.

Whenever I see a vanity URL on a Canadian government advertisement or publication, I have a few immediate reactions:

Does it still work if you type it without the hyphens?
Are there any complicated words that (if you heard it spoken out, instead of written) you might mis-hear or spell wrong?
If you only partly remember the URL later, how likely are you to get to the page you’re trying to reach?

If people type in a vanity URL that doesn’t exist, they’ll get an “Error 404” (page not found) message instead of the information you’re trying to help them reach.

The solution is to create a lot of vanity URLs, for all the different variations (and misspellings) of the main vanity URL that you plan on publicly communicating.

A few examples

Let’s try that out in practice, on some URLs related to the Canadian government’s COVID-19 -related information (as of mid-December 2021; these might change in the future).

URL	Does it work
canada.ca/covid-19	Works ✅
canada.ca/covid19	Works ✅
canada.ca/covid	Does not work ❌
canada.ca/covid-vaccines	Works ✅
canada.ca/covidvaccines	Works ✅
canada.ca/covid-vaccine	Works ✅
canada.ca/covidvaccine	Works ✅

All told, that’s a pretty good track record – hat tip to our public health communication folks!

If your team or project is using a vanity URL, you can try the same exercise: add or remove hyphens, say it out loud (and think about how people hearing it on the radio might register it), and think of different synonyms or words that people might think they saw or heard when your vanity URL briefly passed them by. (And do all this in both official languages, of course!)

I’d be curious how many people land on the “Error 404” page for canada.ca/covid, and if there are web analytics stats that are available to comms teams to help them identify where new vanity URLs could be created. Some content management systems can be set up to send automatic alerts in this case. If you’re seeing a large number (or even a small number!) of Error 404s on a particular URL, that’s a great reason to add a new vanity URL at that exact address.

When webpages get moved from one location to another, it’s also really valuable (dare I say, morally important) to add redirects so that people going to the old addresses can find the new ones. As Tim-Berners Lee (the inventor of the World Wide Web) would say: cool URLs don’t change. If you’re moving where something lives on the internet, make sure that people can immediately make their way to the new location. That’s something the Canadian government hasn’t historically been great at.

What’s the takeaway? If you create vanity URLs, don’t just create one or two; create a bunch that are all designed to account for different ways that people could mis-spell or mis-hear your main vanity URL. If someone ends up on an “Error 404” page instead of your content, they’re probably going to just give up instead of trying another variation of the address they typed in. You’ve written good stuff – help people find it every possible way they can.

A bleak outlook for public sector tech

Wed, 15 Dec 2021 20:34:17 -0500

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:

Today APEX welcomes 839 new Executives at the Recognition of Entry Into the EX Ranks Ceremony.

Aujourd'hui, l'APEX accueille 839 nouveaux cadres lors de la cérémonie de reconnaissance des nouveaux cadres de direction

Follow the conversation / Suivez-nous #LeaderEX2021
— APEX (@APEX_GC) November 17, 2021

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:

Agile transformation in theory: we stop doing the things we were doing before, and start using Agile methods

Agile transformation in practice: we keep doing the same things we were doing before, but now we call them by the names of Agile methods
— Pavel A. Samsonov (@PavelASamsonov) December 7, 2021

I’m hereby introducing a new technical term: agilewashing. It’s the practice of putting a thin layer of Agile™ paint on a corrupt and rotting waterfall system and imagining that everything’s fixed. SAFe, for example, is a form of agilewashing.
— Allen Holub. https://linkedIn.com/in/allenholub (@allenholub) December 17, 2021

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.

This Executive Order aims to save Americans time and frustration by making it easier to:

✅renew your passport (online!)
✅reduce wait times at airport security
✅apply for and claim Social Security benefits
✅simplify tax filing with new online toolshttps://t.co/0AwqYfFmhN
— Emilie Simons Archived (@EmilieSimons46) December 13, 2021

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!

The “missing middle” in software procurement

Sat, 20 Nov 2021 17:01:36 -0700

This year’s FWD50 conference was a couple weeks ago. Like previous years, it’s home to a lot of interesting conversations on technology, governments, and society; it also serves as group therapy for public servants who are trying to change their slow-moving organizations. I wrote some reflections on it last year. Both last year and this year, the conference took place online, and the FWD50 crew sets the bar very high for running virtual conferences that are genuinely interesting and fun to be a part of.

One new event this year was a game show-inspired “pitch competition”, where public servants pitched ideas for policy changes or other initiatives that could better enable digital work in government. My friend and colleague Meg Beretta (a digital government legend in her own right) organized and co-hosted it, and the other participants (from across federal and Ontario public service organizations) came up with really interesting and inspiring pitches. Just getting to meet and chat with them “backstage” was a real highlight:

Shout-out to all the other #FWD50 pitch contestants, you're the very very best! And to @gvezinamtl from the @fwd50conf team for brilliant stage managing & tech! 👏👏 @EveGreb @andrea_bacque @IFiniq @shahzmasays @sidramatik @germainaoun @sfigas01 pic.twitter.com/jfA2aD6vJ6
— Sean Boots (@sboots) November 5, 2021

My pitch was about procurement. And also about urban planning, as a shameless way of combining two of my favourite topics. Below is a recap of the presentation; as always, I’d love to hear your thoughts!

The missing middle

Photos I’ve taken over the years showing three different neighbourhood building types (from left to right: Whitehorse, Paris, and Ottawa). See my full presentation slides here

In the urban planning world, people use “missing middle” as a term to describe how neighbourhoods are designed and built. In North America, most neighbourhood housing tends to be either single-family detached homes, like you’d see in most suburbs, or – in large cities – really giant condo skyscrapers. There’s small, huge, and not much in between.

In other parts of the world – Paris, for example – a lot of neighbourhoods are 5- or 6-story housing blocks. They’re dense enough to support a vibrant community, there are little restaurants and cafes everywhere and you can easily walk around, and it makes parks and public transit all work really well. Montreal is one of the only North American cities that has a similar vibe, and people love it.

That’s the metaphor – there’s a “happy medium” for urban design, and in North America, we don’t have nearly enough of it. What does that look like for software procurement?

Why it matters

Let’s start with what we’re trying to accomplish. I’ve basically dedicated my career to helping public servants get the tools and equipment they need to be really really great at what they do. I want public servants to have software and tools just as good as people who work at Shopify or Google, no matter where they work in government. Anyone who has worked both in government and in the tech sector knows that, in most departments, there’s a giant gap. In government, we lose talented people all the time because our default tools are so bad. That’s what I want to fix.

If you want to do good work, you need good tools. In today’s day and age, where we’re all working online from home, wherever we are across the country, a lot of that involves software products that we access online.

Some of these tools are free, but a lot of them are online subscription services. Tech folks call this “software as a service” or SaaS. These are things like Slack, GitHub, Trello, Figma, or Mural that you access through a web browser and that let you collaborate in useful ways with other colleagues.

For a long time, in the federal government, you couldn’t even access these tools through the firewall; that fortunately started to change in 2018 thanks to a policy update from the GC Office of the CIO. There was another really useful change this year from the Office of the Comptroller General (the group that does procurement policy), saying that yes, you could accept the standard terms and conditions for low-cost, low-risk tools, which means: now you can even pay for them. All of this is really helpful.

The missing (procurement) middle

What’s the missing middle for procurement?

If your tool is inexpensive and your team is small, amazing, you can put the subscription cost on a departmental credit card and call it a day.

And, if your tool is really, really expensive and sold by one of the really large IT vendors, no problem, there are contracting vehicles in place from Shared Services Canada (SSC) or Public Services and Procurement Canada (PSPC) that you can get it from.

In other words: If I want to spend $20 bucks a month, good to go on a credit card. If I want to spend $5 million dollars a year? Good to go on an SSC or PSPC vehicle or supply arrangement.

What’s missing? The in-between.

For example: you’ve got a team of 150 people. There’s an online tool that everyone in the tech industry uses. It costs $30 per person per month. That means in a year, you’re going to spend about $60,000 dollars on this tool. How do you do that? You can’t.

What are the barriers?

The barriers here are specific to the federal government (in Canada), but I wouldn’t be surprised if other governments and jurisdictions have similar issues.

In federal regulations – the Government Contracts Regulations or GCRs – I can (generally) sole-source something if it’s less than $40k after taxes. This $40k limit is per program, and is usually interpreted as over all time (i.e. the lifetime of the program), which means that any subscription service will run into this limit eventually.

When you’re trying to buy software-as-a-service products, some procurement folks actually still consider them a “good”, picking up on the word “software” – because back in the day, you bought software in a box from Staples. In that case, the limit would be $25k after taxes. Even less room! And yes, “software as a service is a good” is a sentence that would only be spoken in government.

(Fortunately, as an unexpected side effect of PSPC moving from GSIN categories to the United Nations Standard Products and Services Code or UNSPSC, there’s now a clear category for “Computer software rental or leasing services” which covers software-as-a-service products… as a service.)

So: I’ve got an online tool that costs $60k per year.

I can’t sole source it, since it’s more than $40k. I could do a standalone competitive procurement, with a Request for Proposal (RFP). Here’s a few of the challenges there:

It’ll take 6 months to 2 years to happen
The company that makes the tool the team actually wants might not even bid
The winner of the RFP will be whoever writes the most convincing bid, not who makes the best tool
I have to know from the very start how many licenses I need, several years into the future, and if my team grows more than that I’m totally out of luck anyway.

Not to mention: my procurement and legal folks will say, you need to set up custom contract and liability terms with the vendor, “to protect the Crown”. And the vendor will say (this is a true story) we won’t bother negotiating custom terms for anything less than $250k USD. It’s not worth the cost of their lawyers otherwise. And my procurement people will say, sorry, in that case, you’re out of luck.

(I’ve heard recently, from more grizzled procurement experts than I, that the most realistic workaround for this is simply to spend the $250k, by buying more expensive licenses or committing to a longer time period. Which is …not exactly an improvement? Locking ourselves into spending more money because we won’t be more procedurally flexible is not a good look.)

I’m trying to spend $60k, and I still can’t.

If I wanted to spend $5 million, I’d get in touch with SSC or PSPC’s procurement folks, who would say: yep, here’s our standing offer with Microsoft, here’s our standing offer with Amazon Web Services, here’s our standing offer with (insert large company here).

Even for medium-large companies, they might say: here’s our supply arrangement for Atlassian products, or here’s our supply arrangement for Adobe products, where three or four companies you’ve never heard of are reselling the products from those companies to government customers. These are considered competitive procurements (and therefore not subject to the $40k limit) because several authorized-reseller “middlemen” competed to be on the supply arrangement. (Classic.) But if the software tool you want doesn’t have government resellers, and doesn’t have a supply arrangement, once again, you’re totally out of luck.

What do you do instead? You stop using the tool that everyone loves, and all your best people quit and go work for Shopify. Not great.

What should change?

When I pitched these to the judging panel at FWD50, one of the judges quite aptly pointed out that my description of the problem was great, but the solutions I suggested weren’t necessarily realistic. This is true! These changes, at the least, would involve a procurement regulation change, which would require a consultation period and Cabinet approval. All the more reason to get the ball rolling sooner than later, that’s what I’d say.

Here’s what I’d recommend:

Clarify that the $40k sole-source limit in the Government Contract Regulations is per year. That way it’s way clearer how subscription services fit against the thresholds, and it still nicely fits the intent behind that particular exemption (of it not being cost-effective to procure at such low dollar values).
Increase the sole-source limit for services from $40k to $100k, again, per year, to make more room for medium-sized teams to sole-source online tools. That still fits, just barely, under the whole bunch of international trade agreements so all good there.
Add an exception that, if a company only offers its product via credit card purchases, you can do a credit card purchase even above regular departmental limits. In most of these cases, 99% of a company’s customers are not governments. They’re not going to bother with contract negotiations and invoices. If we can’t buy their stuff, that’s our problem, not theirs. Governments need to get used to being small, unimportant customers, and to paying for things on a credit card like everyone else does.

Friends of mine in procurement would say: you should just compete it! Or convince the company to set up resellers and a supply arrangement. But the truth is, these companies aren’t going to. 99% of their customers are not in government. Doing a competitive procurement means, 1) spending a ton of time and effort on things that aren’t delivering high-quality services, and 2) at the end of the day ending up with a different product than the one that all my tech and design people actually want to use.

Plus, I don’t have one online tool to procure, I have seven that will run over the sole-source limit sooner than later. And in a year, the best-in-class tool for a given use-case will change, and my team will want to use the new one from a different company instead. There’s no way our existing procurement processes can keep up.

So that’s the situation:

If I want to spend $200 on a credit card, no problem.
If I want to spend $5M via an SSC or PSPC vehicle, also no problem!
If my online tool has authorized resellers and a supply arrangement, also no problem.
But if it’s above the sole-source limit and doesn’t have resellers, I am 100% stuck. It’s the elusive 5-6 story medium density neighbourhood that doesn’t exist in North America.

And to fix it, my pitch is:

Change sole-source limits to be time-based, for subscription and recurring products. So, $40k per year instead of $40k in general.
Bump the sole-source limit for services as far up as you possibly can, which given trade agreements is probably $100k/year.
Explicitly bless paying for things on credit cards and accepting the commercial terms when it’s the only option available from a given vendor, even up to that $100k/year limit.

Procurement: it’s the best (?)

Hello from year four, we’re right on time:

Gov't Digital Service progression:
year 1: "Why y'all talk about procurement so much? How boring."
year 2: "Man, procurement's a pain."
yr 3: "We should really consider doing something about procurement"
yr 4: "Holy crap there's nothing more important than solving procurement!"
— sm (@sashax) December 13, 2017

Would the changes I’m suggesting open the door to more questionable sole-source contracts (e.g. for $99k instead of the just-under-the-limit $39k contracts you frequently see nowadays)? It’s possible, although limiting it to subscription services that are already-complete deliverables (versus, $100k of “working on an IT project that we’ll finish eventually”) would certainly help. Would it enable more “shadow IT”? Yes, but that’s a feature, not a bug. Would it make public servants more productive and effective? 100%.

I don’t want my team to be the only crew in government that can use modern tools; public servants deserve them no matter where they work and no matter what they do.

Rebranding “shadow IT”

Sun, 31 Oct 2021 11:35:02 -0700

“Shadow IT” is one of those terms that you hear tossed around by government IT executives on a regular basis. It’s an anxiety-ridden phrase filled with fear and insecurities.

What is shadow IT? Generally speaking it’s any software product that isn’t managed by an institution’s official IT group. Created your own Trello board to manage your work? Shadow IT. Using Airtable or Tableau Online to run some data analyses? Shadow IT. Figured out a way to install Firefox on your ancient work computer that only runs Internet Explorer? Shadow IT.

Using the Microsoft Office suite installed by default? Congrats, not shadow IT.

The words themselves evoke spooky, threatening outsiders, foreign spies lurking in the shadows to steal the project management notes in your Trello board. There’s danger everywhere. 🕵️‍♂️

What if …it’s actually good though?

Here in my small corner of the public service, equipping people with modern tools is precisely what I’m here for. The things that government organizations’ CIOs and IT executives see as threats, I see as the future of how we all work. I’m not the only one:

Shadow IT is the future of digital service delivery because it is better aligned with the business#GCDigital
— Jayson Sizer McIntosh (@JaysonMcIntosh) July 21, 2021

Shadow IT = unmet IT users needs.
— Mark Dalgarno (@markdalgarno) February 19, 2019

Raise your hand if you’re a public servant who has paid for a low-cost software subscription with your personal credit card, with no reimbursement, just because it’s the easiest, fastest workaround. https://t.co/NlItSdFeR8
— Michelle Thong (@michellethong) September 11, 2019

To that last point – everyday public servants casually buying software on a personal credit card is the kind of thing that gives CIOs nightmares. (Centralization and standardization is often one of the success metrics that IT executives are measured by. Random software purchases across the organization don’t help with that. Fortunately, officially paying for software on a departmental credit card is now easier than it was a year ago.)

This happening, though, isn’t the actual problem. It’s a symptom or indicator of a more important problem: public servants not being equipped with the tools they need to work effectively. Microsoft Office doesn’t cut it, in 2021.

Meet the new IT

Instead of trying to squash shadow IT, whack-a-mole -style, I think we should embrace it. The departments that do this soonest are going to get all the best people.

In that spirit, let me propose a 🎉 fun 🎉 re-branding 🎉 opportunity 🎉. Here’s some alternative names for shadow IT:

Grassroots IT, because it’s led by working-level folks rather than IT executives
Empowered IT, because employees and teams can choose the tools they want to use, themselves
New IT, because it’s better than old IT
Decentralized IT, because it’s not run by the central administration
Fast IT, because you can use it right now without waiting for approvals
Adaptable IT, because you can switch to a different tool whenever a more effective one comes along

But isn’t that anarchy?

Government IT execs (and information management folks) bristle at anyone using non-centralized, non-vetted tools. Some of the main risks that they bring up is that important information will be either compromised (accessed by those omnipresent foreign spies) or lost forever (when the online tool you’re storing it in goes out of business).

Those are real risks! They’re fairly easy to manage, though, namely by storing information in more than one spot, or exporting it regularly (so that if one provider disappears, you’re fine), and by only using non-vetted tools to store unclassified/non-sensitive information.

It reminds me of fearful concerns about “cloud sprawl” from several years ago (2017, the year before the government went cloud-first). If you move a lot of things to the cloud, the concern was, what if you lose track of them somehow?

To which I’d reply: “cloud sprawl” is not a problem. (Not to mention that “losing track of things” can happen with traditional on-premise systems too!) Personal data sprawl is a genuine problem. If you don’t know where sensitive information about real citizens is being kept, that’s a major problem. Don’t fill your Trello cards with people’s social insurance numbers. But for everyday, unclassified work, go for it.

You can read some more tips on starting to use modern online tools in government here. Archiving information of future value in more permanent systems (for future historians!) is also really important. My preferred way of doing that is by making the information public wherever possible, letting Google index it and, if your information is noteworthy enough, having the Internet Archive automatically archive it. If it’s too niche or obscure, you can submit it to the Internet Archive yourself! (I do this all the time.) Future historians, we’re here for you.

Don’t settle for outdated, low-quality tools. Get yourself some grassroots, empowered, new, decentralized, fast, adaptable IT instead. 🌻🌤

How would you re-brand shadow IT? What name would you choose? I’d love to hear your thoughts!

Postscript: Turns out, a number of tech commentators have already written about re-branding shadow IT, and the benefits that these types of tools bring to large organizations. Here are a few examples!

If it’s not public, does it even matter?

Sun, 24 Oct 2021 20:45:35 -0700

Years ago, I interviewed for a policy internship with one of Canada’s intelligence agencies. Most of this involved detailed conversations with personnel security investigators, their eyebrows permanently raised as I answered questions about how vanilla my personal life is. I am a very, very boring person. I ultimately turned down the position to do an international internship through my grad program, but I wonder sometimes how differently my life and work would look if I had followed that career path instead.

Let’s just say, regularly blogging about my day job probably would not have been a feature. 😜

Michael Karlin’s Twitter thread this past week was a great reflection:

Archived tweet from Michael Karlin

In a society and world where misinformation is a large-scale problem, public service habits that default to secrecy are …not great.

Conversations with friends and counterparts from around the public service over the past year bring up tons of examples of this habit: fear of putting things in writing, fear of ATIP (access to information) requests, fear of public disclosure making people look bad… It’s all the more striking when you pair it with public commentary from academic researchers, journalists, and activists pleading to governments to provide more information and more data, imperfections and all. I’ll leave it to political scientists to ponder where that fear originates from, but it’s safe to say, it’s a very established, very unfortunate, part of Canadian public service culture.

It’s also a habit that’s hard to understand and empathize with, because my own philosophy is so different. The public service is so cool, and does such important work. Why wouldn’t you want to shout that from the rooftops? If our team gets an ATIP request, I am genuinely stoked that people are interested in our work (with apologies to my colleagues; completing ATIP requests is an incredibly clunky and manual process). Whenever there are chances to do more work in the open, our team is pumped to do so. Working in the open is one of our organizational values.

Reports to nowhere

On a flight in 2015, when I still worked for a tech startup, I happened to sit next to a senior executive from a federal government department. Over a several-hour conversation, I listened to his reflections on the public service. He described, cynically, the public service as “welfare for people with master’s degrees”, where most of the documents and artefacts that (well-paid) public servants produced were just consumed by other public servants elsewhere in government.

That quote is problematic in a number of ways, but his observation on that type of cycle was striking – how so much of the work that he observed never had any impact on the public beyond the walls of government institutions.

As someone who works nowadays in a policy role – spending my days writing documents and emails – that conversation feels prescient. The takeaway that stuck with me was that, generally speaking, public service work is only valuable based on the degree to which it interacts with the public and world at large.

Governments do a lot of different things, and many public service jobs involve directly interacting with the public as a daily activity. Service centre agents, food inspectors, teachers and educators, health and emergency workers, fisheries and wildlife officers, immigration officials and border guards… These public service jobs, in my view, actually have the highest public impact by far. For the people that they serve, they represent the government affecting their lives (hopefully for the better) in a very immediate way.

(An important caveat: especially in law enforcement, immigration, and border enforcement roles, these jobs in some circumstances can also affect people’s lives very, very negatively in an immediate way.)

For policy people (like myself!) writing documents and plans and ideas – the potential impact we have on the public at large is a lot harder to measure. Did the document you helped write change the big-picture policies that the government put into place? How much did your document help? How much of your work survived the rounds of approvals and committees on its way to decision-makers? How much did the resulting policy changes actually help everyday people? The further you get from the actual public – the more insulated you get within the public service – the less likely you are to be able to empathize with what people are going through, and the less likely you are to positively impact people’s lives.

The caveat is: it’s also possible to have a positive impact by helping other public servants do their work more effectively. Particularly the public servants who do interact more directly with the public. That’s where, at least in my day to day work, I find a lot of meaning.

Fight the good fight

Fighting secrecy culture – and working as much in the open as possible – is a really important part of that work. It’s a way of radiating intent, of finding allies, and of reaching people that you might not be able to directly communicate with as a public servant (senior executives, for example, or political leaders and civic activists). It also means that – even if your work didn’t ship, or didn’t achieve the policy or program outcome you ultimately hoped for – if it leaves a public record, then other people, other public servants, and other governments can learn from it and build on it. The more public record, the better.

It’s not an option that’s available to everyone; there are parts of government whose work should stay secret for good reason. That’s not just intelligence and security people (sorry, past internship me); if you’re working in market regulation or taxation changes, or fraud detection work, or delicate diplomatic topics, carry on, good people. Few public servants, likewise, are in a position where they can just decide to just go for it and start working in the open. There’s a lot of privilege that relates to being able to do this. I hope both that I don’t take this for granted, and that my own efforts help create more space for other public servants to be able to do likewise.

What are the takeaways?

Public service secrecy is a problem, and it’s probably contributing to a lack of public trust in governments. We should talk about it.
Any chance you have to get your work into the public sphere (publishing drafts and works-in-progress, proactively disclosing documents, inviting public scrutiny!) is worth taking.
Individually working in the open isn’t an option for every public servant, but if you have the option, it adds a whole new layer of meaning to your work that you might not have expected.
If you’re a public service leader, do everything you can to make working in the open an option for the people and teams that work for you.

Rock on, friends. 🙌

Addendum 1: Working in the open also brings up really interesting questions around parliamentary or political accountability. More transparency on day-to-day public service work can help elected representatives better hold government institutions and their ministers to account. How this plays out in practice has a lot of complexity (something for a future blog post!). Kent Aitken’s 2017 post “Public service anonymity is dead, long live public service anonymity” is an excellent read on this, along with more recent discussions in the context of provinces’ pandemic responses.

Addendum 2: if your work does successfully become part of the public record, keep it there! A couple weeks ago I was a bit shocked to see that the Auditor General of Canada (my favourite Office of Parliament, along with the OPC) removes reports from their website once they’re more than seven years old. No doubt this is based on an information management approach put in place when computer storage was expensive (nowadays, especially for text documents and web content, it is approximately free). But having to email to ask for a previously-public report, or to search for it on the Internet Archive, isn’t a great way for institutions to operate. As Tim Berners-Lee would say, that’s not cool. Be cool.

How many Government of Canada services are online from start to finish?

Tue, 12 Oct 2021 23:29:07 -0700

Update: In December 2021, I updated the methodology used in the end-to-end services analysis. Following the update, services that are all “not applicable” are no longer counted as fully online. Overall, 19% of Government of Canada services are online end-to-end, instead of 45%. This more closely matches the official methodology recently published on the GC InfoBase website.

Back in early 2020 I wrote a blog post about the quality of federal government services (something that my career is by and large dedicated to improving!). It included a litmus test for government services: can I complete this service online, on my phone, from start to finish, at two in the morning?

Getting accurate data on how many government services meet that mark is challenging. It’s challenging for any government, not just Canada! Even determining how many government services exist across a vast range of departments and agencies is a struggle. Although it was (very sadly) decommissioned this past year, the United Kingdom’s Performance platform was one of the first and best efforts at doing this. It mapped out both how many services the government offered, and how effective they were at meeting a set of consistent performance criteria. UK digital government folks have also written some great pieces on what a service is, which isn’t always a straightforward question.

In Canada, a team in the Treasury Board Secretariat’s Office of the CIO publishes the GC Service Inventory, which lists each service offered by federal departments and agencies. Although it originally only included a handful of departments, the 2019-2020 update to the dataset included services from more than 70 departments and agencies, along with a range of indicators about each service. I was very stoked to see this get published publicly on the Open Government website, and I’m a huge fan of the team that produced it.

Counting up end-to-end services

A screenshot of the “End-to-end services” analysis website. Visit the site

Over the past couple weekends, I put together a new civic tech website that analyzes the GC Service Inventory data and comes up with a tally of end-to-end services, across the government and across each department or agency.

According to the 2019-2020 data, 45% of Government of Canada services are available from end-to-end. That’s actually pretty solid, and quite a bit higher than I was expecting. This percentage varies fairly significantly from one department to the next, and it doesn’t factor in the volume of service transactions (for example, a service used by hundreds of thousands of people each year is weighted the same as a service only used by a dozen).

Services in the GC Service Inventory data set are also self-reported by departments, each of whom may have interpreted the online interactions criteria (there are six) slightly differently. Hopefully this data set continues to improve and grow each year, as departments add any missing services.

Unlike some previous projects (mainly, Is this blocked in my department?) I don’t have any solid ideas on how to gather feedback about any missing or inaccurate service entries. One approach would be a parallel, community-contributed data set (I’ve added a very basic Google Form option to suggest corrections to existing entries, but adding new services would be more complicated) and ideally there would be a clear mechanism to report issues to each department directly. If you have thoughts or suggestions I’d love to hear them!

You can take a look at the methodology for more on how the site works, or the GitHub repository for technical details. Check out the website, see how your department stacks up, and let me know what you think!

“If your technology leadership is more into blockchain than user needs, you’re doomed.”

Mon, 04 Oct 2021 21:29:59 -0700

Matthew Cain in the UK published a great blog post recently titled “Leadership in a digital age”. It included an observation that I found particularly eye-opening, on the difference between technology leadership and leadership of technology-powered organizations:

So what does it take to lead an organisation towards adopting the practices, cultures and technology of the internet-era to respond to people’s ever-increasing expectations? Rarely a training course in technology.

It does require credible, collaborative and unrelenting technology leadership. You can’t be an organisation fit for the 21st century on premise. If your technology leadership is more into blockchain than user needs, you’re doomed. If your technology leaders can’t connect with staff handing down infosec judgements from on-high, no amount of McKinsey can save you. But that’s fixable.

Technology leadership and leadership of an organisation powered by technology aren’t the same and pitching the former to the latter won’t appeal. So what are the broader attributes required of organisation and system leadership to foster a truly digital culture?

(Plus, I’m automatically a fan of any blog post that includes a dig at blockchain.)

Matthew’s post outlines a series of leadership attributes for digital leaders and organizations:

taking a customer view and looking at gaps in their current experience
understanding that outcomes are complex and that things that worked in one place can’t necessarily be replicated elsewhere
managing change towards ambiguous futures and carrying uncertainty for others
knowing that openness is a prerequisite for innovation, and being open by default

These attributes remind me in a lot of ways of Public Digital’s “Internet-era ways of working” post from 2018, one of my favourite blog posts. Gergely Orosz’s post describing Silicon Valley companies’ approach to software engineering teams (autonomy, curious problem-solving, and transparency) is also a great related read.

Thinking about leadership in public sector organizations, the lack of digital expertise is something that often comes to mind. Coming from the tech industry, something that has tripped me up before is the expectation that senior executives (in any government organization) will be able to tell the difference between good and bad technology approaches or solutions. That’s a root cause of a lot of technology failures in government, and the usual conclusion is that senior public service leaders need more technology expertise or training.

Matthew’s post is an interesting counterpoint, that having a deeper understanding of technology products or systems may not actually lead to a more effective digital-era organization. Technology expertise is not the same as “running a user needs-focused organization that works well” expertise. Leaders that are empathetic, humble enough to learn from their teams, and interested in customers’ experiences and how to improve them may be better suited to leading organizations than strictly tech-focused leaders.

Leadership density, or leadership signal vs. noise

One of the challenges of public sector digital work is the sheer number of processes, groups, and people that any given initiative has to go through to make it out the door. These gatekeeper-type processes mean that even if a particular team or division has a great leader (or set of leaders), that isn’t sufficient to see a project succeed.

“Leadership density” is one way of thinking about how this works out in practice – how many of the decision-makers involved in oversight, gatekeeping, or green-lighting a project are enablers rather than blockers? How many of the decision-makers involved speed things up rather than slow things down? Mapping that out in a given organization or for a given project can give an early hint of how likely it is to succeed or not.

One solution to this is to incrementally reduce the number of gatekeeper processes or stakeholders that a project needs to go through to ship (towards single ownership and accountability for project outcomes). The other solution is a comprehensive effort to upskill or replace public sector organizations’ leadership cadre, to eventually achieve a set of leaders who all share the attributes that Matthew describes above.

Suggestions for the next Minister of Digital Government

Sat, 18 Sep 2021 07:30:48 -0700

Monday is election day – don’t forget to vote if you haven’t already!

Back in December 2019, I wrote a set of suggestions for the next GC Chief Information Officer. In the same tradition, below are some suggestions for the next Minister of Digital Government. This was a new ministerial role in the most recent government, created in 2018 as an additional role for the President of the Treasury Board, and established as a separate minister in 2019.

At present, the Minister of Digital Government oversees three organizations in the federal government: Shared Services Canada (or SSC, which runs IT infrastructure across government departments), the Office of the GC CIO (or OCIO, which sets government-wide IT policies), and the Canadian Digital Service (or CDS, which helps departments deliver better public-facing services). Full disclosure, I work for one of these organizations. 😅

Digital government work – and public service reform, more broadly, which is what it ultimately is – isn’t really a newsworthy election topic. It’s near and dear to my heart, though, and I’d love to see more conversations about it from public servants, politicians, and the public alike.

With that in mind, here are some suggestions! These are intentionally far from my day-to-day work, because, y’know, otherwise it’d be weird.

Archived tweet from Michael Karlin

Suggestions 📝

One of the challenges of the Minister of Digital Government portfolio is that – more than most other Cabinet roles – it goes deep into the “how” of how the public service works, not just the “what” of what public servants are directed to work on. That’s not something ministers are accustomed to thinking about, and it’s also not something that senior public servants are expecting to hear ministerial opinions on. The more specific these kinds of recommendations get, the harder they can be to convince public servants to implement them:

Access to information

Increase the retention period for completed Access to Information summaries. Right now, summaries of past Access to Information requests are published on the Open Government website, run by OCIO. The published list only includes the last two years’ worth of entries, which is very short for what would otherwise be a useful historical record. Changing this to a 10+ year retention period would be very little effort, and be valuable for public administration researchers and journalists everywhere. The next step could be to work with Library and Archives Canada to archive summaries indefinitely, as a publicly-accessible dataset.
Begin rolling out a “release to one, release to all program” pilot. Several U.S. states and other jurisdictions around the world have a standard program of publishing the actual substance of completed access to information (or freedom of information) requests – the documents themselves – rather than just summaries of what was asked for. This is often called “release to one, release to all”. In the past, concerns about Official Languages Act compliance and web accessibility have been raised as a barrier to doing this in Canada. Publishing released documents under the authority of Library and Archives Canada – or investing in automated ways of extracting the text of released documents, to make them more accessible – could be potential ways to address this.
Update the Copyright Act to make Government of Canada productions public domain by default. The United States, again, is decades ahead on this – any U.S. federal government publication belongs to the public domain, by default. This makes it possible to reuse U.S. government information in a huge range of other contexts, everything from analyzing climate or finance data to publishing photos of astronomical observations or military aircraft on Wikipedia. Canada doing this would be a huge boost to the open data community, to academic researchers, and to educators. All of these groups currently need to navigate the murkiness of Crown copyright to stay on the right side of the law.

Web publishing

Invest in new content management system options for departments not on Canada.ca. Canada.ca was originally planned as the one content management system to rule them all. Only a few dozen departments and agencies ultimately migrated to it, however. Since the migration effort wound down, it hasn’t been clear if departments are allowed to invest in other modern content management options. As a result, many departmental websites still use incredibly old, fragile systems (or hand-crafted HTML) that limit how quickly and effectively departments can communicate with the public.

Service delivery

I have thoughts here, but I’ll leave them to others to share. Suffice to say, it’s an area with a lot of room for improvement!

Digital talent

Publish department-by-department statistics on the number of in-house versus contractor/consultant IT staff. A large portion of federal government IT work is undertaken by contractors. This has a lot of implications for institutional memory, accountability, opportunities for SMEs, and vendor lock-in. Consultants have been described as “ubiquitous as wallpaper and about as unexamined”; collecting more data on how large a role they play would be a great start.
Encourage departments to withdraw requirements that CS staff only work in CIO divisions. Earlier in 2021, TBS’s Office of the Chief Human Resources Officer published a useful bulletin to departmental heads of HR, confirming that teams can include a range of classifications, and that reporting structures can include a mix of classifications. In practice, departments usually require homogenous reporting structures, and many have requirements that CS (computer systems) staff can only be hired within CIO divisions. Both of these are barriers to the kinds of multidisciplinary teams that do the best work. They also reinforce a lack of non-management software developer career progression tracks that are common in modern technology companies.
Promote multidisciplinary teams and publish reusable job descriptions for design researchers, product managers, and other design and technology roles. The United Kingdom launched the “Digital, data, and technology” career framework in 2017, in order to more effectively hire and retain digital professionals. Modern digital roles like design researchers, product managers, interaction designers, and data engineers don’t fit clearly into the Canadian government’s existing landscape of job classifications.

Large project management

Implement a maximum duration and financial cap on IT projects. This is repeating myself a bit, since this was also on my list of suggestions for the GC CIO. Large project sizes – in time, financial cost, or both – are far and away the most likely to fail. One of the most effective interventions a future Minister could make is to set and enforce a hard cap on the maximum size of projects. Anything larger would need to be split into smaller projects, that are shipped and deliver tangible value to the public, before follow-up projects are started. Actually stopping expensive, in-flight projects takes a lot of guts and political capital, though. The United Kingdom’s spend controls are estimated to have saved £1.3 billion over five years (about $2.3 billion CAD); it’s definitely a strategy worth emulating.
Require that medium to large IT projects publish public proposals, gather feedback, and incorporate that feedback into subsequent funding submissions. If an effective size cap (the item above) was in place, this wouldn’t necessarily be needed. Thus far, though, I haven’t seen any of the oversight processes in place actually stop ill-fated projects. Subjecting them all to public scrutiny would be a fascinating way to see which ones hold up. Having a department put out a plan for a major IT project for the public to see – while it’s still in the early planning stages – would be a great litmus test. Is it built with technology that typical tech companies would be embarrassed to still use? It might not be starting off on the right track.
Reduce the number of oversight committees within departments and at a GC-wide level, to approach single ownership of project outcomes. Each time there’s a major government IT failure, new oversight processes and committees are created to add more scrutiny to future projects. Counter-intuitively, though, this actually dilutes any sense of clear ownership over projects’ outcomes (and adds a lot of unhelpful administrative burden). If a project made it through 12 committees, then failed, was it really anyone’s fault? One of the main takeaways from the Phoenix review is that each IT project should have a single, accountable owner. To get there, one important starting point would be to reduce the number of oversight committees (both centrally and within departments) as much as possible.

These are just a few ideas that a future Minister of Digital Government could champion, regardless of political orientation. I’d love to hear what others think – what would you like to see the next Minister of Digital Government take on?

If you see other blog posts or publications asking this – or if you write one! – let me know and I’ll add a link to the bottom of this post.

To every Canadian citizen: happy voting! And to my fellow public servants: good luck as you finalize transition advice for the weeks and months ahead! Rock on.

Installing Jekyll locally on MacOS Big Sur

Tue, 20 Jul 2021 17:02:32 -0700

Our team often uses Jekyll and GitHub Pages to build micro-sites for project documentation. Jekyll is a static website builder, which makes it easy to build and deploy essentially indestructible (although usually not interactive) websites. Similar tools include Hugo (my go-to for most civic tech projects), Gatsby (which powers “Is this blocked in my department?”), and Eleventy (which I’ve only used once, but found really easy to use). Jekyll is the OG of static websites and it’s a bit dated nowadays, but GitHub Pages’ built-in support for it is really handy.

I recently set up Jekyll for the first time in a while on a new computer, which involves getting Ruby and the Bundler package manager to work happily. Here are the steps I used.

(Note that this is for a fresh install on a new Mac, using the default zsh shell; if you’ve upgraded to Big Sur and have older Ruby versions or packages installed, you may want to follow the steps here or here to use Homebrew, rvm, or another installation method.)

Installation steps

1. Clone the static website repository you’re working on, and cd into that folder.

2. Check that a new enough version of Ruby is installed to meet Jekyll’s system requirements:

ruby -v

The version of Ruby included with Big Sur (currently 2.6.0) is recent enough; good to go there.

3. In the past, I’ve installed Ruby gems using sudo, as part of the system Ruby installation. That’s no longer recommended, so instead I did the following:

gem install --user-install bundler jekyll

4. Then, I added Bundler (and other gems) to my path file following the instructions here:

echo 'export PATH="$HOME/.gem/ruby/2.6.0/bin:$PATH"' >> ~/.zshrc

Note that for newer versions of Ruby, you should change 2.6.0 above to match your installed version. If you’re using the Bash shell the syntax is slightly different.

5. Once Bundler was installed, I needed to use a similar approach to save bundle packages locally, rather than in a system-wide location.

From within the website folder, I ran:

bundle config set --local path 'vendor/bundle'

Which saves packages to a “vendor” directory within the project folder, similar to Composer’s “vendor” folder or npm’s “node_modules” folder.

6. Then, I ran:

bundle install

7. Finally, you’ll need to exclude that vendor folder from Jekyll’s config file, so that it doesn’t try to parse and generate webpages from anything recognizable in that vendor folder. You can do that by adding a “vendor/” line to the exclude config list, for example:

exclude:
- .ruby-gemset
- .ruby-version
- Gemfile
- Gemfile.lock
- Makefile
- README.md
- vendor/

8. You’ll want to add the following lines to your .gitignore file as well:

vendor/
.bundle/

9. After that, you’re good to run your Jekyll site locally! You can do that with,

bundle exec jekyll serve --watch --baseurl ''

…although this might vary slightly depending on your Jekyll setup.

Happy Jekyll’ing!

Paying for low-cost cloud services on a departmental credit card

Sun, 11 Jul 2021 22:15:59 -0700

One of the themes of this blog is that access to modern tools has a huge impact on public servants’ productivity and effectiveness. This is true for public servants all across government departments, not just those that are working in explicitly “digital” teams and roles.

There are a lot of online tools available today – for team collaboration, for communications, for data analysis, for software development – that historically haven’t been easily available to public servants. This has changed for the better over the past few years, and the pandemic (with many public servants working from home) has illustrated just how critical these tools can be.

For Canadian federal public servants, one major improvement was the 2018 policy notice issued by the Office of the GC CIO, stating that departments should unblock access to online services and “enable open access to the Internet for GC electronic networks and devices”. Access to online tools is now, for most departments, much more straightforward than it used to be.

But, there’s been one long-standing hurdle to public servants adopting online tools: how to pay for them. Fortunately, as of this past week – thanks to the release of the Directive on Management of Procurement – this just became significantly easier.

Why paying for online services matters

Many online services (particularly those aimed at a consumer market) have free tiers, which let people try the service out with limited functionality without paying. Since the 2018 policy notice, this has been the norm for a lot of government teams – they can set up a new service in minutes, using a free tier. On the other hand, getting approval from internal IT or procurement groups to actually pay for the same service could take months or years. For low-cost services, the public servant staff time needed to complete the procurement process could cost close to, or more, than the service itself.

Companies providing online services, in turn, by and large aren’t interested in government procurement or invoicing processes. When the cost of their services (for, say, a small team) is $30 or $100 per month, dealing with a government purchase request, getting custom terms legally reviewed, and sending traditional invoices – the activities normally needed to pay for software in government – is an order of magnitude more expensive. These companies all have better things to focus on, namely their thousands or millions of non-government customers, and they’ll often only accept payment by credit card.

Although free tiers are a great way to try out a service – and to see if it meets a team’s needs – it’s usually super valuable to switch to a paid tier as soon as you possibly can.

Paid tiers of online tools typically add a wide range of important security, user management, and data export features. For government teams using these tools, these are often really critical:

Free tiers of collaboration tools like Trello don’t have overarching user management options, so if an employee leaves your team you need to ask them to manually remove themselves from your organizational Trello account. Imagine if an employee were to leave under less than happy circumstances – it would be messy. User account handling tends to be much more robust on paid tiers than on free versions of services.
Free tiers of services like Slack limit access to older messages, once an organization’s Slack history reaches a certain size. If teams don’t upgrade to a paid tier, they wouldn’t be able to comply with Access to Information requests or other information management activities that apply to older messages.
Important security features like multi-factor authentication, single sign-on, and activity audit logs are often only included in paid tiers of services. These are all security protections worth adopting as soon as you can.

All told, paid tiers of online services are lower-risk than free tiers from an organizational and security standpoint.

Traditionally, though, departmental procurement and financial divisions have been reluctant to allow teams to pay for online services with a departmental credit card (credit cards being, again, the only way to pay for them).

One barrier that would frequently come up is the 2013 Policy on Decision Making in Limiting Contractor Liability in Crown Procurement Contracts. According to that policy, only the deputy minister of Public Services and Procurement Canada could accept commercial terms that limit vendors’ liability to the government if things go wrong. That, in turn, was frequently interpreted to mean that government teams couldn’t accept the standard click-through terms of use for online services, which almost always include liability provisions. (For example, that the service provider is only liable for the cost you as a customer paid in the past 12 months.) This left teams with two unappealing options:

Asking the deputy minister of PSPC if your team could spend $15/month on Trello and accept Trello’s standard terms and conditions. Not exactly a viable option.
Asking the provider to sign a Government of Canada-created and negotiated contract agreement. Given the length and complexity of a typical GC contract, the provider’s legal costs for reviewing the contract would far exceed the $15/month revenue.

Bring on the new directive

Fortunately – after years of work – the new Directive on Management of Procurement is now published and active.

One of the key parts of the new Directive is that it officially deprecates the 2013 policy on limiting contractor liability. 🎉 It replaces it with an appendix titled Mandatory Procedures for Limitation of Contractor Liability and Indemnification in Contracts. The bulk of that appendix is focused on larger scale categories of procurements (commodity groupings) – for example, Shared Services Canada setting up multi-million-dollar cloud infrastructure contract vehicles.

But (and this might be my favourite part of any TBS policy appendix!) it includes the following section on low-dollar-value services:

In the absence of a viable existing commodity grouping, where appropriate, accepting standard commercial terms and conditions related to the limitation of contractor liability associated with low-risk and low-dollar-value goods and services, including subscriptions, software, mobile applications, cloud services and open source software. (B.1.1.4, emphasis mine)

This means that government teams can accept the standard terms and conditions of low-cost online tools. It’s a small thing on paper but the impact on teams striving to work in modern ways is going to be huge.

This is also a big win for small and medium-sized software and software-as-a-service companies, including Canadian ones. It gives departments access to services that previously required the provider to sign a Government of Canada contract, which can be confusing and difficult to navigate for small businesses that aren’t accustomed to government procurement processes (compared to, of course, large IT companies who have whole teams dedicated to winning government contracts!).

How do we actually pay for a service, though?

This is a question that comes up a lot! For federal public servants in typical departments, the answer is:

Find someone on your team with Section 32 financial signing authority (typically a director or director-general role) who can say “I approve this purchase” in an email thread about a particular service.
Find someone with a departmental acquisition card (typically an admin person) who can actually pay for it, on a monthly or annual basis. (Getting a departmental acquisition card involves a non-trivial amount of mandatory training and approvals!)
Make sure that the person with the departmental acquisition card has a copy of the “I approve this purchase” email so that they can handle the credit card reconciliation process every month, or whenever credit card charges take place. (This is a genuinely painful amount of paperwork; admin people are heroes.)

This all depends, of course, on the cost of the online service being below the competitive bidding threshold for services (currently $40k), as well as being below your department’s per-transaction credit card limit (which varies from department to department).

There are still a lot of other things to think about (for example, security considerations for anything other than unclassified data; accessibility considerations for both internal colleagues and members of the public, depending on the use-case; ways to export your data to avoid vendor lock-in). But, paying for a paid tier is a really important initial step.

Considerations (hat tip fellow policy wonks!)

The Directive is newly-published, but adds the flexibility that teams have been seeking for a long time. More guidance will probably come out in the future to help answer questions people might have about it. In the meantime, here’s a couple of considerations to keep in mind:

Read all the terms before clicking “accept”. When you accept commercial terms, you are entering into a contract. Commercial terms may offer “best effort” protections for data recovery and may share data with third-parties. This isn’t to say you shouldn’t use a service, just know what you’re going into and make your usage proportional to the terms offered.
Section B.1.1.4 is focused on low-value and low-risk software and subscriptions. “Low” isn’t quantified in the directive. $15/month Trello safely falls into this category, but when the buy is in the tens of thousands of dollars, it’s probably time to start thinking of negotiated terms instead of commercial terms. As you start committing more precious information or processes to a service, you will want tighter terms between you and the supplier. Fairness and competition also becomes a factor as the value increases.

All that said: you learn the most by trying something. Choose a low-cost online service that might speed up your team, and go for it! If you run into issues, check out Should it be blocked in my department? for some extra tips on getting started with online services in government settings.

What’s next?

One thing I’d like to see in future procurement guidance is clarification on how to apply competitive vs. sole-source thresholds to recurring subscription services over time – for example, if you were using a service that cost $10k per year, would you then, after four years, have to competitively procure it when you pass the $40k point?

Procurement folks that I’ve spoken to have shared different perspectives:

One view is that, with a monthly subscription (for example), the service is “delivered” and used each month. Because each month is a separate, complete deliverable, this doesn’t constitute contract-splitting (which would be, breaking a deliverable into smaller, incomplete pieces in order to fit below financial approval or reporting thresholds – like receiving half of an expensive bridge this fiscal year and the other half next fiscal year, as two “unrelated” contracts).
The other, opposing view is that the cost of services should be considered over the lifetime of the program that they’re procured to support (programs being, for example, “providing employment insurance to Canadians”). Under this view, teams would invariably need to competitively procure a given service eventually, once its cumulative total cost crossed the threshold.

I’m convinced that the first view is a stronger argument, but, of course, I’m biased since it leads to more public service teams being able to use modern online services more easily. The clarification I’d like to see – that finds a nice balance between both viewpoints – would be to apply the competitive bidding vs. sole-source threshold over a 12-month fiscal year basis. Under that approach, as long as a given service doesn’t cost more than $40k per year, you wouldn’t need to competitively procure it, even if you ended up using it the following year as well.

The takeaway for policy writers is: always attach time ranges to your financial thresholds! You’re welcome.

To unsung heroes

TBS’s Office of the Comptroller General – which published the new Directive on Management of Procurement – did phenomenal work to bring it out the door. Changing procurement policies is not a glamorous part of making government better, but it is so critical. There’s so much more to do, but in just a few sentences this Directive update solves an issue that public service teams have faced for years.

To Danielle, Daphné, Mark, and so many others at OCG, and to Scott and Sarah at OCIO who helped push this forward, you’re all awesome. Keep on rocking.

Rule number one: Avoid vendor lock-in

Wed, 12 May 2021 16:07:26 -0700

People who know me know that I’m not a big fan of rules. My day job involves a lot of navigating and working around outdated rules, helping teams figure out which rules are red rules instead of blue rules, and trying to change existing rules to be more empowering to digital service delivery teams and everyday public servants. Interpretations of rules and myths around them are some of the main barriers to governments trying to adopt more modern ways of working.

On more than one occasion, friends who are working on rule changes (updated administrative policies, for example) have asked what I’d suggest, and my non-sarcastic answer has been: if we actually got rid of all of those rules, would it lead to better outcomes?

I have one exception, though! My general advice for life is: be a good person, and care for the people around you. And follow this one very specific rule: avoid vendor lock-in.

What is vendor lock-in?

Vendor lock-in is a situation that government and institutional IT teams often find themselves in, where they are dependent on a specific vendor (an IT systems provider, software company, or management consultant) and they aren’t able to stop using them.

It’s a power dynamic where IT teams aren’t able to make changes (for example, to improve a system or move to a new one) because they’re stuck with their current vendor. It can happen for a variety of reasons, and it usually emerges over a period of time.

Vendor lock-in is a problem because it slows down or prevents teams from making improvements; it leads to worse user experiences over time, as a result; and it often leads to dramatically higher costs. It’s great for vendors, though, who benefit from an always-increasing revenue stream and a guaranteed customer, no matter the quality of the product or service they’re offering.

How do you avoid vendor lock-in?

Have an exit strategy! Avoiding vendor lock-in is all about finding ways to keep your future options open. There’s a great quote from one of the original writers of the Agile Manifesto:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

The suggestions below are strategies to avoid vendor lock-in, and to preserve your ability to make future changes. They’re written for public service teams working on technology and service delivery projects. Some of these strategies depend on a certain level of internal technology capacity – something organizations aren’t always prepared for, but that over time is likely cheaper than a locked-in dependence on an external vendor. In other cases, these can be achieved simply by writing better procurement contracts with the vendors you work with.

It’s a long post! Here’s quick shortcuts to each section:

Own your data (and make sure you can move it somewhere new)
Own your front-end interfaces
Own your software source code
Avoid long-term contracts

And lastly, since I’m sure you’re wondering: What should vendors do, then?

1. Own your data (and make sure you can move it somewhere new)

The biggest mistake I see in past government procurements is not explicitly owning the data generated, input into, or collected by a vendor-operated system. This can include user account data, case management information, documents, financial records… all the things that, if you were to switch from your current vendor’s system to a competitor’s system, you’d have to somehow extract and move. If you as an organization don’t actually own that intellectual property, then you’d need to start from scratch in order to change vendors.

In worst-case scenarios, I’ve heard of cases where organizations have had to bargain or plead with their current vendors to give them this data, prior to running a competitive procurement process for a replacement system that the same vendor will be participating in. It’s not a bargaining position you want to be in. Lock it in to the very first contract you write, that you as the government or organization own the data (including user account information) that will be stored in the system.

Even if you own the data, actually getting it out of a system in a format that can be re-used is also frequently a problem. Older proprietary databases, case management systems, and enterprise resource planning systems often didn’t have any systematic way to export data. Without built-in, comprehensive export features, migrating to a different system becomes a manual, error-prone, and potentially years-long process.

As a rule of thumb: have an exit strategy written down for any major system before you even start using it. (Can you export all of the data the system stores, in an automated, machine-readable way? That’s the bare minimum.) Your future self, years later, will thank you.

Always have an exit strategy.

2. Own your front-end interfaces

Interfaces refers to the way that people interact with your service or system – what it looks like, how it works, and how people use it. “Front-end” refers to the layer that people see (for example, the website or web application that they directly interact with).

Interfaces can be challenging to build and maintain, and it takes a lot of expertise to make user-friendly and accessible services. External vendors are often hired to build and maintain these interfaces, as a result.

In many cases, however, organizations will simply outsource an entire service to an external vendor. This sets up a situation where people interact with the vendor’s website and interfaces directly, instead of with the organization itself. This intermediary role and function – one that places a vendor between a government and the people it serves, is one to be protected and managed extremely carefully. There’s a strong argument to be made that front-facing service delivery functions like this should never be outsourced. How this shows up in new procurements is an area to keep a close eye on.

The vendor lock-in here comes from the fact that, over time, people using the external vendor’s service will get used to it. People identify the vendor and their products as the way to receive a given public service, rather than the public sector institution that is now behind the scenes. That makes it disruptive and complicated to switch to an alternative service (either in-house or from a competing vendor). Or at the least, it will feel prohibitively disruptive to decision-makers in your own organization, who will want to stick with the existing vendor longer than it adds value. One way to think about this is as self-constructed lock-in – even if you can legally end the contract, can you functionally expect people to stop using it? Likewise, from the inside of the public sector organization, once established operational workflows are built around a specific product they create a significant disincentive for future change. Habits and routines make changing later all that much more difficult.

Even if your organization doesn’t have in-house expertise in front-end interfaces, you can hire a vendor to build high-quality services that you own and operate (more on that below). If your approach instead is just to deliver services that aren’t user-friendly, that’s not a great solution.

One last part of owning your front-end interfaces is owning the domain name or subdomain that a service is running on. If a vendor helped you set it up but they own the domain name registration, then there’s no way to move away from that vendor without either forcing people to learn a new website address for your service, or having that vendor cooperate nicely in your own departure. Don’t count on the latter.

3. Own your software source code

Governments and organizations depend on a lot of custom software code, whether it originates from purpose-built systems or customizations to “commercial, off the shelf” software. In the Canadian federal government, most of this software code is written by external contractors.

Historically, a lot of this software code has been owned by these contractors; various administrative policies encourage this. Even software that was originally developed in-house by government institutions has been spun-off into commercial software companies, through processes established for this purpose, only for the government to then pay to license it back from those companies.

All this is to say: Canada is pretty late to the open source approach that other governments enthusiastically adopted years ago.

When you don’t own your software source code, you’re vulnerable to vendor lock-in in a few ways. The licensing terms for a software product might prevent you from making certain kinds of modifications or improvements (including, for example, changes that would make it easier to export data). Modifications that you’ve made over time, built into or using the same proprietary software products and languages, can make migrating to a replacement system feel even more complex and unattainable.

Not even considering proprietary software licensing costs, all of these are reasons to own the custom software source code you depend on. When you’re starting a new project, using open source software products as a foundation, or existing software that you already own, is a critical way of avoiding long-term vendor lock-in. Making your own custom software code open source, so it can be shared and re-used by other organizations, is also a big win for both financial stewardship and public transparency.

As Bianca Wylie would say: public money? Public code.

4. Avoid long-term contracts

There are a lot of incentives for public servants to set up long-term contracts, and the onerous nature of government procurement processes is one of the biggest ones. (Waterfall-oriented budget and planning approval cycles are others.) Undertaking a complicated procurement process every few years isn’t appealing, and so public servants often set up five- or seven- or ten-year long contracts with IT vendors and service providers.

Fight that temptation. Long-term contracts are vendor lock-in on purpose; the other sources of vendor lock-in above (not owning your data or interfaces or source code) are vendor lock-in by accident.

Among digital transformation types, you’ll often see everyone shaking their heads as yet another government department celebrates successfully signing a ten-year contract with an IT vendor. The only constant in the technology world is change. What your needs are, as a government institution, will be dramatically different a decade from now. (If they aren’t, you probably aren’t serving your constituents or service users as well as you should be!) The products or services a given vendor provides, even if they’re the best-in-class today, aren’t necessarily going to be the best, cheapest, most secure, or most accessible in a decade.

When you’re putting together a procurement contract, keep your options open by keeping the contract length as short as you possibly can. Two years is alright; three years is long; anything longer and you’re setting yourself up for future embarrassment. If you’re working with a complicated system or you’re really constrained for technology talent, then a two- or three- year contract with a few option years afterwards might be okay. Don’t lock yourself in to anything longer than that.

Countries that are further ahead in their digital transformation journeys have implemented maximum monetary value and duration limits on IT contracts. In the future, it would be great for Canada to adopt a similar approach.

What should vendors do, then?

This post might seem like it’s setting IT vendors up as some kind of villain; they’re not, they’re just responding to the incentives that exist for them in public sector IT. (If you’re a vendor, I’m sure you’re cool!)

By becoming a more savvy, vendor lock-in-aware customer, you’re incentivizing the vendors you work with to put forward their best work. If you’re able to easily switch to another vendor whenever the situation warrants, your vendors will be that much more motivated to do high-quality work.

There’s a few areas where using an external vendor often does make more sense than doing things in-house. These include:

Public cloud infrastructure. Large-scale cloud providers like Amazon Web Services, Microsoft Azure, and Google Cloud Platform offer highly reliable, secure hosting and computing services at a much lower cost than bespoke, on-premise systems. The Canadian government recommends public cloud for practically any use-case (outside of defense and intelligence work). As a government institution, you should manage accounts on cloud infrastructure yourself, rather than depending on a third-party vendor or reseller to do this. There are some important philosophical issues with large-scale cloud providers, but my main reason to recommend them is that you can begin using them very quickly – in minutes, not days or months (compared to many governments’ internal shared or cluster infrastructure options). These large-scale cloud providers are inexpensive and high quality. And as long as you manage the accounts yourself and own your own domain names, you could switch from whichever cloud provider you’re using to a competitor whenever you want to.
Specialized behind-the-scenes services. API-based platforms like Twilio (for SMS and phone communications) and Stripe (for credit-card handling) have great reputations for reliable service delivery and easy integration into other systems. (Part of this is thanks to high-quality developer documentation). You can integrate these platforms into your services while still owning your front-end interfaces and the rest of your software source code. In areas like credit-card handling that have stringent security compliance requirements, offloading this to a vendor like Stripe can significantly reduce the complexity of your service. As always, just make sure you have an exit strategy to another provider if you end up needing it.
Custom software development, if you really need to (but open source it!). Many government institutions don’t have the in-house design and technology talent needed to deliver modern online services. That’s a significant problem, but in the short term, depending on vendors is going to be a reality for most organizations. To do this well, in a way that avoids vendor lock-in, there’s three steps to take. The first is, require that the intellectual property developed under the custom software development contract is owned by your organization (for example, the Government of Canada). The second is to license that custom software under an open source license and to publish it publicly somewhere (ideally, in real-time as it’s built by the vendor). The third is to keep the contract for custom software development fairly short (again, two to three years) so that, if need be, you can switch to a competing vendor in the future. As long as the software code is owned by your organization and publicly published, the replacement vendor can then fairly seamlessly continue working on the software initially produced by the first vendor. As an added benefit, the vendors involved will be motivated to do high-quality work, since it can be scrutinized by the entire world.
External security and accessibility audits. There are some areas of design and technology where specialized expertise can be particularly critical. Making sure that your services are secure and robust – and making sure that everyone can use them – is essential. Even if you have in-house technology capacity, it can often be really helpful to enlist an external provider for security and accessibility reviews, especially at certain points (prior to launching a brand-new or redesigned service, or a large-scale new feature). Over time, you should develop in-house security and accessibility expertise, but short-term contracts with companies that specialize in these fields can be a lifesaver in the meantime.

Vendor lock-in doesn’t just happen in government institutions; it can happen in private companies as well. But it seems to be extra prevalent in public sector organizations, partly (in my view) because of how laborious approval and contracting processes are; partly because of outdated IT strategies; and partly because of a lack of technology expertise among senior decision-makers in the public service. This is compounded by situations where government departments and public service leadership depends on vendors for advice on how to deal with vendors. (This frequently occurs with management consulting companies, who also have large IT service provider divisions.) I’ll write more about these in future posts.

Thanks for reading! Thoughts and feedback are always welcome, don’t hesitate to reach out anytime!

Curious what vendor lock-in looks like in a tangible way? Read about the City of Toronto’s recent PayIt procurement in Regs to Riches and Tech Reset Canada.

Yukon stopped doing seasonal time changes and it’s… really great

Wed, 10 Mar 2021 19:05:03 -0700

Heather and I moved to the Yukon about a year and a half ago. Last February, shortly before the pandemic, the Yukon government did a public consultation on getting rid of daylight savings time changes. When the results came in, 93% of Yukoners were in favour of stopping seasonal time changes.

Let’s just say… I was stoked.

As someone who grew up in Saskatchewan and never experienced daylight savings time changes growing up (Saskatchewan is on permanent daylight time), I’ve always been mystified by other provinces’ seasonal time changes. When I moved to Ontario for grad school, experiencing the fall time change for the first time left me totally floored. (So confusing, and so dark!)

Ever since then, I’ve always been excited to see other countries’ proposals to eliminate seasonal time changes, although (in the case of Egypt and Russia, for example) these haven’t necessarily originated from governments that I’d otherwise look up to.

Yukon making the change was thrilling both on account of, well, living here, and on account of the government conducting the public consultation and then going for it in the same year. Last spring’s time change was the last one to take place, and in the fall before the time change would’ve normally happened, the Yukon government sent friendly reminder cards to people’s mailboxes to remind them that seasonal time changes were a thing of the past:

When other provinces fell back an hour in the fall, Yukon stayed the same, which also brought us an hour closer to family, friends, and co-workers in Ontario over the winter. It’s been really nice!

Making it happen

There was a great CBC article (hat tip to Lucas, who shared this!) interviewing the Yukon public servant who had been tasked with actually implementing the end of seasonal time changes here.

Practically speaking, that meant creating a new standalone timezone (for Yukon time) and somehow communicating that to technology companies, telecoms, and other groups responsible for “time” as determined by all the systems we rely on:

“It has been a real adventure to figure out how exactly time works, who controls time, what time is,” said Andrew Smith, who is leading the government’s preparations.

In order to change Yukon’s time zone online, Smith said he had to follow “the bread crumbs” to track down the international time zone databases. He says he’s been in touch with all the telecom companies in the territory, trying to ensure phones and computer clocks don’t fall back an hour on November 1.

He urged Yukoners to ensure their phones have the latest updates, and are set to the time zones “UTC -7 Yukon” or “Whitehorse” on Apple devices.

A couple of times during the summer, my laptop greeted me with the following screen, and all I could think was: I can’t wait!

What about the rest of Canada?

Aside from Saskatchewan and now the Yukon, a number of Canadian provinces have planned to eliminate seasonal time changes, but haven’t gone forward with it yet.

In the case of British Columbia, it passed legislation in 2019 that makes it possible to switch to permanent daylight savings time. But, it plans to only change in coordination with Oregon, Washington state, and California.

Likewise, Ontario passed legislation this past November that also makes it possible to end seasonal time changes. Similar to BC, though, Ontario only plans to change if Québec and New York do the same.

Coordinating across regional boundaries makes sense, but it causes a sort of “lowest-common denominator” approach where things will only change once the least-enthusiastic province or state changes, which could be decades from now.

Research consistently indicates that seasonal time changes have negative effects, as the Ontario article mentions:

Studies have shown that the bi-annual tradition can cause “serious negative effects,” including increased depression rates, heart attacks and strokes, Roberts said.

He added that one of the benefits of ending the twice-yearly change includes promoting more consumerism by giving residents more hours of daylight in the evening.

In the United States, people have been making the case for eliminating seasonal time changes for years. Among many other reasons:

…there’s evidence that a year-long DST might reduce traffic-related deaths, especially for pedestrians. On the whole, daylight saving means that more travel occurs during daylight, when it’s easier to see pedestrians, which is why researchers calculate that full-time DST could save a few hundred lives annually.

Finally, there’s another, simpler benefit to making DST year-round: It’s a hassle to switch your clocks and adjust to a new time twice a year. And, as mentioned, doing so appears to have real costs in terms of productivity and accident rates, as our bodies adjust to the missing hour of sleep.

Everyone seems to agree that seasonal time changes have more downsides than upsides. But, at least in Canada, only Yukon has had the courage to actually get rid of them. To the folks in the Yukon government that made this happen, I tip my hat. Thanks and keep on being awesome! See you next week, same time as always.

If you want enterprise services to be good, make them optional

Sun, 14 Feb 2021 20:52:15 -0700

“Enterprise” is a fascinating term, in that it’s widely (and aspirationally) used in government and organizational IT, and also made fun of frequently by digital transformation advocates. Generally speaking it means: systems and services that are used across an entire organization, rather than just one specific program or team. In government settings, “enterprise” often means services that are used across the entire government, or, efforts to make that a reality.

I’ve written before about how standardization efforts often backfire, and it’s one of the reasons that enterprise IT systems – standardization on as large a scale as possible – tend to have a bad reputation.

As a concept, adopting enterprise approaches is a fairly widely-held priority in the Canadian government. Fewer systems, adopted more widely, can mean less specialized training and expertise is necessary, and that staff can move from team to team or organization to organization without having to re-learn how unique systems work. In an expertise-constrained environment, this isn’t a bad approach. But there’s an (admittedly counter-intuitive) way to significantly increase the quality of enterprise systems: make them optional.

An Amazon case study: if you don’t have competition, create it

Amazon (yes, the online bookstore-turned-logistics and software behemoth) is famous for its approach to software engineering. David Eaves has a great article about Amazon’s engineering approach here, and what it means for government IT. A simple software architecture decision in the early 2000s – that any internal services need to be externalizable, and to communicate with each other using APIs – laid the groundwork for what became Amazon Web Services, the largest cloud infrastructure provider operating today.

By building internal systems with the scalability and security that would let them be adopted by the outside world, it was easy for Amazon to turn its internal infrastructure into services that other customers could pay for and use.

There’s a more subtle benefit to this approach, beyond just being able to make money from surplus computing power. By turning its internal systems into external products, Amazon can very quickly learn if its internal systems are commercially-viable. If they’re not, then Amazon can either invest in improving a given internal system, to catch up to whatever competitors exist in that field, or they can drop it and use a competing product internally instead.

At my old company, we built communications and survey tools used by international development organizations. One of the optional services we provided was setting up or helping operate small call centres. In 2017, Amazon launched a self-service call centre platform, which we watched with a lot of interest. Having Amazon launch a product in your field is …not an uncommon experience for tech start-ups.

One of the reasons Amazon launched this product was to see if their own internal call centre software was good enough to keep using it. As a TechCrunch article from the time explains:

In the 10+ years since AWS’s debut, Amazon has been systematically rebuilding each of its internal tools as an externally consumable service. A recent example is AWS’s Amazon Connect — a self-service, cloud-based contact center platform that is based on the same technology used in Amazon’s own call centers. Again, the “extra revenue” here is great — but the real value is in honing Amazon’s internal tools.

If Amazon Connect is a complete commercial failure, Amazon’s management will have a quantifiable indicator (revenue, or lack thereof) that suggests their internal tools are significantly lagging behind the competition. Amazon has replaced useless, time-intensive bureaucracy like internal surveys and audits with a feedback loop that generates cash when it works — and quickly identifies problems when it doesn’t. They say that money earned is a reasonable approximation of the value you’re creating for the world, and Amazon has figured out a way to measure its own value in dozens of previously invisible areas.

“Mandatory” is not the advantage you may think it is

If you’re someone providing an enterprise service in government – whether it’s Government-as-a-Platform products, internal IT systems, web services, infrastructure, or anything else – you might be tempted to make it mandatory.

In government IT settings, decision-makers make particular internal software products or systems mandatory all the time. I’m curious why this happens, and I think it might be in part because – for public servants in leadership roles – making a thing mandatory seems more concrete and decisive than making it optional. In an environment where successful outcomes are long-term and hard to measure, simply making a clear decision is seen as a metric for success. Accurately tracking the long-term costs of IT projects and systems is also something that governments struggle with, and having one single system instead of several intuitively seems cheaper, even if that might not be the case in reality.

When I think of the (mandatory) enterprise software solutions in place in the Canadian government – the Phoenix pay system, the Shared Travel System, GCkey to sign into websites, the content management system that powers Canada.ca, the Shared Case Management System, GCdocs, and a number of others – none of them are solutions that in good faith I’d recommend that friends and colleagues in the public service use, if they had the choice. I wonder if the fact that they are mandatory is actually one of the reasons why these solutions are as dated and poor-quality as they are.

Make things optional, it makes things better

In comparison – as the Amazon example above hints at – there are a number of clear advantages to building services that are optional:

They create feedback loops. Users can tell you why they chose to use, or not use, your product.
They generate data about adoption rates versus competitors. If users decide to use an alternative product instead, that can tell you volumes about what features or benefits are a priority for them.
They incentivize continuous improvement. If users have the choice to use other products, you’re motivated to keep on improving yours in order to retain them as a user.

These advantages all apply even without needing to worry about commercial viability, in government settings.

There are downsides to making enterprise services optional; they can lead to fragmentation and inconsistent user experiences. But I’d argue that there are more significant downsides to making poor-quality services mandatory. Government decision-makers have a poor track record of telling the difference between good- and bad-quality technology solutions. And, even if a product was the best choice at the time, the slow pace of government decision-making means that it’ll still be mandatory five or ten years after it’s no longer the best option available.

If you’re a provider of enterprise software solutions, your services should be good enough that people want to use them, even when they don’t have to. And, from a professional craft and public service excellence standpoint: it’s better to build a good product that’s under-used than a bad product that’s over-used. Build good things, and make them optional.

A year’s worth of IBM ads

Sat, 06 Feb 2021 12:04:28 -0700

Jump to the screenshots

Online advertising is a fascinating thing. The layers of personalization and customization behind online ads (and the personal data that drives these) powers a large chunk of the tech industry. In ads on some social media platforms, sophisticated math generates hundreds or thousands of variations of an ad, learns which versions people look at or click on the most, and prioritizes those all automatically.

In my case, I don’t experience a lot of advertising, online or not; living in the Yukon and not owning a TV, there aren’t a lot of ads that I see on a regular basis. (“Experience” might not be the right word, if you’re not a fan of ads; maybe “exposed to” as in radiation or “confronted by” as in a barrier to your destination are better verbs!)

It’s an industry I find really interesting, and I’m a big fan of efforts to “reverse analyze” advertising (as everyday people on the receiving end of it). Paul Wells’ #sawanad effort from Canadian political campaigns a few years back is a neat crowd-sourced example of this.

When it comes to online ads, I don’t see a lot of them either; I use an adblocker browser extension (uBlock Origin, which I’d recommend enthusiastically to everyone using Chrome or using Firefox). Using adblockers eliminates practically all online ads and web tracking, improves the security of your computer, and speeds up your internet considerably as a result.

The only exception – where I do see ads on a regular basis – is within the mobile apps on my phone, namely, Twitter, which (as you can guess!) I use a lot. There isn’t an easy way to block ads in native mobile apps, like Twitter or Instagram.

Beginning in October 2019, right around the time that Heather and I moved to Whitehorse, I noticed that almost all of the ads I saw on Twitter were from the same company. Namely, IBM, the information technology company that frequently works with the Canadian government. What was striking wasn’t the ads themselves, so much as the frequency – anecdotally around 19 out of every 20 ads that I saw on Twitter were IBM ads, for more than a year.

Below is a series of screenshots of these ads, collected between October 2019 and October 2020. It makes sense that I’m in the target demographic for these ads (given that I work in technology in the public service), and I wonder how much of an impact advertising like this has on government IT decisions. (In similar ways, I wonder how much of an impact the advertisements for defence contractors, shipbuilders, and payroll software makers on billboards in the Ottawa airport have!) None of this is a criticism of IBM or any of these companies, which are well within their rights to advertise their products and services. But it’s a question for public servants, of what influences we’re exposed to and how we respond to those.

IBM ads on Twitter, October 2019 to October 2020

As seen from my own Twitter feed, using the Android and iOS Twitter apps. Adjacent tweets and usernames were blurred out. Note that these images (three composite files) might take some time to load. See a combined image here (9.3MB).

“Onerous levels of oversight”

Tue, 12 Jan 2021 22:34:00 -0700

Lee Berthiaume from the Canadian Press wrote a fascinating article last week, based on an internal Department of National Defence report on IT support. The report looks at DND’s IT processes and systems, describing them as “not only inefficient and expensive to maintain, but also often out-of-date and poorly supported”. From my vantage point this is consistently a problem across the federal government writ large.

The entire article is worth a read, but one section in particular stood out (emphasis mine):

The internal report also took aim at the military’s troubled procurement system, which was found to deliver IT equipment with inadequate or out-of-date technology. Poor planning was partly to blame but the report also blamed onerous levels of oversight.

While that oversight was described as the result of cost overruns and delays on past IT projects, the report said that it nonetheless created new problems in delivering modern equipment.

“The complex processes associated with the capital projects and procurement are very slow and cumbersome,” according to the report. “The process cannot keep up with the rate of change of technology.”

Those delays — and their potential impact on operations — were also cited as a major reason for why a patchwork of IT systems and programs now cover different parts of the Defence Department and military.

It’s really cool to see that internal teams at DND are putting together this kind of critical analysis, and really exciting that news organizations like the Canadian Press are shining a light on it. Public scrutiny of government IT, it’s my jam!

“Onerous levels of oversight” seems to very accurately capture one of the main root causes of IT failures in government. Which may seem counterintuitive, of course! The government has IT-related oversight processes across the board, for project management, procurement, security, and any other aspect of IT projects. This extensive oversight often exists as a reaction to previous IT failures, so it’s understandable to think that oversight would prevent future failures. But that’s often not the case.

Large IT projects are inherently likely to fail, and when political and public service leaders ask for action in response – “we have to make sure this doesn’t happen again”, or something along those lines – introducing new oversight processes is a familiar and comforting response. It’s a response that avoids asking larger, more existential questions about how IT projects are designed and implemented in government, and what public service leadership capacity would be required to make that happen differently.

Even the Office of the Auditor General – my all-time favourite Officer of Parliament, although the Office of the Privacy Commissioner is a close second – has fallen into this trap in the past. The OAG has published some brilliant pieces on how the government is failing to effectively deliver services to Canadians, as one of the few Canadian government institutions making the case for how important this is. But their recommendations following investigations into major IT failures (Phoenix, for example) often ultimately recommend more oversight, reinforcing the problems that the DND report describes above.

Almost a year ago I wrote a post titled “Introducing agile to large organizations is a subtractive process, not an additive one”. Every government department and division nowadays tends to describe their work as agile, or mostly agile; the challenge is that in a large majority of cases departmental teams haven’t been able to stop doing the non-agile processes that their institutional procedures require them to do (dozens or hundreds of waterfall project management artefacts, lengthy architecture review or investment planning committee presentations, pre-canned technical requirements documents that prevent future iterations or changes in priority based on user feedback). All of these oversight processes and the activities that support them take time and energy away from doing higher-value, higher-impact work that public servants could otherwise be doing.

Thinking anecdotally to the IT- and service delivery-related policies and processes that I’ve seen in practice across the federal government, easily more than half of them have a net negative rather than net positive impact on public service teams trying to deliver modern services. As just one example of this, ESDC’s IT strategy team has a truly phenomenal post describing how their existing project management and oversight processes increase rather than reduce IT project risks. The same is true in a variety of forms in practically every other federal department.

Many of these processes end up being self-reinforcing or self-perpetuating, partly since oversight and compliance work is more comfortable (to public servants accustomed to traditional policy work), and partly since siloed departmental oversight roles create incentives to be as risk-averse as possible. For example, if a project never makes it out the door, an IT security overseer achieves their lowest-possible-risk outcome even as the project team is catastrophically delayed. If an architecture committee mandates a problematic standardized solution, they accomplish their objectives even if that decision adds years of delays to other teams’ work.

Despite some promising TBS policy changes over the past few years, there’s still so much that could be changed – and the departmental procedures that most teams follow tend to both be significantly more complex, and to lag several years behind TBS efforts to streamline policy requirements.

Ultimately, changing this all comes down to public service leadership that is able to recognize the value of having fewer oversight processes, of trusting their people more, and of doing less process-compliance work and more delivery work. (And on breaking things into smaller rather than larger projects!) It depends on leadership that can eliminate institutional barriers, and take on perceived risks related to non-compliance with processes that, if followed, would actually lead to worse outcomes. And it depends on having public servants with the technical and design expertise to know what good service delivery outcomes look like.

Is this blocked in my department: a year in review

Mon, 04 Jan 2021 18:41:39 -0700

Update: This is the 2020 “Is this blocked in my department” year in review. Read the 2021 year in review here.

In my post last week I talked about how access to tools – online services, software, and modern computers – will affect where public servants choose to work. Given a choice of organizations to work at, talented public servants are going to choose the departments and agencies that provide them with the best enabling environment.

Over the past year, public servants across Canada adapted to working through the pandemic. Departments made a lot of progress in improving access to online collaboration tools and other services. But, there’s still a pretty dramatic gap between departments – the working environment for public servants in more restrictive departments is very different from that of their colleagues in more forward-looking departments.

One of the civic tech projects that I’ve maintained for a few years – Is this blocked in my department? – is an effort to track that gap. It’s a crowd-sourced website where public servants can anonymously document the online services and other tools that they can or can’t access within their department. I built it in 2018 as an Ottawa Civic Tech project, and soft-launched it around this time in 2019. Seeing data come in over the past couple years as people make suggestions has really been a highlight.

When the pandemic started, friends and colleagues across the federal public service began using it to figure out which of their counterparts in other departments they could communicate with, with which online services. Below is a quick look back at 2020 based on statistics from Is this blocked in my department. Happy new year, everyone!

Traffic by month

As you can guess, traffic to the website peaked pretty significantly in March, alongside the government’s very rapid shift to working from home. A couple weekends into March, I also built “Should it be blocked in my department?” (based on a tweet from Imraan Bashir) which elaborates a bit on why public servants should be able to access online tools, and how to make the case for them if they’re unavailable.

Traffic to both websites seems to be pretty heavily-driven by social media conversations (on Twitter, LinkedIn, and discussion platforms like GCcollab).

Pageviews by month. Source data

Submissions by month

People can make suggestions to Is this blocked using one of four different Google Forms, depending on what kind of information they’re providing:

Department-wide updates
To suggest changes for more than one service within a specific department
Specific service updates
To quickly suggest changes for an individual service within a department
Add a new service
To suggest a new online service (collaboration tools, messaging platforms, etc.) to add to the dataset
Add a new department
To suggest a federal department or agency to add to the dataset

In 2020, crowd-sourced submissions also peaked in March, but they were actually significantly less frequent than in 2019 (72 entries in 2020 versus 219 entries in 2019, across all four Google Forms).

Crowd-sourced data submissions by month. Source data

In 2020, there weren’t any submissions to the “Add a new department” form.

(It’s worth noting that – because data is anonymously submitted, and because I can’t double-check submissions by, for example, testing them on computers and networks in any department except the one I work for – there isn’t any kind of validation on the crowd-sourced submissions. So far I haven’t seen anything that looks like a deliberate attempt to skew departments’ results, which is nice! I manually update the website’s dataset based on the responses to these forms.)

Submissions by department

Based on the same form data, here’s the top 20 departments by number of crowd-sourced submissions:

Crowd-sourced data submissions by department. Source data

This is based on submissions to both the “Department-wide updates” and “Individual service updates” forms.

Highest- and lowest-scoring departments

Based on the current dataset (at the end of 2020), here’s the top 5 and bottom 5 departments and agencies, based on their overall score. A few new services were added this year (bringing the total from 35 to 38), which brings the highest possible score – open access to every service in the list – from 105 to 114.

Highest- and lowest-scoring departments. Source data

The five highest-scoring departments above (Transport Canada, Atlantic Canada Opportunities Agency, Parks Canada, Department of Justice, and Innovation, Science, and Economic Development Canada) are also the only five departments with a score above 103, which is 90% of the highest possible score.

The scoring system is a bit arbitrary, but it was designed to avoid penalizing departments that were simply missing data when the site first launched. You can sort departments by highest and lowest score on the Is this blocked homepage.

Most- and least-improved departments

One aspect I’ve been really interested to see is which departments improve the most, regardless of their starting point last year. Any progress departments make (opening up even a single service that was previously blocked) is something to celebrate.

The departments below are the five most-improved and five least-improved departments; the number overlaid on each row is the positive or negative score change between the dataset a year ago and now. (Specifically, between the Dec. 31, 2019 update and the most recent update from Dec. 8, 2020.)

Most- and least-improved departments. Source data

This chart excludes departments that didn’t have any data in 2019, and departments that didn’t have any new updates submitted in 2020.

Only two departments “went backwards” (blocking more services in 2020 than in 2019); Library and Archives Canada and the Canadian Nuclear Safety Commission. Despite the Royal Canadian Mounted Police’s low overall score, it improved substantially between 2019 and now.

In each of these cases, whether this represents new firewall rules being introduced or changed, or just new crowd-sourced submissions that make the data more accurately reflect what was already in place, can’t be determined from the crowd-source submissions.

What’s next?

Unlike other past civic tech projects (putting the Internet Red Tape Reduction report online, analyzing Government of Canada contract spending, or building the Meeting Cost Calculator), Is this blocked is a continually-growing and evolving website. In 2021, I hope it keeps on being useful to people as they communicate and collaborate with public servants in other departments, and as they think about which departments they’d want to work at next.

Is this blocked is only as useful as the data that’s on it; if you see any errors or missing entries on the site, please send in your suggestions! You can also see how the website is built by visiting the GitHub repository for the project.

Have a great 2021 and stay safe out there!

Tools that work

Sun, 27 Dec 2020 18:26:31 -0700

Cyd Harrell posted a great Twitter thread last week, that friends of mine will know is definitely my kind of content:

Archived tweet from Cyd Harrell

The article that accompanies that thread – Is innovation really making cities better? – points out that city governments across the US lack even 1990s-era technology. The same is true of governments at every level here in Canada, too. Public servants do critical, life-changing work with the most rudimentary tools.

I don’t think it has to be this way, and my experience in government so far makes me dream of all the good work that could be accomplished if public servants had access to better tools. Making that happen is a big part of my own public service mission.

A blast from the past

My first experience in the federal government was in grad school, as a student working for the team at Global Affairs Canada that rebuilt Travel.gc.ca in 2012. It was a whirlwind, eye-opening experience, with an amazing and inspiring team of colleagues and a project with a frantic timeline. I pulled a few all-nighters at the Pearson Building, we may have broken a few rules, and we launched a website that won government-wide awards. All of those are stories for another day.

What stood out, unsurprisingly in hindsight, was that my work computer was only equipped with a word processor, an email program, and a web browser (Internet Explorer, of course). The word processor was WordPerfect 7, the same version that my family used when I was in elementary school in the late 90s and early 2000s.

This tweet from Rachelle Gervais (a friend at Global Affairs) captures the kind of reaction I had, too:

Welcomed a coop student last week. She is helping us with social media and some graphic design. Felt very embarrassed when IT installed Photoshop 2005 on her PC. She was 6 years old when that version came out. Come on #GC, we need better tools. #GCDigital
— Rachelle Gervais (@Rachelle2pt0) January 17, 2019

I rejoined the federal government in 2016, after spending several years working as a software developer for a tech startup. Once again, the work computer I was assigned (a Surface Pro tablet with a docking station) was a disappointment; the office suite was newer but the choice of software was essentially just as limited as my old Global Affairs desktop. Internet Explorer was, of course, still the only browser option.

My personal MacBook wasn’t anything fancy; a bit beat-up from working and travelling overseas, but it was kitted out to do all kinds of work. Building small websites, designing posters for volunteer groups, doing very rudimentary data science work – it was a well-equipped toolbox. In comparison, the work computer had practically nothing. Using it was like opening a big toolbox and finding it only had a toothpick inside. No one can be expected to do great work on bad equipment.

Better environments for better work

Fortunately, I joined a team that was enthusiastic about shaking things up. Part of my early work was figuring out ways to equip my colleagues with modern equipment – as my UK heroes would say, technology “at least as good as people have at home”. That included MacBooks as our official (unclassified) workplace devices, unfiltered wi-fi, and the ability for team members to install the design and software development software they needed onto their devices by themselves.

As I wrote in a 2018 work blog post,

Developers and designers have a lot of job options, and making the Government of Canada an attractive place to work for digital professionals is a key part of CDS’s mandate. As government departments looking to build better digital services, we all need to be able to offer modern tools in order to successfully recruit talented staff.

None of this was really revolutionary – the UK had been doing all the same things 3 or 4 years earlier – but it was striking how unusual it seemed in the Canadian government. Part of this, looking back, really illustrates Leah Lockhart’s theory that poor-quality government IT trains public servants to have low expectations of what’s possible.

Even the simplest things (by any outside-of-government metric) could seem impossibly futuristic. On one memorable occasion in 2017 or so, I showed a senior public service executive how to use Google Docs for the first time. They were amazed, watching changes to a document on one computer show up in real-time on another computer. (Google Docs publicly launched in 2006; as I joked later, most executives’ kids probably use it on a regular basis in elementary school.)

My desk at the Northlight coworking space (pre-COVID) with the three computers I use on a regular basis: a Chromebook for videoconferencing, MacBook for day-to-day work, and department-issued Surface Pro for protected documents and emails.

Being in an environment where I could help introduce colleagues to better, more productive and user-friendly technology has been really fulfilling. Friends in other parts of the public service have gotten in touch on a regular basis over the past few years, asking for suggestions on how to get better technology into the hands of their own teams and departments. Others have gotten in touch, discouraged, as they ponder leaving the public service because they don’t have the tools they need to do the specialized work they’re experts in. Denied IT request tickets have a much heavier cost than people tend to realize.

Making these changes is hard, given the centralized decision-making for software and devices in most departments’ IT divisions. They’re important changes, not just to be able to recruit design and tech folks into government from outside, but also to make it possible for existing public servants to skill up. Educational programs (like the Canada School of Public Service’s excellent Busrides series) aren’t enough if people don’t have an environment where they can experiment with and learn technology-enabled skills during their day-to-day work, even (and especially!) if they work outside of IT-related divisions.

All of these conversations were the inspiration behind “Is this blocked in my department?”, which helps illustrate which websites and tools are either available or blocked in each federal department. Its pandemic-inspired sibling website, “Should it be blocked in my department?” aims to better equip public servants to have those conversations with their IT groups and CIOs.

The trends are alright

Things are getting better; in many ways the COVID-19 pandemic jump-started a lot of work to bring public servants into the modern era as all of us were suddenly forced to work and collaborate from home.

Even before the pandemic, some really good work had been happening to open the door to more modern tools for public servants. TBS’s 2018 IT Policy Implementation Notice instructing departmental CIOs that they shouldn’t block access to online services and collaboration tools was a major turning point (thanks to really excellent work from Alex, Imraan, Po, Scott, and many others).

Unblocking websites is really just the beginning, though. Being able to easily pay for team subscriptions to online tools, being able to install open source data science tools locally, and being able to use modern tools with protected information are all as-of-yet unsolved issues.

The bigger issue, on top of this, is the wildly uneven distribution of access to tools between departments. Comparing the highest- to lowest-scoring departments on Is this blocked? is illuminating. Competition for talent with design, technology, and data science skills is only going to get more intense in the post-pandemic period, not just between the private and public sector but between departments as working from home and distributed across the country becomes a more normalized option.

On top of a sense of mission, good team culture, and relevant work, access to an effective working environment is a clear reason to choose one department over another. The departments with the best tools are going to get all the best people. Are departmental CIOs and heads of HR talking about this?

A lot of conversations about technology in government involve flashy, sales-pitch-driven futuristic ideas. In my mind, those aren’t convincing, and they’re not even that interesting. To me, the most interesting work in the next few years will be getting everyday technology – used in every other industry – into the hands of public servants, and seeing what they can accomplish with it.

As Cyd Harrell writes,

Every city has pockets of problem solvers who quietly invent smart improvements using the tools they have, without the shine that a formal innovation group or outside consultant provides. It is the people programming workarounds in Excel spreadsheets or running lunchtime learning groups on mobile web design that are pushing cities forward. They may think of themselves as problem solvers rather than innovators, but the root of most useful inventions is properly defining the problem to be solved. When these government staffers are given resources and attention, they can move mountains.

All of that is true for provincial and national governments, too. Let’s make it happen.

Cyd Harrell’s book – A Civic Technologist’s Practice Guide – is a gem. Definitely worth a read!

“Government is actually a big tech company, they just don’t know it yet.”

Mon, 16 Nov 2020 20:50:15 -0700

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:

“Government is actually a big tech company, they just don’t know it yet.” @acroll at @fwd50conf #fwd50 pic.twitter.com/X8QgGqZVrI
— Sean Boots (@sboots) November 4, 2020

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.

What’s missing?

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’.

“Working in the open” firsts for COVID Alert

Fri, 30 Oct 2020 15:27:32 -0700

A few months ago I wrote about how busy the summer ended up being. Working on COVID Alert has definitely been a career highlight, in a lot of unexpected ways in an unexpected year. As of this week more than 4.9 million people have downloaded the app, and 2,900 people have used it to alert people close to them about their COVID exposure. For everyone that has worked on COVID Alert, it’s humbling and daunting to be part of something at this scale.

In a lot of ways, COVID Alert represents some unprecedented milestones in Canadian federal government IT:

It’s the first large-scale, public-facing mobile app launched by the Government of Canada that is open-source, to my knowledge. (A lot of that is credit to the volunteer team that built COVID Shield, the proof-of-concept app that COVID Alert is based on!)
It was built in 45 days, between the day that CDS’s product team was formed and the public launch of the app.
It had a pre-launch public beta where thousands of people helped test the app and provided feedback.
And, it involved some very close collaboration between the federal government and provincial healthcare and technology teams to deliver one-time keys to COVID-positive patients.

Beyond all of that, there were some extra geeky “firsts” that I was really thrilled to see, as someone working at the intersection of tech and policy. Each of these are different (really neat) examples of working in the open.

A privacy assessment published in the open

Protecting Canadians’ privacy was one of the foremost goals of the entire project. If Canadians didn’t trust COVID Alert and didn’t adopt it in sufficient numbers, it wouldn’t have any public health impact. Ensuring users’ privacy was one of the main benefits of the underlying Google/Apple exposure notification framework, and building the app as an open source project gave privacy, security, and technology experts the ability to dig into the code and point out any privacy concerns.

One of the highlights of my day-to-day work on COVID Alert was working with Health Canada’s privacy division on the COVID Alert Privacy Assessment and the wide range of other privacy documentation that went into the design and oversight of the overall system. Health Canada’s privacy team is second to none. Their thoughtful feedback, questions, and deep understanding of Canada’s federal privacy environment made working on a complicated topic a really wonderful experience.

The privacy assessment was published both on GitHub and on Canada.ca the day the app launched. As far as I know, it’s the only full privacy assessment for an app or online service that the federal government has ever proactively published. (If you know of any others, let me know!)

A public Accessibility Statement

Accessibility statements are an emerging best practice for organizations and websites, where they detail how they’re meeting accessibility needs, what issues are still outstanding, and provide ways for people to provide feedback or raise issues. A number of European countries now require accessibility statements on public sector websites.

COVID Alert’s Accessibility Statement, published on Canada.ca, is the federal government’s first-ever accessibility statement for a mobile app. (It’s the second-ever published accessibility statement, after a 2018 accessibility statement for an ESDC consultation tool run by a third-party vendor). COVID Alert’s Accessibility Statement is accompanied by an accessibility report, published on GitHub, that details ongoing issues and work in progress.

My colleague Julianna – a fearless advocate both inside and outside CDS for accessibility and inclusive design – championed both of these in really thoughtful ways as COVID Alert came together.

A Vulnerability Disclosure Policy for cybersecurity researchers

Last but not least! Vulnerability disclosure policies (VDPs) are quickly becoming a norm for both tech companies and government institutions. They let cybersecurity researchers know what things they can and can’t do while poking at websites or services to make sure they’re secure, and how to notify the organization’s security teams if they find something broken.

Vulnerability disclosure policies are an important signal to cybersecurity researchers that a team or organization takes cybersecurity seriously. That if they notice something broken or unsecured, that they can report it to the organization in an obvious way – without worrying that they’ll be accused of hacking or illegal activity when they’re trying to help. Both the UK government and the US government’s cybersecurity agencies have been making vulnerability disclosure policies into a standard process over the past few years.

COVID Alert’s Vulnerability Disclosure Policy is the first VDP ever published by the Government of Canada. There’s still work ongoing to make this a regular part of launching and operating government websites and services – I’m really excited to see where it goes.

Onwards and upwards

I’m really grateful to have been able to work on COVID Alert, and in total awe of my software development, design research, design, and product management colleagues that made it a reality. Working with the talented team at Health Canada has also been a huge highlight. (And, not least, with Sam and Lucas and Michael and John and the whole CDS policy team! Y’all are the very best.)

People’s reactions to the app have been really really positive, and I hope we can maintain that level of public trust as the app continues to improve. If you want to learn more about how it came together, check out the official CDS blog for an ongoing series of posts on how COVID Alert was built.

Interfaces, data, and math

Mon, 19 Oct 2020 22:13:50 -0700

Back in January, I wrote a post about bridging the technology-policy gap. By and large, no one is teaching public policy students and practitioners how to be technology-savvy, or teaching computer scientists and IT specialists how to be government-savvy.

One of the consequences of this is that it’s hard to have conversations about public policy and technology where people on both sides of the discussion understand each other. Computer software – the programming code that makes software programs and systems work – often seems impossibly complicated and intimidating to people outside the tech industry. That’s particularly true in government settings, with a range of unfortunate consequences – from bad software decision-making by public service executives to marketing terms designed to give a sense of security that products don’t live up to.

Computer software seems complicated and unknowable, and that’s part of the problem. (Government IT vendors are, perhaps, motivated to keep it that way, which is a different problem for another day.) It doesn’t help that there are so many kinds of software: from applications installed on your computer like Microsoft Word, to interactive websites like Twitter or Wikipedia, to specialized systems like the software running your car stereo or your Amazon Echo. That’s not even counting custom software written to analyze scientific data, or to run multiplayer computer games, or to power satellites and Mars rovers. The huge diversity of kinds of computer software, and the equally diverse set of programming languages, frameworks, libraries, and systems used to create it, can make it a challenging field to tiptoe into.

Before joining the Canadian government, I worked as a software developer for a tech startup (Viamo) that builds communication and research tools for use in developing countries. Our flagship product was a survey platform that sent text message or phone surveys to people’s mobile phones. The startup was small enough that we all worked on practically every part of the products we built.

Even when programming is your day job, it’s sometimes hard to know where to begin when you’re tasked with building a new feature or part of a software product. For me, the easiest way to get started with anything I was programming was to break it down into three categories, and to draw or write everything out on paper before I started coding.

My three categories (as you’ve probably guessed from the title of this post) are interfaces, data, and math. Any piece of computer software probably has all three of them. By breaking something down into those three categories, it becomes a bit easier to think about how it works. Or, if it’s not working properly, it makes it easier to understand why.

These three categories aren’t any kind of official terminology; people who teach computer science will probably tell me I’m missing some key details, and they’ll be right! (I’m also using words like computer software, applications, and programs pretty interchangeably.) But when my day job was computer programming, these categories helped me think and work more effectively. Now that my day job is public policy, maybe these categories will be useful to you as a public servant or political leader, as a way to understand technology decisions happening around you.

This is a long post; don’t feel any pressure to read it all at once! Here’s a quick shortcut to each section:

Interfaces
Data
Math

Interfaces

You’re reading this on a computer or smartphone, which means you’re already dealing with interfaces every day. An interface (in my own definition here) is a way that you as a person interact with computer software. It could be the buttons on your phone’s home screen, that you tap to open your web browser. It could be an online form, like on an e-commerce website, where you put in your shipping address and credit card number then click “Place order”. It could be the “Like” and “Share” buttons on social media websites, encouraging you to react to some kind of online content.

Interfaces have changed a lot over time, and continue to change. Back in earlier decades of computing, the interface for a computer was probably punchcards and wiring. Early desktop computers had green and black text prompts, as the only way to interact with the software on the computer. Desktop operating systems with mice and Start buttons were all steps in making interfaces that were easier for everyday people to use.

The last decade or two has seen interfaces – how they’re designed, and how easy they are for people to use – become the defining element on which many technology companies stake their reputation. Think of the iPod’s touch wheel, or the first touchscreen iPhone, or the Facebook news feed, or the list of recommended products at the bottom of any Amazon webpage. All of these interfaces became ways that companies distinguished themselves from their competitors, or kept their customers and users coming back again and again.

As a software developer, anytime I was working on a new feature, the interface was what I thought about first: What kinds of buttons or text fields would I need? What order would they be in? How would people get to this new feature from other, existing parts of our software product? If they had to, how would they get back again? Could they figure out those steps on their own? If they made a mistake, how easily could they undo it?

What does an interface look like?

Here’s an example interface, from the first civic tech project I built – the Meeting Cost Calculator. Nothing is ever perfect on the first try, and I’m sure I drew five or six different sketches of the interface before starting to write it in code. You can see the buttons, the drop-down menu, the timer, and the cost display that make up the interface:

(In 2019, I very slightly redesigned the calculator interface again; you can see what it looks like nowadays here.)

Designing interfaces that are easy to understand and use is a whole field of its own – known sometimes as human-computer interaction or product design – and it involves art and psychology as much as it does programming skill. Done well – like the iPod click wheel – a good interface is quietly wonderful to use. Done poorly – like, well, most government software – bad interfaces slow people down, frustrate them, or stop them in their tracks.

Data

While I drew the interface for whatever I was about to program, I thought about the data I would need to make the new feature work. Buttons or text fields (or other online form pieces like radio buttons or checkboxes) are ways to ask people for data, so that your computer software can do what they want it to do. If people wanted to send a test survey to themselves, at my old job, for example, the software would need to know what mobile phone number to send it to. If they wanted to send it out at a particular time of day, the software would need to ask them what time.

Data is a shorthand word for “structured information”. Structured in the sense that the information is labelled and categorized in a way that computer software can understand it. This blog post – several hundred words of not-very-organized text – is unstructured information. A spreadsheet with really consistent columns and cells is structured information: without too much effort, a computer program can do something useful with the information in each cell. Databases are the exact same idea, but with even more pre-planned structure.

It can be hard to understand at first, but when you’re looking at a piece of software, almost anything that isn’t a consistent part of the interface is data. Imagine opening a spreadsheet in Excel: all the buttons and menus along the top are the interface; the information that you type into all the cells is data. Or, imagine a social media website like Twitter: the text box and the “Post Tweet” button at the top are the interface; all the tweets as you scroll down below are data, submitted in that case by other Twitter users. More accurately, each tweet has a bunch of kinds of data all associated together: the text of the tweet, what time it was posted, who posted it, the profile image for that person, the number of people that retweeted it, and so on.

Examples of data

When you’re designing a piece of computer software, you have to think carefully about what data you’ll need for it to work. In the Meeting Cost Calculator, going with the example above, publicly-available public servant salary data was what made it possible to build. Here’s a sketch of the data that went into building the calculator:

You can see what that data looks like in practice here, on GitHub. (The data is in a CSV format file, which is a bare-bones style of spreadsheet that can be read and understood by computer software more easily than, say, an Excel file.)

Good or bad data is often what makes the difference between software being useful or not. Some data is easy to come by automatically. When you’re posting a tweet, you don’t need to manually enter what time it was posted or what your username is; the Twitter website can easily tell what time “right now” is, and can tell what your username is because you’ve already had to log in. In other settings, data can be a real challenge. Think of scientists analyzing weather or ice melt in the Arctic – before their software can run a useful analysis, they might need several years of accumulated data from sensors physically installed in difficult conditions.

This is just scratching the surface; in the past decade, as social media use has accelerated, questions about how people’s personal data is used by social media platforms have become critical ethical and legal topics. Specialized professions (data scientists, for example) have emerged as companies and organizations try to make sense of larger and larger collections of data. These are all discussions for other posts, too. The point here is that data, no matter what kind, is almost always an essential ingredient for software systems to work properly.

Math

“Math” is not exactly the right word for this; the shorthand I’m going for here is “things that computers do on their own”. These things can be in response to some kind of interface activity – a person clicking the “Submit” button, for example. Or they can be automated in some way – a scheduled activity that a piece of software does at a certain time of day, or after some accumulated amount of data is reached.

When I worked as a software developer, this was the last step I did on paper before I started coding: listing all of the functions I would need to code to make my new feature work. “Functions” are small sections of computer code that do a specific task, usually with some kind of input as the ingredient that determines what the section of code does.

Math, or baking, or programming

You can think of a function kind of like a baking or cooking recipe: this function takes in flour and yeast, and spits out a pizza crust. This next function takes in a pizza crust, some tomato sauce, and some pepperoni, and spits out a finished pizza. Each function has a predefined list of what inputs it will happily expect, and it consistently spits out the same results when given the same input ingredients. You can put in twice as much flour and yeast, and you might get a pizza crust twice as big. But if you only put in flour, without yeast, the function will probably complain and do nothing at all.

The theme here is that, under similar conditions and with the same input ingredients, software functions will do the same thing consistently. As a programmer, you write functions to do all the different things that you want your software to do. Generally speaking, a function is a verb – it does something. For example:

If the user clicks the “Submit” button below an online form, check if they’ve typed the right things in all the text fields (with a function named something like, “check form field data”).
If it turns out that everything looks good, save the data they’ve provided to the database (with a function named something like, “save data to database”).

Thinking back to my old job, we had pre-scheduled surveys to send out. We had a function that, once every minute, checks for pre-scheduled surveys that haven’t been sent out yet (“check for unsent surveys”). If the scheduled time for a given survey is in the future, don’t do anything yet. If the scheduled time is in the past, then send out the survey! (You guessed it: with a function named something like, “send out pre-scheduled survey”, and with the main ingredient being the unique ID number for that particular survey.)

Math that powers …a calculator 🧐

For the Meeting Cost Calculator, once I had the interface design sketched out and the data ready, the last step was writing the functions that make it all work. Most of these functions were related to the interface (what to do when someone clicks on a button, for example); the other main one was actually tallying up the cost of the meeting. Once per second, if the timer was running, the software would check how many “people” you had added to the meeting, what position and annual salary they were, then do some actual math to figure out the cost of the meeting “per second”. Then, it multiplied that by the amount of time that had gone by on the timer and displayed the total cost. Here’s what the calculator’s functions looked like:

That’s pretty much all that programming is. It’s not rocket science; it’s thinking of all the things you could possibly want your software to do, and writing small functions to do each of those things, one at a time.

I call this category “math” (instead of a more accurate term like “logic” or “functions” or, well, “programming”) because ultimately it’s not that different from high school math. Sine and cosine and other bits of trigonomic fun aren’t that different from the functions in any piece of software: you put some kind of ingredient or input in, and you get some kind of consistent output out. (If you didn’t enjoy trigonometry in high school – and who did! – then Excel spreadsheets are another good example: functions like SUM and AVERAGE are just like functions in more formal programming!) Sometimes you’re adding or subtracting or multiplying numbers; sometimes you’re using logical steps like “if this happens, do this; otherwise, do that.” The ideas behind it are all pretty much the same.

Complicated pieces of software just have lots and lots of functions, or functions that are each really big and are doing too many things at once. If you’re a good programmer, you’ll find ways to make things simpler instead of more complicated.

Abstractions make our world

Once you start thinking of software in terms of interfaces, data, and math, it can help you think differently about the software products you use everyday:

When you finish a Netflix show and it goes right into the next episode, that’s a clever bit of interface design meant to keep you watching.
When Facebook generates advertisements that seem creepily targeted at you, it’s because over several years of you liking and sharing posts, you were generating data that Facebook can use to guess your political and consumer preferences.
When you open Twitter and it shows a set of “Tweets you might like”, it’s because, in the time between when you last opened it, Twitter did some math (maybe something like, “find all the tweets that at least 20 people you follow retweeted but that you haven’t seen yet”).

These three categories aren’t a magic way to instantly become a software developer. But, as a software developer, they helped me make sense of what I was building. And no matter your field of work, they’re an interesting way to think about software, and to decide what you like or dislike about it, or what, in your view, works well or poorly about it.

You made it! Thanks for reading all this. If you’re looking to dive deeper into computer software, Paul Ford’s “What is code” is a fascinating (and, er, fascinatingly illustrated) long-read. Chris Allison’s “Guide to Digital” video series is also really excellent.

In government environments, technology often seems especially complicated and unknowable. Making computer software simpler and easier to understand – through abstractions like interfaces, data, and math – can help public servants make better technology decisions. In future posts, I’ll look at how these three categories can help you ask better questions, and how you can analyze a particular piece of government software based on each category. The more public servants we have that are equipped to ask good questions about technology, the better.

“It’s more an approval of an approach” for the win

Tue, 13 Oct 2020 19:46:23 -0400

A few weeks ago, there was a great profile in Maclean’s of the person behind the CAFinUS Twitter account. CAFinUS is the official account for the Canadian Armed Forces working in the United States, and the account is run by Capt. Kirk Sullivan, based at the Canadian embassy in Washington DC.

The entire article is worth a read, especially given how much of an anomaly the CAFinUS account is in comparison to practically any other Government of Canada social media account. It’s charming, it’s thoughtful, it advocates for inclusion and anti-racism, and through it all it comes across as very authentic and human.

Most government social media accounts, as anyone familiar with them will know, tend to be cautious, sterile, and denatured by the layers of hierarchy that tweets and posts go through before being published. Lengthy communications approval processes take the human-ness out of social media posts, and make it hard for them to get out the door in time to be part of whichever fast-paced conversation is happening at a given moment.

The article shines a light on this in a way that makes me all that more impressed that the account exists:

The account doesn’t shy away from current events.“It takes a point of view on some of the issues that are so important right now, like Black Lives Matter,” writes Scott Simmie, a communications specialist, in an email. “Government historically would not take a position on something like this unless it had gone through 47 committees. The honesty and spontaneity really impresses me.”

In June, Sullivan tweeted: “Do / not / think it’s over . . . do / not / think it’s someone else’s problem / Racism is our problem / They are Us.” When a woman responded, saying: “Systemic racism is a myth,” he wrote: “Dear Katherine: We hope all is well with you and yours during these uncertain and trying times. Please know that racism is very real. Please know that it’s unacceptable . . . Please understand that it hurts us, Yours, @CAFinUS.”

Sullivan doesn’t need approval for his tweets (“It’s more an approval of an approach,” he says), noting that the account does not make announcements but rather echoes existing military policy, reflects the CAF’s code of ethics and takes its cues from statements already made by leadership.

That line near the end – “It’s more an approval of an approach” – is brilliant and astonishingly rare in the government communications field. It’s exactly the enabling, not blocking approach that I think reflects public service leadership at its very best.

Capt. Sullivan’s writing and social media style is brilliant, without question. But there’s really two heroes here, and the second isn’t mentioned in the Maclean’s article. The second hero is, whoever Capt. Sullivan reports to (in the Canadian Armed Forces hierarchy). That person, maybe some public affairs manager in the CAF, did three things that I think are really spectacular:

Approved the process for Capt. Sullivan to tweet, autonomously and without needing specific approvals for each post (which is wonderful and basically unheard of in Government of Canada communications divisions)
Let Capt. Sullivan do a media interview with a major publication like Maclean’s
Didn’t try to take public credit for Capt. Sullivan’s work or insert themselves in the story somehow

Any of you that have worked in or with government communication folks (or in any large institutional hierarchy) will know how rare all three of those things are. The folks in the hierarchy above Capt. Sullivan demonstrated, implicitly, a level of humility and trust that isn’t always found in government management layers. To Capt. Sullivan, and to your boss, and to anyone else above them that enabled this to happen, you’re all doing amazing work. Keep going.

Public service tech tip: Paste without fonts and formatting

Fri, 18 Sep 2020 21:46:43 -0700

We’ve all been there, fellow public servants. You’re copying and pasting something from some obligatory government website into some obligatory government Word document. You hit “Paste”, and your Microsoft Word freezes up for a painful few seconds, then proceeds to turn the formatting of the entire remainder of your Word document into a strange and bewildering hybrid of the fonts and colours of the website you just pasted.

It’s been this way for decades. The struggle is real:

does anyone ever want to paste the formatting? why is this a default? #crankypants
— Cyd Harrell (@cydharrell) August 30, 2017

In my case, I’m a little bit paranoid about misspelling people’s names when I reply to emails, so I practically always copy and paste people’s names into the introduction of my email. Outlook is more than happy to bring along the formatting, leading to situations like this:

Hello (in navy blue, Times New Roman text) Éloïse,
Thanks so much for your quick reply…

Guilty as charged! Fortunately, there’s an easy way to prevent this from happening, by changing the application settings in Microsoft Outlook and Microsoft Word.

(If you’re using a Mac, you can just use the “Paste and Match Style” keyboard shortcut: Command-Option-Shift-V, to just paste plain text. Not exactly ergonomic, but it works beautifully. I’ve probably pasted text with formatting twice since getting a Mac; Command-Option-Shift-V is my perpetual go-to keyboard shortcut. You can even make this the default at the operating system level. Macs are great.)

Changing the default paste options in Microsoft Word

Let’s start with Microsoft Word, which is slightly simpler than Outlook.

In Microsoft Word, click “File”, then “Options”. In the “Word Options” window that comes up, click on “Advanced” in the sidebar on the left.

Scroll down to the “Cut, copy, and paste” section. For each of the pasting options, change the dropdown menu to “Keep Text Only”.

When you’re done, the series of dropdown menus should look like this:

Then, click the “OK” button at the bottom to close the Word Options window and save the changes you made.

After doing that, close Word completely (closing any documents you have open) and then re-open it. Otherwise, if Word crashes before you properly close it, you’ll lose the changes to the settings you just made. Yes, that was a slightly painful discovery.

Changing the default paste options in Microsoft Outlook

You can follow similar steps in Microsoft Outlook. (Unfortunately, you can’t change the default paste options in Microsoft Excel or Microsoft Powerpoint.)

In Microsoft Outlook, open up the settings window by clicking “File” then “Options”.

Next, click “Editor Options”, up on the top right:

Then, click “Advanced” in the sidebar on the left, and scroll down to “Cut, copy, and paste”. When you’ve changed each of the pasting options, the series of dropdown menus should look like this:

Then, click “OK” to save and close the Editor Options window, and click “OK” again to save and close the Outlook Options window. Just like Microsoft Word, it’s a good idea to then fully close and re-open Outlook to make sure your changes stick.

Pasting with formatting, when you need to

In very rare cases, sometimes you actually do want to bring some existing formatting along when you paste something. (In my case, this is usually when I’m copying something from a document I wrote, where I can trust the original formatting!) You can still easily do that, as a one-off action, without having to change the default paste options back again.

To paste with formatting, place your cursor in the document where you want to paste something, and then click the little downwards arrow below the Paste icon on the Home tab. Here’s what it looks like in Microsoft Word:

There are a few options here; my preferred one is usually “Merge Formatting”, which brings along bold, italic, hyperlinks, and lists, without most other formatting cruft. “Use Destination Theme” has similar effects. Choosing “Keep Source Formatting” includes all the original formatting – identical to the typical paste functionality before changing the default options.

And, here’s what the same functionality looks like in Outlook (for example, when composing or replying to an email):

Other quick Microsoft Office improvements

Microsoft Word and Outlook are software programs that, for better or worse, we spend an astonishing amount of time in as public servants. Changing the default settings to work more effectively is a great way to save time and make your work slightly more enjoyable, or at least slightly less frustrating.

A few other steps you can take to improve your Microsoft Office experience include:

The options screens for these programs can feel overwhelming, but if there’s a setting you want to change, there’s a good chance someone else has figured it out beforehand and written a how-to guide online. Don’t fight your tools! Change them to work better for you.

“Fake COTS” and the one-day rule

Wed, 16 Sep 2020 18:38:13 -0700

One of the long-held norms of government IT is the perceived benefit of COTS solutions: “commercial, off the shelf” software. In government environments where IT isn’t seen as a core competency, and that by and large are short on technical expertise, being able to buy ready-to-go software products to meet government IT needs is an appealing approach.

COTS software has a number of benefits, in a government setting:

It’s potentially ready to use right away
There are existing customers, so you’re not dealing with the bugs or issues that come with the first version of a product
You’re paying for a commercial product (software licenses, for example), rather than hiring staff or contractors to build something (which introduces a range of complex HR or project management steps)

Various Government of Canada guides over the years speak highly of COTS approaches: “Acquire commercially available items unless custom-made items are essential to operational requirements” and defining COTS as “commercially available products that can be purchased and integrated with little or no customization, thus facilitating customer infrastructure expansion and reducing cost.” Some government standards written in the early 2010s require specific COTS products for particular business processes (PeopleSoft and OpenText Content Server are two examples of this).

The appeal of COTS products is essentially: if you have the same need as someone else, and a widely-used commercial product exists, why not use it? That way you can spend your time and resources focusing on the unique aspects of what you do, rather than reinventing the wheel.

Seems rosy so far, right? Here’s the catch…

A car versus a box of car parts

Almost all software solutions marketed at government institutions are described as COTS products. Calling your product a COTS solution is a key part of government IT sales and marketing. What happens as a result is that a lot of COTS-branded software products don’t live up to that “off the shelf” label:

Archived tweet from Cats and Procurement

Any software product needs setting up, configuring, or tweaking to make it useful for a given goal. But the amount of customization required to make a COTS solution useful is what distinguishes genuinely-useful COTS software from “fake COTS”, that’s off-the-shelf in name only.

In 18F’s (fantastic) De-Risking Guide, the team writes:

Government agencies often describe challenges and the expense of customized commercial off-the-shelf (COTS) software. These efforts often start out as a pure COTS implementation, until agencies realize that they need to customize the software to meet their needs.

In these situations, the agency pays industry to develop custom software that the agency may end up locked into, especially if, as often happens, the agency did not secure sufficient data rights in its contract.

Over time, these systems become more difficult to maintain, as new features and customizations are added to the base COTS product, each of which bring it further away from actually being COTS. 18F technologists often refer to these products as “unrecognizably modified off-the-shelf” software, or “UMOTS.”

Modifying COTS software eliminates most of the benefits of using COTS. Customized COTS is often modified to the point where routine software updates can no longer be applied. At this point, the software requires expensive custom updates for the duration of the software’s life. It also locks the agency into a long-term (and often sole-source) relationship with that contractor.

How do you tell how much customization is too much? This is a frequent challenge for government organizations without the in-house technical expertise to be able to see through the marketing claims vendors make about their products.

Some COTS products are genuinely solutions you can adopt and use quickly. Other COTS-branded products are the equivalent of ordering a new car, and instead getting a large box of car parts. In theory, you got a car, but it’ll take years and a lot of specialized expertise before you can use it. (Without enough specialized expertise on hand, you might never end up with a car at all.) You might’ve even received the parts to build a truck or a minivan instead, if you wanted to, but if you were hoping to drive it tomorrow, you’re out of luck.

The one-day rule

How do you tell the difference between genuine and fake COTS? When every piece of software needs to be configured at least a little bit, how much customization is too much?

Here’s my personal rule of thumb:

If you can get a software solution to successfully meet your needs in one day, it’s a real COTS product.

Yes: one normal work day, with one or two people and a reasonable but not extravagant level of technical expertise. If it takes longer than that, it’s fake COTS.

There’s two side cases that I’ll allow:

You get an extra day, if you need it, to figure out how to deploy the software solution across a set of managed devices (e.g. corporate software deployments).
And, you get an additional extra day to figure out how to bulk import data that’s been exported from whichever solution you were using before. (Time spent getting the data out of the previous system doesn’t count, since it’s not the new system’s fault!)

If both of those apply, you get three days and you can still call it a genuine COTS solution.

Examples

Let’s see what that looks like in practice! You can probably see this coming – most online software-as-a-service products do this really well (one of the reasons why the Canadian government’s Cloud Adoption Strategy prioritizes them), as do software products aimed at regular, non-government consumers. Government-oriented COTS products largely all fail to live up to the one-day rule.

How long it takes to purchase and get a software product working

Under one day (all times are anecdotal, your measures may vary):

Microsoft VS Code: 10 minutes
Trello: 15 minutes
Slack for a small or medium team: 15-30 minutes
GitHub for a small team: 20 minutes
SurveyMonkey survey: 20-40 minutes
DigitalOcean instance: 30 minutes
Amazon RDS database: 30-45 minutes
Google G Suite for organizations: 1 hour (plus an available domain name)
Adobe Creative Cloud: 1-2 hours depending on internet bandwidth (for individual use; government purchases via standing offer are 3-6 months)

Over one day:

Oracle PeopleSoft: 4-6 years
OpenText Content Server (GCdocs): 2-4 years
Microsoft Dynamics CRM: 1-2 years
Adobe Experience Manager: 1-3 years

You can see examples of various implementation projects using these solutions and their timeframes in the list of large Government of Canada IT projects, by searching for them in the search field for a given year’s data.

All of these government-oriented products, it’s safe to say, are boxes of car parts: time-consuming assembly required. If you have teams of developers and several years to turn them into the product you actually want, go for it. If you want something that’s ready to use, right off the shelf, they’re not good choices.

The simplicity is the point

If you’re a grizzled government IT veteran, reading this you may immediately think: how naïve, how simplistic; government needs are just inherently complex and it’s unavoidable for projects with complex requirements to take this long.

To which I would say, that’s fine (except it isn’t). The point here is that, if “off the shelf”-branded solutions take several years to implement, which in government they consistently do, then the “off the shelf” label means very little.

The one notable caveat in the examples above is that most of the “under one day” products above are tools for individuals, while the “over one day” products are tools for business processes. Business processes (like delivering various kinds of government services) aren’t things that you can figure out in a day; they take research and thoughtful design and iterating over time. That’s fine! But that’s also partly the point: no “off the shelf”-labelled product will single-handedly make a complex business process work, which is why the COTS label in a government IT context feels so disingenuous.

If you’re designing a government service over the course of several months, starting with a COTS-branded product (particularly those marketed at government, not consumers or regular companies) instead of something built in-house isn’t likely to save much time anyway. It could just as likely slow implementation teams down by having to work with a “one size all fits nothing well” product as a starting point, rather than open-source components that are free, much simpler, and easier to work with. (And, if your data, business rules, or requirements are complex enough that your IT project really will take several years to implement, it’s probably doomed to failure from the start.)

COTS is a marketing term, not a technical term. It’s a branding term that says: you can use this right away. The one-day rule is a simple way to call that bluff, across a wide range of types of software products. If you want to buy a car, and drive it this week, don’t buy a box of car parts.

I love bicycling and so using this car-buying metaphor feels weird – but after moving to Whitehorse we leased a Subaru Crosstrek and, turns out, it’s …really really great.

Make things open source, it makes things better

Thu, 20 Aug 2020 16:50:25 -0700

One of GDS’s early design principles was “Make things open: it makes things better.” I printed off a poster of it that I would stick on the wall near my desk, back when our then-tiny team moved desks every couple months.

Making things open follows a long tradition of open government advocacy, open science movements, and public sector transparency initiatives around the world (Prof. Tracey Lauriault has given fascinating presentations on this). But in the government technology field, GDS changed the game by making things open a foundational starting point for how they worked. From GDS’s blog and social media updates to the software they published in the open on GitHub, they set the bar that every digital services team following in their footsteps has tried to live up to.

The “open source” part of open

When it comes to software being developed by or for government institutions, making things open source is such an obvious choice that it’s hard to believe, until recently, that it was treated with a lot of doubt and suspicion: “Could anyone just edit your code?” “What if people find security flaws?” “Who needs to approve publishing this?” Governments’ reluctance to either use open source software, or publish software they created or paid to create, became an increasingly stark contrast with the enthusiastic adoption of open source by almost every major technology company.

Even today, open source software is seen as a bit of a niche in the federal government IT landscape. Back in February, my colleague Josh and I published a blog post that attempted to dispel some open source in government myths:

Building software in the open brings out the best in people’s work. It helps us learn from each other, and makes it easy for people to continue contributing to useful software even as they move from one part of government to another. Open source saves time and money, by making software easier to reuse and adapt.

Making open source the norm for government teams building or procuring software is something I’d really like to see happen. Teams across the federal government are advocating for this, to increase the speed, quality, and interoperability of government software. Other countries (like France and the UK) have blanket policies requiring that custom software code paid for by government is published as open source. It’s something Canada should do too.

When public trust matters most

A few weeks ago, our team launched COVID Alert, a Canada-wide exposure notification app. Public trust in the app – that it respects people’s privacy, works reliably, and doesn’t do things they don’t expect – was (and is) a critical factor to the app succeeding or not.

Making the app clear and easy to understand (through content design and continuous design research) was an essential ingredient for this. Making it open source was the other essential ingredient (not least because the app was based on COVID Shield, an already open-source project!) Being able to see the software code inside and out, at least for security and privacy experts, was “table stakes” for public trust. Asking people to trust an app whose code wasn’t open source, for a subject as sensitive as being exposed to COVID or not, seems like a complete non-starter. Other countries with similar exposure notification apps – Ireland, Italy, and Germany – have all made their apps open source as well.

The apps and services that underpin government programs should practically always be open source. Public trust in things like the EI system, filing taxes, or as a public servant, getting paid, would be higher if people could see the inner workings and understand that software is working as it should.

Old and outdated software is the one area where making things open source can be a challenge. Going through thousands of lines of legacy code, looking for glitches or security issues, isn’t an easy feat. But for new code – even code that talks to legacy systems that aren’t open source – making it open source should be the default, in practically every public service team. Whether it’s built in-house or by an external vendor, if you want people to trust your code, make it open source.

Don’t pay twice

Waldo Jaquith, a government technologist in the United States, has a fantastic recent post on why government software should be open source:

When it comes to important state infrastructure, top government software vendors use a double-dip business model. First, they charge us to build the software, then they charge us to use it. Nobody would pay to build a house and then pay to rent that house, so we shouldn’t do this with important state infrastructure. Vendors often claim that states are merely licensing software they’ve already built (“Commercial Off-The-Shelf,” aka “COTS”). This is often untrue. Instead, the software they’ve already built is custom for another state and will require large changes to work in a new state. These changes will be done at our collective expense, but with the resulting software owned by the vendor. In this scenario, we’re paying for a house to be rehabbed before we start to pay rent on it. This is absurd.

Open source code reduces vendor lock-in, improves the quality and interoperability of software, and increases public trust. What’s not to love?

Hat-tip to Lena Trudeau, both for introducing me to “table stakes” as a catchy expression and for fearlessly advocating for open source in government!

A busy couple months

Wed, 29 Jul 2020 15:10:44 -0700

Since the start of the year, one of my goals was to write a new blog post here every few weeks. Having a regular frequency in mind helped overcome a bit of the self-doubt that often holds me back from writing – the regular cadence becomes its own source of encouragement or motivation.

My good friend Lucas’s newsletter – published every weekend – was a big inspiration for starting this blog. To publish something, every week, and not worry too much about it being good or bad or perfect. (The newsletter’s title, “Hit or Miss” helps capture that, too.) Another inspiration was David Eaves’ blog, with the subtitle, “if writing is a muscle, this is my gym.” Getting back into a regular, imperfect blogging routine is something I’m really looking forward to.

Although the blog here has been quiet, it turns out there’s been a lot of (metaphorical) exercise over the past couple months! For Lucas and I both, our day job has been the busiest it’s ever been. Working on a product with more scale and visibility than our team’s past work has been exciting and daunting all at once.

On that, and other things, there’ll be more to write in the weeks ahead. Hopefully even some semblance of a regular blogging cadence! In the meantime, I hope all of you are doing well and having a good summer despite the pandemic.

A short introduction to building digital services in the Canadian government

Tue, 16 Jun 2020 16:30:31 -0700

Back in March, some friends from the Ottawa civic tech community reached out. The pandemic was ramping up, and they were interested in volunteering their developer skills to help government departments respond to the crisis. Building digital services and IT systems in a government environment is complicated. The federal government in particular has a lot of rules to navigate, and it’s easy for these to overwhelm people and (at the least) siphon their time away from designing and building user-friendly software.

Here’s what I wrote, on a Sunday evening – none of this constitutes formal policy advice, but it was meant to give an introduction to which rules really do deserve a lot of attention, and potential landmines to avoid. (Note that some of the links below were added to this blog post after the fact, for extra context or further reading.)

You’ll notice that this skips over some of the most important practical steps in designing, delivering, and iterating on good digital services – doing research with actual users, using modern software development tools and best practices, deploying early and frequently, etc. This was written for an audience that’s used to building digital products in the private sector, to better understand what’s new and different in a government context. Enjoy!

A short introduction

In case it’s useful, here’s a few suggestions on typical government implementation details – trying to focus here on the ones that really matter, not the seemingly-endless lists of rules that ultimately don’t affect users. These are the ones that government teams get accidentally crushed over when they screw them up (e.g. lawsuits or public shaming, etc.).

From a tech standpoint, anything you build is almost guaranteed to be higher-quality than most existing GC systems and services. Use what you’re familiar with and what you trust. Most of these suggestions ultimately have to do with the front-end/public-facing aspect of services, not back-end engineering decisions (where the GC norm is, y’know, 40-year-old COBOL or dicey ASP.NET applications).

GC = Government of Canada; sorry in advance for any acronyms

Official Languages

Anything that constitutes a Government of Canada service or communications product needs to be available in English and French, “simultaneously and of equal quality”. Ideally your departmental partner would have translation capabilities on standby so you wouldn’t need to translate things yourself – but you definitely need to build EN/FR internationalization support into everything from the start. Speaking from experience it’s a pain to add in after the fact. Publicly launching a service only in English, then adding French later, would be a huge (political) catastrophe.

Also count on at least one full business day for any translation request to come back, even ones that are marked super urgent. Write as much of your public-facing content as early as possible (e.g. in parallel to your software work) so that you can send it translation ASAP.

Accessibility

Any Government of Canada service (and ones delivered and built by third parties) needs to meet WCAG 2.0 AA accessibility standards. This is mostly the basics e.g. keyboard navigable, has sufficient colour contrast, has good headings and image alt-text, etc.

Not meeting WCAG 2.0 AA is a semi-frequent source of lawsuits that the Government of Canada always loses. Run your service through at least two or three different online testing tools that check for WCAG compliance and save a copy of the results somewhere, send them to your departmental partners for posterity, etc. Your departmental partner should be doing much more extensive, ongoing accessibility testing (the CDS accessibility handbook can help).

Federal Identity Program

Certain government types are very particular about how the government’s logos and visuals are used. The very short answer is: put the “Government of Canada / Gouvernement du Canada” signature in the top left of the page, and the “Canada” wordmark in the bottom right, and don’t be too outlandish with fonts and colours. (The formal Federal Identity Program requirements are from the 1990s and mostly apply to government letterhead, building signs, and vehicle decals – there’s a lot of interpretation and debate about how to apply them to websites, and it’s best to avoid those debates if you can.)

On the French version of your website or service, the signature should use the French-first “Gouvernement du Canada / Government of Canada” version.

CDS has a “starter app” repository that you can use for inspiration (and logo files) but don’t worry too much if you’re using a different front-end library, etc.

Domain names

The government is pretty inconsistent here, but in a perfect world everything run by the GC would have domain names ending in *.canada.ca or *.gc.ca.

When Global Affairs Canada sent out notifications to a bunch of international travellers last week [mid-March] and used bitly links, people freaked out because it looked like a scam.

There’s a DNS setup that CDS operates at alpha.canada.ca and can spin up a subdomain off of it relatively quickly, if that’s useful (and if your departmental partner doesn’t already have some specific URL in mind). It can be pointed at whatever cloud provider you need and it’s faster than going through the gauntlet of SSC + TBS + ServiceCanada that normally has to approve GC subdomains. It’d be better than something that isn’t clearly GC-operated.

Inclusive design

Practically speaking, this is probably the hardest area to figure out (but incredibly important). Think about situations like: people applying for a service on behalf of their elderly non-tech-savvy parents; band councils trying to apply on behalf of everyone on their First Nations reserve; people applying on behalf of hospitalized family members or friends.

One notable mishap here last year was IRCC’s redesigned program to apply for family reunification visas; the team built a cloud service (for the first time) and it scaled really well to handle the giant surge of requests when the application period opened (compared to, well, IRCC’s normal, more fragile IT systems). But, the program was designed “first come, first serve” and as a result, inadvertently prioritized whoever could get through the complicated online application form fastest (disadvantaging people with disabilities or accessibility requirements, people with slow bandwidth or computers, etc.).

People acting on behalf of other people is the most complicated area (and a bunch of GC services don’t handle it well, although the CRA and ESDC do have some online services that include delegating to family members / power of attorney contacts or, say, tax professionals). Whatever you build might not need to handle these edge cases, but figuring out ahead of time which ones you can and which ones you can’t (and clearly documenting why, and making sure that your departmental partners know) is important.

Shipping

In government, the hardest part of any IT-related project is literally getting it out the door. Under normal circumstances there’s a whole gauntlet of approval processes (security, privacy, quality control, infrastructure) usually all done by separate groups or committees. For a brand new online service, getting through these processes could typically take 6-24 months. (This is one reason why people say that tech implementation is only a small part of digital government work – the rest is, either navigating through or getting rid of all these waterfall processes).

In an emergency situation like the COVID pandemic, the typical approval processes for something to get shipped (“go live” or “go into production”) could potentially be skipped – but in place of them, you would definitely need some kind of written confirmation from a senior public servant (e.g. assistant deputy minister or deputy minister) from the department in question. An email from them saying “I authorize the operation of this service” is sufficient.

There is a whole graveyard littered with amazing digital products in government that never made it out the door. I can think of probably a dozen examples. Don’t be one of them. World-class tech implementation won’t get you through this; you need the backing from a public servant at the highest leadership level possible to fight through any potential gatekeepers and to give the green light to go live. Having a close relationship between the product team and that senior public servant from as early on as possible helps (direct communications, regular progress updates). I’d say, this is the biggest risk to any project – that you build something phenomenal, and then your partner department gets cold feet and it never ships. This happens frequently.

Thanks to Ross Ferguson for suggesting that I publish this as a blog post. If you’re a public servant working to navigate these rules in your department, don’t hesitate to reach out! The rules here – and the long tail of other government requirements – can definitely be a challenge, and you’re not alone.

Listen, read, donate, give space

Tue, 09 Jun 2020 18:12:39 -0700

The past couple weeks have seen an outpouring of grief, protests, and calls for change following the death of George Floyd at the hands of Minneapolis police officers. Floyd’s murder, by police, is not a one-off. For Black Americans – and Black Canadians – police violence and systemic racism is an everyday and ongoing problem.

As a white, male Canadian, it’s hard to know how to talk about police violence and racism without coming across as performative or inauthentic. Well-intentioned but cringe-worthy attempts by white people who end up putting a focus on themselves – instead of people who are actually marginalized and oppressed – are pretty frequent.

Much like the pandemic, though, police violence against people of colour and the movement against it are part of the world we live in today. Carrying on with this blog’s usual topics (government IT and, uh, more government IT) without mentioning it seems artificial, at best, and staying silent in the face of injustice, at worst.

For people in positions of privilege (white Canadians, for example), one of the most important things is to examine and reexamine how our own actions (especially well-intentioned ones) contribute to racism and inequality. They do. Before anything else, figuring out ways to do less harm is really important.

All of this involves listening, learning, and being open to often really uncomfortable conversations about how things that we do inadvertently harm others. If we’re speaking up in a meeting, or volunteering for some kind of opportunity, are we taking up space from someone with less opportunity to do so? Are we only listening to or interacting with people with the same upbringing or norms or culture as ourselves? How do we change that?

Friends and colleagues have been sharing a lot of really important resources over the past couple weeks (articles, books, places to donate to). Here’s a few that stood out:

(Many thanks to everyone sharing these and other articles and reflections over the past week or two! Lucas Cherkewski’s newsletter this week introduced me to several of them.)

Fighting systemic racism, as a public servant

Some of the conversations that really stood out in the past week were from fellow public servants, challenging each of us to more directly confront racism in our work and in our interactions with others. As politically-neutral public servants, it’s often easy to shy away from conversations about inequality and social justice that might feel “too political”.

Glennys Egan kicked off a really important conversation on this last week, that’s still continuing:

If you're not racialized, the risk of speaking out about racism you witness hurting you/your career is so low. Pls don't be afraid. It's way scarier/riskier for racialized folks to do so, I promise. Be an Active Bystander. Plus you'll prob. feel much better about yourself 🙏 https://t.co/5mZIMGSh6C
— Yumi Kotani 小谷友美 (she/elle) (@Yumi_Kotani) June 3, 2020

This is really well said so please read it. If you fancy yourself a leader, right now is a good moment to acknowledge that racism exists in our organizations and not such a good moment to be silent. I can only hope the work is happening behind the scenes. https://t.co/cHHZ3oAfF3
— Abe (@worldofabe) June 4, 2020

There’s two angles on this – one is, how do we talk about the fact that government systems aren’t equitable, from the inside? Historic injustices against Indigenous people and people of colour are built into the origins of many of the institutions we work in. How do we rethink that, and create government services that are more compassionate, more inclusive, and deliberately designed to challenge and reduce inequity?

The other angle is: how do we confront the reality that Black public servants face systemic barriers to their careers, and retribution for community advocacy work? The senior executive ranks of the federal public service are almost completely white, which makes it ill-prepared to understand systemic biases against public servants of colour, and ill-prepared to address issues like police violence and systemic racism in society at large.

What does a different future look like?

Ta-Nehisi Coates and Ezra Klein published a great interview last week, where the ongoing theme was optimism for change despite police oppression and the current state of American politics. Reading it, their reflections on what a different kind of government and society could look like really stood out:

One thing I’ve been thinking about is whether the question can and should be turned around: Instead of nonviolence being the ethic demanded of protesters, what if it was the ethic demanded of the state? That seems more reasonable to me, at least as a goal.

The core of nonviolence is that you will transform those you are in relationship with through your own willingness to suffer and forgive. You will forgive over and over and over again. You will always hold out the hope of growth and transformation, and you will accept enormous risk and pain to create space for it.

There are many ways we could think about this in terms of the state. You could think about prison abolition. You could have police who did not have guns. If nonviolence is such a beautiful way of living, I think we should imagine that for the state. I think it’s actually worth doing.

Building a more just, equitable society is a public policy question. It’s so much more than that, too. But for public servants, public policy students, and aspiring and current politicians – it’s so important to recognize that working to build a better society is what you signed up for. It isn’t just a thing to watch other people do, on the news or from the sidelines. It’s what you’re here for.

Doing this well – making things better, instead of making things worse – involves stepping back, listening, and ceding space to other people who don’t have the privilege that you have. It involves, as a first step, not doing harm. And it involves learning as much as you can from people of other communities, backgrounds, and cultures, and shifting power to them without making it about yourself.

I still have a long way to go and a lot to learn; writing a blog post this long feels questionably close to making it about myself. If you’re interested in more to read, check out Policing Black Lives: State Violence in Canada from Slavery to the Present (whose CBC interview is mentioned above), or – especially for a technology lens on systemic racism – Algorithms of Oppression: How Search Engines Reinforce Racism (which Lia Milito recommended). If you’re a federal public servant, you can also join in to conversations Glennys and others are organizing to build an inclusive and anti-racist public service.

Blockers versus enablers

Tue, 02 Jun 2020 15:22:55 -0700

Also published on Apolitical

As many of you will know, something I’m very interested in is the value of public servants’ time. When I first launched the Meeting Cost Calculator, a lot of the early feedback I got was how useful the calculator would be for other, non-meeting public service activities as well. You could use the calculator to estimate the total cost of writing and reviewing a briefing note, to fill out the paperwork for a leave request, to complete the travel claim process, etc.

Part of what motivated creating the calculator is the belief that public servants’ time is valuable – something that isn’t always appreciated by senior public service management, the public, and public servants themselves. The public service is often seen as cautious, risk-averse, and perfectionist. The hierarchy of public service institutions compound this, as documents and other products get carefully reviewed and wordsmithed at each layer. All told, these tendencies create an environment where getting things out the door is a challenge.

The organizational dynamics in these situations are sometimes hard to talk about; one person’s due diligence reviews are another person’s unreasonable delays. In today’s context, however, where the public service is being asked to respond more quickly to evolving social needs, being able to get things out the door quickly (and continue iterating once they do) is more important than ever.

As a model to describe behaviours that either support or prevent things from getting out the door, “enablers” and “blockers” is a convenient (if simplistic) shorthand. Enabling versus blocking is a property of the behaviour of people in management or gatekeeping roles, and of the institutional structures that incentivize certain behaviours. It’s worth remembering: people aren’t blockers, although particular actions they take might sometimes be. And, blocking behaviours almost always have good intentions at their root, even if the consequences ultimately outweigh the benefits.

Blockers as a function of time

As a public servant trying to get something approved up the hierarchy, the simplest definition of blockers versus enablers might be a “no” or “yes” at each level. Changes and edits from various layers of management can feel like a blocker each time (even if these changes are ultimately improving the document or product).

“Yes” and “no” isn’t the whole story, however; the time it takes to receive these is a bigger factor. (In practice, more frequently, it’s the time it takes to receive some kind of edit or revision to the document). A “fast no” with a series of changes that will then let the document keep on moving up is more valuable than a “slow yes”, where the document is approved as-is but only after weeks or months of sitting on someone’s desk.

In environments where shipping things quickly matters (which, ideally, would include most of the public service), “slow yesses” and “slow nos” are practically equivalent. In some cases, the “slow no” or “slow yes” are deliberate institutional strategies – to take so long to review or approve something that the originating party ultimately gives up.

Overcoming blockers as a function of time often depends on setting clear expectations for timelines and getting pre-approval for things long before you need it. Here are some potential strategies:

Providing clear deadlines when you’re asking for feedback, and being clear about what things you want feedback on
Whenever possible, explicitly frame requests as “for input” instead of “for approval”, so you can keep moving if recipients don’t respond
When you need approval from groups outside your own hierarchy, do this in parallel, not in series (e.g. ask each group, separately, all at once instead of one after the other)
Get formal pre-approval in writing for activities you might need to do down the road, far ahead of time

Blockers as a function of quantity

Public service institutions often have a large number of actors that need to review or approve things intended for public consumption – content reviews, privacy reviews, security approvals, project governance, etc.

Even if (in best case scenarios) these various committees and gatekeepers are supportive of a project’s goals, getting all of them to individually green-light a document or product can be very difficult. One group’s proposed changes can cause another group to have second thoughts, and maintaining the simultaneous approval of everyone involved for long enough to actually get something out the door can sometimes seem impossible. Shepherding this process falls to the original team, and each actor involved may not realize the combined burden that they and every other actor cumulatively imposes.

In many cases, the quantity of approvals or reviews required acts as a structural blocker, regardless of how positive or supportive individual reviews are. Dominica DeGrandis’ Making Work Visible book provides a useful mathematical model for this:

If there are two inputs needed to deliver something, then there is only one chance in four of delivering on time. One chance in 2^n is the formula that computes the total number of binary permutations.

If each given actor needs to green-light a product (providing either a “yes” or “no”), then every additional actor doubles the number of possible states.

There’s only one state in which the product is fully green-lit (when everyone says “yes”). With two reviewing actors, there’s a 1 in 4 chance of being green-lit. With three, there’s a 1 in 8 chance. With four, there’s a 1 in 16 chance, and so on.

In typical government departments, 16 different groups might need to approve a given project – that’s 65,536 possible states (2^16), and only one state where everyone agrees. It’s not great odds.

Overcoming blockers as a function of quantity ultimately comes down to, reducing the number of external approvals or reviews that are required. Some strategies for this include:

If you can, influence the design of internal processes to have as few external dependencies as possible
Delegate formal approvals as far down the hierarchy as possible, and trust your staff to make decisions autonomously
Decouple “go-live” decisions from committee or governance reviews (in favour of continuous, incremental improvements), and get permission to do this from the very beginning

What does enabling look like?

Although this post doesn’t paint an optimistic picture, good work gets done in the public service all the time. In a lot of cases, that’s thanks to thoughtful public servants in management and leadership roles, who champion their teams’ work and fend off potential blockers when needed.

The public service leaders that I look up to most embody a combination of humility and trust – hands-off and confident in their teams to make good choices and do good work, but ready at a moment’s notice to step in and shield those teams from external delays, gatekeepers, and threats.

It’s striking how rare, and how powerful, a statement like “endorsed, with no changes” is in a rigidly hierarchical environment like the public service. It’s an expression of trust – both in a team’s capacity to implement, and in the value and urgency of their work.

The metaphor for enabling public service leadership that comes to mind (you’re welcome, Star Trek fans) is of a starship in orbit. You trust the away team to do what works best on the ground, but you’re on standby and ready to act when needed. Just knowing that you’re there, and that you have the team’s back, sometimes makes all the difference.

For more on emerging styles of public service leadership, this recent piece from Abe Greenspoon and Jennifer MacLeod is a great read.

Why are there so few senior developers in government?

Tue, 26 May 2020 18:48:51 -0700

Delivering good services to the public, in the internet era, depends on designing and developing good software.

In the Canadian government, there’s about 17,000 IT professionals, comprising the Computer Systems (or CS) job classification. The CS classification has five levels (CS-01 to CS-05) and includes IT helpdesk staff, software developers, software team leads, database administrators, enterprise architects, security assessors, and a handful of executive-equivalent roles at the top end of the classification.

However, the number of CS staff whose day-to-day job is software development is relatively low, and this drops to nearly zero at the top end (for example, CS-04 and CS-05 roles). This is significantly different from typical private sector tech companies.

In the private sector, competition for experienced software developers – who can quickly and thoughtfully design software, deploy it reliably and securely, and mentor junior staff – is incredibly fierce. Large tech companies frequently try to poach experienced developers from each other. For new startups, having one or two senior developers early on can mean the difference between success and failure.

Here’s how Microsoft (one of the world’s leading technology companies) describes the importance of developers:

Computing is becoming embedded in the world, with every part of our daily life and work and every aspect of our society and economy being transformed by digital technology. Developers are the builders of this new era, writing the world’s code.

As every industry – from precision medicine to precision agriculture, from personalized education to personalized banking – is being impacted by technology, the developer community will only grow in numbers and importance. Developer workflows will drive and influence business processes and functions across the organization – from marketing, sales and service, to IT and HR. And value creation and growth across every industry will increasingly be determined by the choices developers make.

In short, developers will be at the center of solving the world’s most pressing challenges.

Identifying why the government has so few senior developers

The government does have a few thousand developers, mostly at the CS-01 and CS-02 levels (exact numbers by type of work are difficult to determine, within the 17,000 total CS staff). The government also has an estimated 60,000 or more IT contractors and consultants, many of whom likely do software development as their primary role.

But, the absence of senior developers is notable, and concerning given their value in being able to understand and build on complex software systems, hold external contractors and consultants to account, and – as a US Department of Defence guide elegantly says – detect “agile BS”.

There’s a number of reasons why the government has so few senior developers. (If there’s entries missing from this list, please let me know!) Here’s a few:

Lack of senior specialist/developer (non-management) tracks: From the CS-03 level on, government IT staff are expected to manage other employees. Unlike most private sector tech companies (which have “dual-track” career progression models), senior non-management technical roles largely don’t exist in the Canadian government. (Although there are non-management CS-03 and CS-04 roles in some departments, they’re rare and public servants who choose them aren’t able to progress to the management-only CS-05 level.)
Bilingualism requirements for all management roles: The federal public service’s Official Languages commitments require that anyone in a management role is able to effectively communicate with their employees in both English and French. Since mid-level CS staff and up are almost all expected to manage other employees, this imposes bilingualism requirements widely across the CS population. In an already fiercely-competitive industry, finding developers who also speak both English and French makes a small pool of potential candidates even smaller.
Limited internal career progression: The CS “generics” classification structure used in many parts of government require a certain number of CS-04s below each CS-05, a certain number of CS-03s below each CS-04, and so on. This rigid pyramid structure causes “bunching” and stagnated careers at the lower-end CS levels, with public service developers sometimes waiting more than 10 years for promotions into the small number of higher-level positions available. This also makes it more difficult and more controversial for teams to bring external developers into salary-competitive higher-level positions.
Extensive hierarchy and lack of autonomy: The extensive hierarchy of the public service – the number of layers between working-level staff and decision-makers – can be unsettling and discouraging to technology professionals who are often accustomed to startup or freelance work, more enthusiasm for bottom-up idea-generation, and a much higher level of personal autonomy over their work. Public service IT management and leadership also tend to use more outdated approaches and tools, discouraging developers who are new to the public service.
Centralized government IT shops: Isolation in centralized IT or corporate services branches and waterfall project management methods also disconnect developers both from important colleagues (designers and researchers, for example) and from the end-users who would benefit from their work. Frequent reassignment from project to project prevents developers from being able to see the impact of their work from end-to-end.
Outdated technical stacks: Many of the technology systems and programming languages used in government are decades older than those used by leading technology companies. Given the choice, most developers would rather not use many of these technologies. The continued use of these systems (and the rejection of widely-used modern programming languages and frameworks) is often the result of misplaced attempts at standardization.
Inability to customize and choose your own tools: Developers (especially very good developers) are famous for very carefully customizing their working environment, operating systems, and programming tools. In many government settings, desktop security settings and group policies prevent staff from doing things as simple as changing their screensaver – let alone installing and customizing software development tools in order to work at their best productivity.
Slow, cumbersome hiring processes: The average time to staff a government position (from start to finish) is 40 weeks. In the private sector, companies frequently hire developers in 1-4 weeks. Average staff tenure at large tech companies is 2-3 years. By the time government institutions are able to offer talented developers a job, they’ve more than likely accepted private sector offers elsewhere. An emphasis on formal education and technical certifications in hiring processes also hinders applicants who have extensive experience but unconventional paths to becoming a developer.

For developers who do end up in government, there tends to be an overemphasis on makework instead of programming. Here’s an example from a federal department’s developer job posting in 2018:

Significant and recent experience in leading IT enabled projects or operations through all stages, including preparing business cases, leading multi-disciplinary teams, managing project or operational budgets, as well as delivering digital services to users

The “as well as” at the end – delivering digital services to users – is ultimately the work that software developers tend to find the most meaningful.

Experienced software developers – the people that government IT and service delivery teams need most – have a wealth of job options. Convincing them that the government is a fulfilling place to work depends on overcoming many of the reasons above. Doing this will be challenging work, and will require changes both to government policies and collective bargaining agreements. But to deliver internet-era services, these are critical steps.

Crisis, bureaucracies, and change

Fri, 22 May 2020 20:33:17 -0700

It’s been two months and a bit since the COVID-19 pandemic dramatically adjusted life in Canada. Amid the social and economic upheaval that took place, government responses – public health activities, emergency benefit programs, and more – have played an essential role. Government departments have rolled out benefit programs to Canadians in record time, with politicians and public servants alike developing and iterating on programs at an unprecedented pace.

As an enthusiast for public sector reform, it’s been genuinely encouraging to see the public service in Canada rise to the occasion. It’s a noteworthy moment, and some recent publications have captured what’s different between the present and “business as usual” in the public service. An April piece from Matthew Mendelsohn says it well:

…we can internalize the lesson that making adjustments to programs in real-time based on new information should be easier; that front-line staff and stakeholders will understand how programs are being experienced on the ground; and that acknowledging that something can be improved once it has been launched should not be interpreted as a catastrophic failure. At the end of the day, every program should be designed to achieve a clearly defined outcome. If evidence accumulates that programs are coming up short, processes must be designed to allow for recalibration.

The most striking difference between the public service in crisis-response mode and the status quo is its willingness to accept risk. In the same piece, Mendelsohn writes:

Normally, dozens of public servants poke and prod at every line and every number in a policy proposal, asking questions that are impossible to answer, with the goal of eliminating any risk that the program will be inefficient. What usually emerges is a watered-down program, with easy to achieve but meaningless metrics and accountability driven by conformity to process. Under ordinary circumstances, processes are designed to eliminate perceived risk of any new initiative to near-zero.

What we are seeing is the exact opposite. Governments know there are huge risks inherent to the programs that are being offered, but are willing to take them. In ordinary times, any one of the risks that are currently accepted would be enough to kill a new program. That’s why it is generally so difficult to get innovative, risky new programs launched.

Again, governments can’t just switch from risk-aversion to risk-seeking. But there are lessons to internalize: the risk of doing nothing is often greater than the risk of change, yet government systems are designed to kick the stuffing out of any new proposal, without probing deeply the risks of the status quo.

In a Twitter thread on the CERB application process, Aaron Snow describes the pivot “from ex-ante to ex-post eligibility enforcement” that made the application experience so seamless. Under normal circumstances, government benefit programs are usually designed with complex upfront approval criteria (designed to reduce the risk of fraudulent payouts) – but these add delays, errors, and time-consuming follow-up stages to the application process.

In many cases, people either don’t bother applying, or aren’t successfully able to, and miss out on benefits they would actually be eligible for. The CERB model (immediate upfront approval, and down-the-road eligibility reviews) addresses that in a clear way, thanks to some clever programming and a more thoughtful approach to risk.

Will it stick?

Archived tweet from Steven Hepburn

Despite some hiccups (network capacity, for example), the federal public service has adopted a number of changes to work more effectively during the COVID-19 pandemic. This includes guidance from the Treasury Board Secretariat that encourages the use of online collaboration tools like Slack and Google Drive in order to reduce the strain on departmental IT systems.

In the immediate reaction to the crisis, many government departments streamlined internal processes or temporarily exempted teams from needing to follow them. In institutional settings with an overabundance of process, this is a welcome thing. Trusting public servants to use their best judgment and to focus on outcomes over processes – and having power delegated to working-level staff to do so – should be the everyday norm.

A friend in another department reported that, after 5 or 6 weeks, their department re-imposed the cumbersome internal processes and external approvals that had been removed at the outset of the pandemic. Crisis mode – high trust and autonomy – reverted to business as usual.

Outside of crisis situations, it’s easy to get disconnected (as a public servant) from the actual impact of your work on people. If you get far enough away, your assessment of your own success becomes, “how well did I follow the process” rather than, “what impact did I have on Canadians” (or whichever population you serve). The urgency and constraints of working in a crisis force us to reconsider assumptions and processes that are long-established, and they also remind us of why our work matters.

In an April opinion piece, Tony Dean says it well:

…when this crisis subsides, Canada’s public servants should not go all the way back to normal. They should be empowered to continue embracing uncertainty, learning through experimentation, and continuing to work more collaboratively across sectors and jurisdictions to bring different perspectives to the table. Public servants want permission to innovate as much as Canadians would benefit from it.

Interested in ways to make crisis-mode changes stick? Nick Scott’s blog post on parallel learning structures is a great deep-dive into path dependency and strategies for change in government.

Kathryn May’s How COVID-19 could reshape Canada’s federal public service, published May 23, is also a must-read.

The cycle of bad government software

Wed, 20 May 2020 19:15:46 -0700

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.

New #GCdigital challenge – take an online tool (say, Google Docs) and guess if it’s more likely to be used by a) seven year old elementary students or b) your department’s senior leadership. Then ask how we can build up executive-level digital literacy. https://t.co/dyrBQjsuyv
— Sean Boots (@sboots) March 4, 2020

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.

Corporate networks are not the future

Wed, 15 Apr 2020 22:40:08 -0700

It’s been about a month now since federal government employees have been asked to work from home, to reduce the potential spread of the COVID-19 pandemic. This has been a fairly unprecedented change for the public service.

Across hundreds of thousands of public service employees, only a small fraction normally work from home – and the sudden shift to a fully remote workforce quickly overwhelmed the IT infrastructure used to access corporate networks from home. As this piece from Chris Nardi explains,

Since Monday, most federal departments are asking staff who were sent home to stay off internal servers if they aren’t working on core or critical services. That’s because most ministries have significant limitations on how many people can simultaneously access work servers from outside the office.

“Imagine when you used to have to connect to the Internet with a dial-up connection. That’s what the situation is now. Every minute counts, so you connect, you download what you need, and then you get off,” union leader Debi Daviau said about government VPNs (Virtual Privacy Networks).

Over the past few weeks, government IT staff have scaled up VPN access and network capacity as quickly as they can. It’s really impressive work, but one of the questions is why government network and remote access capacity was so constrained to begin with. It’s likely a combination of a few things: old buildings without modern network cables and switching equipment; old (basement) data centres that were already slated for upgrades; a limited number of licenses for VPN software that work on a per-connection basis (either on the client or server side); not enough server capacity to handle remote desktop or VPN connections.

There’s another limiting factor, though: the dedicated security hardware used in corporate networks across government. These are hardware-based firewall and network monitoring devices (F5 hardware devices, for example) designed to observe all of the traffic going in and out of the “perimeter” of corporate networks. This is normal in government institutions, banks, and other large companies – and it’s also one of the main reasons why scaling up bandwidth and remote access is so difficult.

A colleague asked me once if it was legal for our department’s IT security folks to monitor our internet traffic. Formally, for Canadian government employees, your department is required to let you know that “electronic network monitoring practices” are being applied (and if you’re connecting through a corporate network or VPN, they are); typically that’s part of the acceptable use screen that you consent to before you log into your corporate device. Spoiler alert, it’s legal.

Alex Stamos (previously the VP of security at Yahoo, then CSO at Facebook, and now a professor at Stanford) gave a great overview of why perimeter network monitoring is a problem in a 2015 keynote at the OWASP security conference. It’s a long presentation, but worth watching. One of the takeaways is that, for companies and organizations operating at scale, it’s becoming a “completely ridiculous idea” to buy security hardware. These monitoring devices are the slowest and most energy-intensive pieces of any data centre operation, and they don’t work well with the containerized, automatically-scaling model of modern, cloud-based software infrastructure.

To networking and IT security staff that have been working on corporate networks for a long time, this probably seems sacrilegious. Network perimeter monitoring (through the enterprise firewall devices that Alex Stamos criticizes in his talk) was long one of the main tools used to watch for unauthorized or unexpected traffic, hacking attempts, or compromised devices. Moreover, the hundreds of legacy applications on the inside of the corporate network typically have almost no application security features whatsoever – what my friend Mike Williamson calls the “crunchy outside, gooey inside” approach to IT security (this approach is …no longer a best practice).

I’m not advocating that departments get rid of their corporate networks tomorrow, or unleash the world upon their undefended legacy applications. But as organizations (government departments included) plan what they need for the future, it’s clear that corporate networks and the dedicated security hardware guarding the perimeter aren’t it. The main downsides, in a “cloud-first” world are:

putting security hardware that can’t scale well as a chokepoint between end-users or staff and cloud-based applications and services, which do scale well
introducing single points of failure (the security hardware itself, and/or on-premise remote desktop or VPN servers) that are liable to fail when you need them most
adding significant complexity when new cloud-based services need to connect “into” the corporate network to talk to a legacy system (particularly in the Canadian government, in which this automatically introduces an external dependency on networking staff from Shared Services Canada)
creating a false sense of security and diverting investments away from application security and other modernization efforts

This isn’t a uniquely Canadian problem, but other governments are taking proactive steps to move away from corporate networks. The United Kingdom announced in 2017 that they would officially begin moving away from their Public Services Network (PSN) corporate network:

At a recent meeting of the Technology Leaders Network, we reviewed our position and it was clear that everyone agreed we could just use the internet.

From today, new services should be made available on the internet and secured appropriately using the best available standards-based approaches. When we’re updating or changing services, we should take the opportunity to move them to the internet.

The future is the regular internet. Moving away from corporate networks isn’t easy; there’s a lot of path dependency from previous investments, previous security policies and approaches, and (in Canada) from the organizational history of departments like Shared Services Canada (that reinforce a divide between networking and sysadmin staff, in SSC, and application developers in individual departments).

Investing more in modern application security and building cloud-native applications is an important first step; large-scale cloud providers have a range of audit logging and monitoring features built into their service offerings that mitigate the need for separate firewall devices.

Avoiding any requirement for these applications to pass through or depend on corporate networks is the second step. Google’s “zero-trust” security model – assuming every device might be compromised, and engineering secure systems with that in mind – is a good example of what this future path can look like.

Right now, federal government employees are largely all working from home, using online tools (like Office 365) that are also off the corporate network. It raises the question: what value is a perimeter when everything is outside it?

I’ll end off with a presentation from the US Digital Service’s Marianne Bellotti at the 2017 Strangeloop conference, on her work to remove US government requirements for “Trusted Internet Connections”. Security policies that make it harder to build modern, reliable, and scalable software ultimately end up making things less secure.

Thanks to Mike Williamson for the conversations that inspired this post.

Sharing is caring

Tue, 07 Apr 2020 21:40:02 -0700

As governments and organizations around the world have grappled with the COVID-19 pandemic, their efforts to reuse and remix others’ work have stood out as a bright spot:

Archived tweet from John Michael McGrath

Seeing this take place has been really encouraging. Within Canada and around the world, there’s a lot of neat ways that people and teams have been learning from and sharing with each other:

Open source software: Nova Scotia and Ontario’s COVID-19 self-assessment tools were both based on Alberta Health Services’ online content, and were published as open-source code on GitHub for others to adapt. The UK’s Notify platform has been reused by Canada and Australia to quickly send notifications to citizens at scale.
Research data: Health studies and case tracking have been shared publicly, with publications that would normally have been paywalled or restricted being opened to public access. Source data for the Johns Hopkins University case tracking dashboard is also being published to GitHub, where other researchers can review and propose updates to it.
Good ideas: From public policies to communications strategies, these are being imitated and adopted from one country to another. Norway’s Prime Minister held a news conference to answer pandemic questions from children; a couple weeks later, Canada’s Prime Minister did the same.

Under normal circumstances, governments and organizations are often resistant to adopting ideas from elsewhere. The perceived uniqueness of each organization, or “not invented here” syndrome, leads to missed opportunities to adopt ideas that work well elsewhere. It can take a lot of humility to adopt others’ good ideas, rather than coming up with something of your own.

Although the pandemic is an unprecedented situation, it raises a lot of questions about how society should work under normal circumstances (something for future blog posts!). Academic researchers making the case for more open access to science journals (as one example) argue that these changes should become the norm, not the exception:

“It’s incredibly important that this happen. Of course this should be the default for ALL science, not just COVID-19 science, and it should have been the default for the past 25 years. But I’m glad to see this happening now.”

The sharing that we’re seeing today – between countries and between levels of government – is a reminder that governments often face very similar problems. We end up solving the same problems over and over again, rather than adopting or adapting policies, legislation, ideas, or software code that others have already created. We get more expensive, less-reliable outcomes as a result.

In Canada, there’s a few future steps that would be particularly valuable. Making publicly-funded software code open source by default (as the UK and France have done) would be a dramatic level-up for government IT – helping reduce vendor lock-in and leading to higher-quality software. Switching to an internationally-recognized Creative Commons attribution license for government open data would make it easier to reuse. A recent Private Member’s Bill to amend Crown Copyright – and make Government of Canada publications automatically part of the public domain, as they are in the United States – would go even further.

Sharing is caring. As governments, we don’t do it often enough. Hopefully – as we all work through the pandemic together – we can learn to make this the norm.

Curious about using open source in the Government of Canada? Josh and I have a blog post answering your questions here.

Data residency is security theatre

Sun, 29 Mar 2020 22:11:28 -0700

One of the most persistent myths in Canadian government IT is that storing your data in Canada protects it against eavesdropping or interception by foreign governments. Storing your information in data centres geographically located in Canada, the claim goes, or using cloud services that are fully hosted in Canada, safeguards you against your data being intercepted by, say, U.S. intelligence agencies.

If someone on your government team has asked to use a new online tool and your reaction is, “no, you can’t, because it’s hosted in the United States,” this article is for you.

For Canadian public servants, data residency concerns mostly originate from the USA PATRIOT Act, introduced in 2001 following the 9/11 attacks. The PATRIOT Act gives U.S. law enforcement and intelligence agencies a broad ability to intercept and collect electronic information without informing the persons whose information is being gathered. Although the PATRIOT Act has been in place for almost twenty years, it wasn’t until a few years ago (as the Canadian government began to adopt cloud services) that formal data residency requirements were introduced.

Consequences of data residency requirements

Canada’s adoption of cloud services comes several years behind most comparable governments. Around the world, governments and leading private sector companies have all adopted cloud services in earnest, for everything from front-line service delivery to internal collaboration tools.

Cloud services (operated by third-party companies and accessed over the internet) are updated and improved regularly, can be easily and reliably scaled, and typically cost much less than custom software hosted in traditional data centres. Using “software as a service” tools (where an online application and the infrastructure it runs on are both operated by a third-party company) has become an integral part of software development, collaboration, and team communication for modern organizations.

Canadian government departments have nominally been able to use software-as-a-service tools with protected information since 2017. Government-wide policies explicitly encourage the adoption of cloud services, especially software-as-a-service products. However, data residency requirements applied to Protected B information mean that most software-as-a-service tools – which are almost all hosted outside of Canada – can’t be used by government teams that need to handle this level of information. Moreover, widely held misconceptions that no Canadian government data can be stored outside of Canada have significantly hampered the adoption of cloud services.

Data residency requirements – and the myths that have accompanied them – have slowed the adoption of modern cloud services in government. In place of the professional-grade software used by other governments and companies, Canadian government teams end up depending on legacy IT systems. Or, they end up adopting mediocre imitations of widely-used software, where the selling feature is that the product is hosted in Canada rather than being user-friendly, reliable, scalable, or cost-effective.

Canada is too small a market for any but the largest cloud service providers to launch dedicated infrastructure here. Data residency requirements limit software options to major providers and exclude small software-as-a-service companies and products that are widely used elsewhere.

Your data will be monitored anyway: a historical overview

Proponents of data residency requirements argue that, by storing government information in the United States, it will become subject to U.S. surveillance and infringe on people’s privacy rights as a result. But developments over the past two decades suggest that – no matter where information is stored – it’s subject to intelligence or law enforcement monitoring anyway.

Boomerang routes

In the years following the introduction of the PATRIOT Act, a major concern was that Canadian internet traffic frequently crisscrosses U.S. borders, and would be intercepted and monitored when it crossed. Researchers at the University of Toronto and York University pointed out that most Canadian internet traffic – even when it starts and ends within Canada – is routed through internet infrastructure in major U.S. cities (so-called “boomerang routes”).

Internet networking systems automatically optimize for the fastest and most reliable routes – that’s part of what makes the internet resilient – and the fastest networks between two points in Canada often travel through the United States. Although this doesn’t apply to dedicated (standalone) corporate networks, any Canadian citizen interacting with a government service online would be potentially subject to U.S. monitoring as a result.

Edward Snowden and the reach of U.S. electronic monitoring

In 2013, former U.S. intelligence contractor Edward Snowden revealed that U.S. electronic surveillance extends much further than had previously been publicly known:

a dragnet programme to scoop up digital activities direct from the servers of the biggest US tech companies; a tap on fibreoptic cables to gather huge amounts of data flowing in and out of the UK; a computer program to vacuum up phone records of millions of Americans; a codebreaking effort to crack the encryption system that underpins the safety and security of the internet.

Snowden’s revelations make it fairly clear that information stored anywhere in the world is potentially subject to U.S. intelligence monitoring. Ironically, the country where it’s likely the hardest for U.S. intelligence groups to monitor is the United States itself, since they would need to get FISA court or domestic law enforcement approval to potentially monitor American citizens.

Foreign intelligence agencies running misinformation campaigns reportedly use servers located in the United States for this exact reason.

The Microsoft Ireland court case

As part of an unrelated law enforcement investigation in 2013, a U.S. judge issued a warrant requiring Microsoft to produce emails and information associated with a user account allegedly related to drug trafficking. The emails were stored on Microsoft servers located in Dublin, Ireland, and Microsoft argued that a U.S. judge did not have the authority to issue warrants for information located outside the United States.

In 2014, a federal judge declared that the legislation the warrant was based on (from 1986) acted as a subpoena and was not restricted by territorial constraints. Several appeals followed, ultimately leading to the U.S. Supreme Court. The central question throughout was whether data stored outside of U.S. borders, but belonging to U.S. companies, was still subject to law enforcement warrants – and, relatedly, whether the invasion of privacy approved by a warrant took place in the United States or, in this case, Ireland.

Before the Supreme Court case was decided, the U.S. Congress passed updated legislation as part of an omnibus spending bill that clarified that U.S. cloud service providers were indeed subject to U.S. law enforcement warrants, even if their data was stored elsewhere:

Primarily the CLOUD Act amends the Stored Communications Act (SCA) of 1986 to allow federal law enforcement to compel U.S.-based technology companies via warrant or subpoena to provide requested data stored on servers regardless of whether the data are stored in the U.S. or on foreign soil.

Although in many cases these situations would be handled by mutual legal assistance treaties, the main takeaway from the court case is that – as long as data is being stored by a provider with U.S.-based business interests – it is subject to U.S. law enforcement no matter where in the world the data is located. Practically all of the major IT vendors, systems integrators, and management consulting companies that work with the Canadian government also have U.S.-based operations.

Operational security, not theatre

Data residency is a common myth because it intuitively seems like data hosted in Canada will be more secure than data hosted elsewhere. The data residency myth becomes a placeholder for more informed technical discussions – discussions that can quickly become deeply complex, relating to specific encryption techniques and cloud security best practices.

There are important questions that teams and organizations should be asking when they’re considering new cloud tools, including:

Is the service provider sharing your data with third parties?
What data export options are available, how comprehensive are they, and how easy would it be to switch to a competing service in the future?
What security and account management settings are available? Are they sufficient?

All of these questions help determine how secure and effective a service is, but none of them have to do with where the service’s data is geographically stored.

In public service environments with a shortage of technical expertise, simple explanations (like storing data in Canada to keep it safe) are attractive and reassuring. Data residency is “security theatre” because it gives the impression of making things secure, without actually adding any operational security benefits.

Data residency requirements do have some potential value when it comes to specific legal questions – namely, where lawsuits between a service provider and customer might take place, although this is usually determined in terms and conditions or contract details instead. And, as the Microsoft Ireland court case shows, unless the contract is with a company that has no U.S. business whatsoever, any information the company stores is still subject to U.S. law enforcement.

Ultimately, this is okay (or at the least, inevitable). Protected B information, mentioned above, isn’t meant to be secure from motivated foreign intelligence actors; there are other classification levels (and other networks) for information that genuinely should be protected from foreign eavesdropping.

Government teams should focus their efforts on security and cloud infrastructure best practices – operational best practices, as opposed to compliance paperwork – and they should use the best cloud service providers available for their use-case, regardless of whether data is stored in the United States or not.

Change for the better

Next week, updates to the main Government of Canada policy on information technology are coming into force, as the Policy on Management of Information Technology is replaced by the Policy on Service and Digital. Among other changes – making the policy more streamlined and more closely focused on user needs – the update removes the formal data residency requirements that were previously included.

The existing policy (being withdrawn on April 1, 2020) included the following language:

Ensuring that all sensitive electronic data under government control, that has been categorized as Protected B, Protected C or is Classified, will be stored in a GC-approved computing facility located within the geographic boundaries of Canada or within the premises of a GC department located abroad, such as a diplomatic or consular mission. This does not mean that the country of origin of IT service providers must be Canada, as long as these service providers can ensure storage of data within boundaries or premises as described above.

The new policy is reorganized slightly, with departmental CIO responsibilities being moved to the accompanying Directive on Service and Digital. The corresponding language (emphasis mine) is,

Ensuring computing facilities located within the geographic boundaries of Canada or within the premises of a Government of Canada department located abroad, such as a diplomatic or consular mission, be identified and evaluated as a principal delivery option for all sensitive electronic information and data under government control that has been categorized as Protected B, Protected C or is Classified.

This is a really welcome change, and opens the door to a much broader adoption of software-as-a-service tools than were previously available.

It’s worth noting that some other Canadian government policies have not yet been updated to match this change – notably, the Standards for the Conduct of Government of Canada Public Opinion Research (which still include explicit data residency requirements) and the 2017 Direction for Electronic Data Residency (which predates the policy requirements above but has not yet been formally deprecated). And, several provincial governments – namely British Columbia and Ontario – have provincial legislation that imposes data residency requirements for personal information and health data.

(Also worth noting – and it’s a topic where the terms often get mixed together – is the concept of data sovereignty, which is the ownership and hosting of data by Indigenous groups and other historically-marginalized communities. In an environment where social and cultural research has often been done to marginalized groups rather than with them, it’s a useful tool to rebalance power dynamics. You can learn more from this Animikii article or from the First Nations Information Governance Centre.)

As government technology practitioners, we operate in an environment with a long list of constraints – on how we work, what tools we use, and what permissions we need to build and ship software and services. My goal, with blog posts like this one, is to remove as many constraints as I can – and to give people the space and trust to choose the tools that work best for them.

Use the tools that work best for you. Think carefully about the (genuine) security and privacy implications of the tools you use, but don’t choose them based on security theatre and myths. Choose them because they’re the best tools.

Look out for one another

Wed, 25 Mar 2020 21:22:20 -0700

It’s been a strange, unfamiliar, and in a lot of ways distressing past few weeks for people. Years from now, we’re going to look back at this point in time – early-ish 2020, or late 2019, depending on where you were at the time – as a monumental occasion for our individual lives, our societies and the world.

My default approach is to try to find the silver linings in any situation. There’s a time for that, but as people are losing their jobs, places and businesses are closing for now or for good, and everyone shelters in their own homes – now doesn’t feel like the moment.

Months from now, we’ll celebrate the (incredible) work of nurses and doctors and medical staff, of grocery store and pharmacy workers, of truckers and logistics people, of public health experts and of everyday people looking out for one another (from a safe distance of 2 metres away).

In the meantime, call your friends and family; have Skype brunches and dinners over FaceTime. Last weekend my amazing friend Jessica Fan organized a virtual coffeehouse over Zoom – with friends playing songs on piano and guitar, singing or reading poems to each other. It was such a bright and unexpected moment, of finding joy in a shared social experience after being isolated at home.

Look out for one another, and don’t be afraid to ask other people to look out for you. We’ll get through this.

Find the truth. Tell the truth.

Tue, 03 Mar 2020 22:00:26 -0800

I read a great post this week from Robin Rendle, Systems, Mistakes, and the Sea. It’s worth reading just for the description of “hyperobjects”, a much more practical concept than the name might suggest.

The post is about design systems, the trend that has been sweeping the design field for several years. I’m torn, in any discussion on design systems, between consistency being good for users and the danger that design systems might squish creativity and autonomy out of web development work. In general, any move towards standardization for standardization’s sake makes alarm bells go off in my head – but design systems can add a lot of value by speeding up developers’ work and letting them focus on edge cases instead of routine components.

Robin’s post touched on a deeper point, though: that every presentation or discussion of other teams’ design systems work seemed wildly successful and easy, while his own team’s efforts were one difficult challenge after another:

What gets to me isn’t that everyone appears to be building beautiful design systems. Instead what bothers me is that it appears as if everyone is building them all so very easily. This has led me to wonder that, if this work is so easy for them, then why is it so hard for me? And how can they do it without ruining their evening, or a relationship, or letting the state of the system ruin their health? Is it a problem of experience? A lack of mentorship? Am I bad at my job?

But in conversations with other designers, privately, the story is different. The work is hard, everywhere; things aren’t going as smoothly as it might seem from the outside:

My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.

The ugly truth is that design systems work is not easy. And what works for one company does not work for another. In most cases, copying the big tech company of the week will not make a design system better at all. And so instead we have to acknowledge how difficult our work is collectively and then we have to do something that seems impossible today—we must publicly admit to our mistakes. To learn from our community we must be honest with one another and talk bluntly about how we’ve screwed things up.

Although Robin’s post is about design systems, it couldn’t be a better description of public service modernization efforts. Public discussions of digital government – on social media, in conference presentations – paint a rosy, optimistic picture that doesn’t live up to how things are actually going. This work is hard. It burns people out. And if, as public servants, we can’t talk about real problems because they’ll show our institutions or our leadership or the government in a negative light, we won’t be able to learn and grow and change.

One of the values of the US Digital Service is “Find the truth. Tell the truth.” It’s something that, as Canadian public servants, we’re particularly reluctant to do – despite appeals to be a voice for evidence in an increasingly misinformation-driven world.

Finding and telling the truth publicly is important: to counteract misinformation, to push back against vendor-driven hype, to be part of broader societal or practitioner conversations, and to help drive important internal changes. It’s not always clear how to do that, as a public servant – partly because of the unclear lines around loyalty and public criticism, and partly because there isn’t an obvious escalation path or “happy medium” between, on the one hand, saying nothing potentially-negative publicly, and on the other hand, formal whistleblowing or resigning in protest. If there’s a silver lining to Robin’s post, it’s realizing that this is a challenge for people in private sector companies too.

But it’s worth figuring out. As public servants, in any government and at any level, how can we find and tell the truth more often?

User needs, not government needs

Thu, 27 Feb 2020 17:50:34 -0800

My last post talks about how government services aren’t working. This is true in a wide variety of cases, both in the sense that the IT systems underlying them are unreliable or at the end of their lifetimes, and that people trying to use the services in question can’t successfully do so.

The perennial question is, why does this happen so often in government? It’s not a matter of people deciding to build good or bad systems and services, that if people only knew better they’d be able to implement reliable IT systems and user-friendly online services. It’s that there is a whole range of government processes and activities that take time and energy away from focusing on whether actual people can use a service or not. And, they take away teams’ ability to course correct and do things differently based on what they’ve learned.

Take the road less travelled

In Ottawa I had this poster above my desk, taken from a UK Government Digital Service (GDS) catchphrase: “User needs, not government needs”.

You can download a copy of this poster in English and French.

When you’re prioritizing what activities to work on, it’s usually not that hard to tell if something is responding to a user need or a government need. Does the activity help understand an actual person (outside of government) and how they’d use the service you’re building? Does it let particular users (like people using accessibility software) more effectively interact with your website or online services? Does it generate data that can help inform future improvements to the thing you’ve built, improvements from the perspective of actual end-users?

If it’s not doing any of those things, it’s probably solving for a government need: a presentation deck for a project oversight committee; a detailed rationale about why you need to use the cloud infrastructure you’re planning to use; a roadmap of feature requests stretching long into the future, past where you know if they’d be useful to people or not; an IT request for permission to use a non-standard tool; a report on your progress in the form of a long narrative document.

Although some of these (particularly navigating through various gatekeepers) end up being unavoidable prerequisites, none of them directly contribute to making a working, user-friendly piece of software.

One of the ironies of government IT work is that these “government needs” – cumbersome project management processes, governance and oversight committees, layers of stakeholder approvals – are often created or expanded in response to previous IT failures, even though over time they become one of the root causes of subsequent failures.

Don’t revert to what’s familiar

Gatekeepers notwithstanding, part of the reason that teams spend so much time on these “government needs” is that they’re familiar activities. Successfully designing, building, and shipping software uses different skills and ways of thinking. Writing reports and presentation decks is much more like any other part of working in government, and it’s easy to focus on the things that you’re already familiar with.

GDS’s early years were revolutionary because they really lived by this message. Their first design principle was to “Start with user needs” – with a little asterisk saying, “not government needs”. They followed that up with an unprecedented (and largely new to government) focus on design research: interviewing everyday people who used existing government services, bringing people into their offices to watch them interact with prototypes of new or redesigned services, and using those observations and insights to make changes to the things they were building.

Mike Bracken’s 2013 blog post – The strategy is delivery. Again. – does a great job of capturing how lopsided governments’ prioritization of internal needs over user needs tends to be.

Focusing on user needs – learning from people, building things that meet their needs, and continuing to iterate based on their feedback – is challenging work even without the pressing distraction of government needs. But it’s work that makes it vastly, vastly more likely that people can successfully use the things you build. And that, in turn, is what’s ultimately worth it.

Interested in reading more? Mark Headd’s Process Eats Culture for Breakfast and Peter Karman’s Digital Service is not about technology are both must-reads on this topic, published earlier this month.

Our services aren’t working

Tue, 25 Feb 2020 21:48:19 -0800

The government’s legacy IT systems have been in the news recently. There’s a great set of articles by Jordan Press, from November and February, and a follow-up radio interview that’s worth a listen. Within the government, as these articles show, there’s a growing concern that these systems – software code and mainframe computers that underpin critical services and benefit programs for millions of Canadians – could fail unexpectedly at any moment.

This isn’t a new problem:

Many of the information technology systems that the federal government relies on to deliver programs and services to Canadians are aging, and several are at risk of breaking down.

Even if systems are currently working, a breakdown could have severe consequences. At worst, some government programs and services could no longer be delivered to Canadians.

That’s from a 2010 news release from the Office of the Auditor General. Practically all of the systems identified as at-risk a decade ago are still in use today. Amid other government priorities, IT systems have never been high on the list. As the United States’ 2013 Healthcare.gov crisis shows, though, we live in a world now where technology successes and failures are directly connected to political successes and failures. Outdated and poor-quality IT systems can constrain political leaders’ ability to achieve their goals, by delaying or preventing the successful rollout of services that their citizens are counting on.

A “lack of focus on end-users”

The complicating factor in discussions around legacy IT systems (and their need for replacement) is that many of the services that these systems support don’t work well as-is. From the perspective of a Canadian trying to apply for a program or benefit, they’re often confusing, hard to navigate, easy to complete incorrectly, and involve several stages of printing off and mailing forms or dropping them off in-person at a front-line office.

This, too, has been a problem for a long time. In 2013 and again in 2016, the Auditor General raised a wide range of concerns with the quality of the government’s services to the public:

…Few of the online services offered to Canadians by departments are client focused. For example, we found online services that were difficult for users to navigate or that could not be completed from start to finish through the online channel only.

…the perception of the service is very different depending on whether you are talking to the service provider or to the citizen trying to navigate the red tape.

Over the years, our audit work has revealed government’s lack of focus on end-users, Canadians.

Government… needs to be good at service delivery to remain relevant.

In short: our difficult to navigate, user-hostile services are the ones at risk of failing. Our user-friendly services by and large don’t exist.

Two questions that are actually the same question

The maintenance and repair (or replacement) of IT systems is often treated independently from the services (for example, a Canadian applying for a benefit program) that they support. These systems might directly power online forms and interfaces, or, depending on the case, they might be several steps removed – storing data and calculating eligibility criteria for requests that come in through phone or paper channels.

The divide between conversations about systems and conversations about services is a good example of Conway’s Law – that organizations create products and processes that reflect their internal communication structures. In this case, siloed IT units are responsible for system maintenance and upgrades, while the design of programs and services happens in other parts of a department.

For a person using a service, though, the distinction is meaningless. If a service is beautifully and intuitively designed, but the systems it runs on are down for maintenance, it’s useless. If a system is up and running, but the service is a long, burdensome form that people stop filling out halfway through, then it isn’t helpful either.

The two questions worth asking are: does it work?, and, can people use it successfully?

As the risk of failing IT systems has finally started to be recognized across government, I’m worried that people will only ask the first question, and not the second, more important one.

(“Successfully”, it’s worth saying, is doing a lot of work in that sentence. How many people can find and use a service? Does it take them an unreasonable amount of time to get through? How likely are people to make it all the way through to the end? Are particular groups of people – using accessibility tools, for example, or on low-bandwidth network connections – more likely to find a service difficult or impossible to use? Each person’s determination of whether a service is successfully usable or not can vary.)

IT administrators are often content to stop at, “does it work”. Replacing legacy IT systems is difficult, and it might seem easier to make the bare minimum of changes (porting a mainframe system to a slightly less old mainframe; emulating it in an expensive, proprietary emulator for 1960s hardware, etc.). Doing that may keep a system working for a bit longer, but it doesn’t make it possible to make the services it runs more user-friendly, more flexible, or more adaptable to policy and program changes that political leaders may want to bring about. Investing in more foundational changes that make it easier to change, more quickly, in the future can be a hard sell, but worth it.

The test for public services in 2020

Surprise: it’s actually the test for public services in 2014 but we’re just catching up. The test is, can I complete this service online, on my phone, from start to finish, at two in the morning? The inspiration is the UK Government Digital Service’s 2014 redesign of the Carer’s Allowance, a UK government grant program for people who care for elderly or sick family members. After the service was made available fully online, GDS found that there was a daily spike in traffic around 1 or 2 in the morning, when people who had been caring for their relatives all day finally had a chance to apply for the program. If they had to phone a call centre or apply at an in-person office – as was previously the case – they would have had to take time away from caring for their loved one.

In 2018, a panel of Canadian technology industry luminaries wrote a report about making Canada successful in a global digital economy. It includes a challenge to the Government of Canada to digitize every public-facing service and make it available online and mobile-friendly by 2025. Echoing the Auditor General’s reports, they write:

Every government service needs to be delivered online to eliminate the need for in-person visits to government offices and the printing, scanning, and mailing of government documents.

The way our government is currently delivering services to Canadians is no longer appropriate for our times.

Doing this in practice requires changes both to how we think about managing IT systems, and to how we design services themselves. Ultimately, those are two parts of the same question, and whether we succeed or not has profound consequences for people’s everyday lives.

Why this matters

Making services that people can actually use matters, because it’s the most vulnerable people in our society who get burdened with the most bureaucracy. This work matters, because people aren’t receiving the benefits and services they’re already eligible for. It matters, because – although the government does a vast range of important things that aren’t service delivery – services are what people see firsthand, and the quality of the services they receive can directly affect their trust in government. It matters, because a whole range of middlemen – from tax advisors and immigration consultants and customs brokers, to Member of Parliament offices running passport clinics, to software companies advocating to be the front door to government services – are a symptom of the ongoing failure of the government to provide services that everyday people can successfully use on their own.

We owe it to everyone to build public services that they can use. I’d like to amend my test criteria to add: a good public service is one that I can complete online, on my phone, from start to finish, at two in the morning, in less than 10 minutes. At my old company, one of the hardest things was convincing clients that the 30 minute research surveys they wanted to do were too long. No one would make it to the end. If you want people to successfully complete something (a survey, a form, an online transactional service) you have to be conscious of the effort and cognitive load you’re putting on them. It’s a big part of inclusive design, which is finally starting to get some important recognition.

How many government services meet that test: fully online from start to finish, that you can do on a smartphone any time of day in less than 10 minutes? I can only think of one, out of the more than a thousand unique services the federal government provides.

We’ve got nowhere to go but up.

Perils of standardization

Tue, 04 Feb 2020 21:34:46 -0500

If you work in government IT, you’ve probably heard this before. “We’ve got one standard database product.” “We’ve standardized on this programming language.” “This software is our standard for case management systems,” and so on.

This isn’t unique to government, and it isn’t intrinsically a bad thing. Some standards are incredibly valuable; for example, there’s only one right way to write date formats. Software standards that improve a user’s experience (for example, using single sign-on instead of having dozens of separate login accounts) are a great choice.

But, standardization often plays an outsized role in technology strategy or enterprise architecture. Standardizing (or consolidating) on a single set of systems, or on a single product for a specific use-case, or on a single vendor, becomes a goal in itself – often without recognizing the tradeoffs that end up being made as a result. In this blog’s spirit of being gently counter-cultural, here are some downsides to standardization efforts.

One size all fits nothing well

In conversations about enterprise software (that is, software marketed at large organizations like multinational companies, universities, and government institutions), poor usability comes up pretty frequently. These are software products that are expensive, incredibly complex, do a lot of things, and are somehow almost always very, very difficult to use. There’s a great Twitter thread from Arvind Narayanan about Blackboard, an enterprise courseware product used by a lot of universities and colleges. Arvind writes,

[Blackboard is] actually designed to look extremely attractive to the administrators (not professors and definitely not students) who make purchase decisions. Since they can’t easily test usability, they instead make comparisons based on… checklists of features. 🤦🏽‍♂️

And that’s exactly what’s wrong with Blackboard. It has every feature ever dreamed up. But like anything designed by a committee, the interface is incoherent and any task requires at least fifteen clicks (and that’s if you even remember the correct sequence the first time).

There’s a lot of reasons why “everything and the kitchen sink” is a common philosophy for enterprise software, especially when it’s sold to governments. Government procurement is difficult and time-consuming, so buying one product that does “everything” (instead of several separate products) is appealing. Checklists of features, as Arvind describes, are easier to communicate through RFP responses (in long paper documents) than the usability or intuitiveness of a software’s interface, or how happy or frustrated people are when they use it. And, complicated review processes for security and privacy mean that it’s easier to just use one product for as long as possible.

The downside is that – as a result – these “one size fits all” enterprise software products are hard for people to navigate and use, which makes people’s work more frustrating and less efficient. These products often also need to be extensively customized in order to work for the organization buying them, which can be time-consuming and introduce unexpected and hard-to-detect software bugs.

A placeholder for more informed technical discussions

Over time, it’s easy for standardization – as a goal in itself – to replace more informed discussions about the merits and downsides of different technology options. In environments where there is limited technical expertise (a frequent issue in government institutions), standardization is a simple enough concept that it can become a stand-in for actual technical discussions. Making the case for a particular technology tool or framework instead of another can quickly reach a level of complexity that decision-makers aren’t comfortable with. Asking “is it standard?” gives the appearance of a technical discussion without actually providing it.

In situations like this, the best approach is to learn to ask better questions. Does using one technology instead of a different one speed up people’s work, or slow them down? Does it make a service more accessible? Does it make it easier, or harder, to reliably get data in and out of a system? These are all more important questions – when it comes to the outcomes that a technology decision should achieve – than “is this technology the standard”.

A barrier to continual change

Governments and institutions that decide on widely-held standardized software products aren’t able to easily change these when the products get out of date. Standardized technology decisions can remain in place for many years, even as the technology industry moves past them. Even if the decisions were thoughtfully made at the time, they almost always remain in place long past the point where they add value. Standards end up staying in place much longer than they should, because removing or changing them takes more political capital than anyone is willing to spend. Even if the most cutting-edge technologies were selected – for a standard database product, standard programming language, standard case management system, or standard software for any other purpose – it’s just a matter of time until they’re a detriment instead of a benefit.

Over time, as these standards get more and more out of date, they add increasingly severe side effects: preventing teams from being to experiment with new technology choices, introducing security vulnerabilities as products get end-of-lifed by manufacturers, and discouraging expert talent from wanting to work for your institution. If you only use really old database products – or, for that matter, if you only build things in Java or ASP.NET – you’re not going to be able to hire the talented software developers and technology experts you need.

No standard can keep up with the pace of change in technology, especially in the web development world. The main takeaway for government institutions is: don’t mandate specific systems. As Marianne Bellotti writes,

No matter how thoughtfully written or well researched a policy is someone, somewhere in government will create failure from enforcing it. It is inevitable.

The plot twist is: standards can be a force for good, when they equip organizations to be better able to keep pace with change instead of slowing them down. The UK’s Digital Service Standard and Technology Code of Practice did this really well, by introducing open source requirements and shorter maximum lengths for IT contracts. Standards that keep your options open and avoid vendor lock-in can be tremendously valuable.

Instead of mandating specific software products and systems, mandate ways of working that lead to good outcomes. When it comes to software choices, government institutions should mandate interoperability, full data import and export capabilities, and other approaches that keep their future options open.

Like this? Read Dan Sheldon’s Government IT Self-Harm Playbook from 2016.

Introducing agile to large organizations is a subtractive process, not an additive one

Tue, 28 Jan 2020 18:16:09 -0500

Working in technology in government, the word “agile” comes up a lot. Usually it’s in the context of agile software development, but it gets applied pretty broadly to other parts of digital government work. I get emails on a semi-regular basis from companies pitching agile training certifications or agile coaching.

“Agile” gets mentioned enough that can sometimes seem like it applies to everything: is anything not agile? In that sense, it’s almost used as a synonym for “good”, which isn’t particularly useful. But there’s a deeper meaning behind it that’s easy to miss, that’s particularly relevant to organizations that have a lot of long-established processes.

What is agile?

In the software development world, “agile” as an idea originated from the Agile Manifesto, written in 2001 by a group of software developers. They were disillusioned with how IT worked in large companies at the time. The Agile Manifesto laid out a simple set of values to do software development differently:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In the words of the authors (on a beautifully retro website), “while there is value in the items on the right, we value the items on the left more.” It’s a call to software developers – and those they work with – to focus their time on things that matter.

Agile is usually described as the opposite of “waterfall” software development, where the planning and eventual development of a piece of software follows a linear path from concept, to business planning, to requirements and specifications documents, to implementation. Waterfall software development has been abandoned by most of the technology industry, but is still widely used in government and other large organizations.

Don’t just do more things

Working in government technology today might feel similar to how the authors of the Agile Manifesto felt back in 2001, where their companies spent a lot of time on detailed waterfall project planning requirements and reports at the expense of building good software.

Since that time, “agile” has become the byline of a much larger industry – of project management consultants, training programs, software tools, and other efforts to do software development differently. When you hear terms like “scrum”, “extreme programming”, “kanban”, “lean software development”, and others, these are all techniques and approaches that evolved out of similar origins as the Agile Manifesto.

In many government teams, there’s a lot of ongoing interest in “being more agile” or “becoming agile”. This often translates into doing some of the activities that feel like staples of agile software development: daily standups, tracking tickets in JIRA, putting a lot of post-it notes on walls. There’s a whole industry peripherally around government that encourages this, offering training programs and certifications in various agile-themed approaches.

Doing these activities can be motivating, especially for teams that want to modernize how they work – they’re not bad as a first step. But adding these things (daily standups and JIRA tickets, for example) without removing established processes that slow a team down is a recipe for frustration. Being agile means choosing one approach (say, working software) over another (comprehensive documentation, following the Manifesto values above). It’s about deliberately prioritizing what you spend your time on. Just adding more things to do undoes the benefits of agile work.

What this looks like in practice

The IT Strategy Team at ESDC wrote a phenomenal blog post a month ago titled, “We are inadvertently promoting risks in IT”. It describes some of the project management policies and processes in use in their department:

In the PMLC [project lifecycle framework], an IT project is typically expected to produce between 21 and 39 project management artefacts, would require between 48 and 60 project management activities, and would involve 16 stakeholders. Note that in the 16 stakeholders only 5 of them are from the IT Branch.

This heavy project governance process, though it is intended as a means to reduce risks, ends up promoting them instead. Given that the effort of making small IT changes do not warrant the effort of going through this burden, we end up waiting. We wait until we have enough small changes piled up to justify the effort in seeking permission to make them. We inadvertently end up promoting feature bloat.

In organizational environments like this one, adding agile practices without removing some of the traditional waterfall activities isn’t likely to lead to significant change. Doing agile training courses, getting certified, and doing daily standups – but then still having to produce almost 40 traditional project management artefacts, each with dozens or hundreds of pages – isn’t a recipe for success.

In some ways, this is a symptom of how people implementing a process in government often don’t have the authority to change it. It’s easy to start doing daily standups, but to stop doing burdensome project management exercises depends on someone else (often several layers up a hierarchy) giving you permission to work differently.

For people in those leadership positions, several layers up, one of the simplest and most valuable things they can do is to remove established organizational policies and procedures that impose or reinforce waterfall-style ways of working. In most government institutions, there’s no shortage of those.

Why it matters

Adding agile activities but not getting rid of waterfall practices ultimately leads to a lose-lose situation. People get cynical about the agile activities (all the post-it notes, for example) that feel showoff-ish when you’re still only able to ship your software once a year. If you really do have to do all the waterfall practices anyway, then the agile activities can feel like a waste of time. It’s easy to revert to the mean, or to what feels familiar.

In Digital Transformation at Scale (the seminal book on digital government today), the authors touch on this:

As agile has grown in popularity, it has spawned a wide variety of imitators, many of them combining bits of agile and bits of waterfall. ‘Wagile’ doesn’t offer the best of both worlds though; you won’t get the thing you planned on the date you planned it, and you won’t get something that meets user needs either.

Ultimately, they write:

Waterfall works much less well in a landscape where people’s needs and the underlying technology are constantly changing. Agile is a rejection of applying false certainty to delivering policy with technology.

Technology changes very quickly. People’s behaviour, more importantly, is impossible to predict in the way that waterfall software requirements expect. It can only be observed and learned from, and your software iterated on in turn. To do that, you need to ship frequently, test with real users, learn from their feedback, and keep shipping continued improvements. And to do that, you need to stop doing the waterfall things that hold you back.

If you’re interested in learning more, be sure to read “Detecting Agile BS” – a shockingly excellent government publication – from the US Defence Innovation Board, or their other concept papers here.

Principles for blogging as a public servant

Tue, 21 Jan 2020 18:43:47 -0800

If you’re a public servant who is thinking about blogging about your work, you should do it! I say that with more enthusiasm than credibility since I only, well, started a few months ago. Public servants across Canada and around the world have been doing this for years, and I really appreciate how much I’ve been able to learn from other people writing about their perspectives and experiences in government.

Blogging and talking about your work on social media has become a lot more common in the past few years. “Working in the open” has become a shared goal of public servants around the world. As a federal public servant, though, it’s still sometimes hard to know what you are or aren’t allowed to talk about. There’s a few principles that apply pretty generally here:

Be non-partisan. In Canada (like in the UK) public servants are non-partisan and politically impartial, and so avoiding statements that promote or criticize politicians, political parties, or their views is important. If something you wrote would make politicians and political staff wonder if you’re non-partisan or not, it’s probably not a good thing to write.
Don’t announce things that aren’t public yet. Unless you’re an official spokesperson for your department (in which case you’re probably too busy to write a personal blog on the side) you shouldn’t reveal things that haven’t been announced yet. Your personal blog shouldn’t be the channel by which the public or journalists learn about brand-new government programs, for example. But, if you’re trying a new approach to how you work, or doing some experiment that contributes to an already-announced program, I’d say, go for it. If your team’s work or program was announced on some press release somewhere and no one even noticed, all the more reason to blog openly about it!
Don’t publicly criticize the government. This comes from the duty of loyalty that forms part of the values and ethics of the public service, and is related to the non-partisanship principles of loyally implementing the decisions and priorities of the elected government of the day. The typical interpretation is that you should raise concerns internally, and that (outside of situations where the government is breaking the law or risking health and safety) publicly raising direct criticisms of government policies and decisions can be a reason to fire you as a public servant. Your personal blog probably isn’t the best channel for public whistleblowing.

Working in the open, with unbridled positivity only

That last point – to not publicly criticize the government – is probably the most complicated one. Uncertainty around what constitutes public criticism, or where the line is between acceptable and getting-fired-worthy criticisms, is one of the biggest challenges for public servants that want to talk openly about their work.

One of the consequences of this that you’ll see often is how – as more and more federal public servants talk about their work on social media and blogs – the consistent theme is unbridled, relentless positivity. Enthusiastic reactions to meetings. Excitement about upcoming or recent events. Great conversations with colleagues. Reflections on all the good parts of recent work experiences you’ve had.

People that know me know that I am all about unbridled positivity. But there’s a downside to the unstoppable positivity of most public servants’ social media conversations. A few exceptions notwithstanding, we’re not having honest, frank, public discussions about things that are broken within the public service. And let’s be real, there’s a lot of things that are broken. As a public servant, though, it’s hard to know how to talk about these – and in an environment where it’s really hard to get fired, the real possibility of getting fired for a violation of the duty of loyalty is definitely a barrier to having those conversations.

How to criticize a thing that you love

I’m really interested in having these conversations because I really want government to be good. I really love the public service as an institution, and as a vocation. I want our public service to be the best in the world. I don’t think it is today. I want us as public servants to be really, really good at improving the lives and well-being of people across Canada. I don’t think we can do that as well when we don’t have open conversations about what we could do better.

None of this is meant to discourage public servants today who share enthusiastic, positive anecdotes from their work. There’s so much we can learn from things that are going well, and working in the open (on blogs or social media) helps mainstream the concept of public servants talking about their work at all, which is still relatively new to an extent in Canada.

In the spirit of more frank conversations that (hopefully) still don’t get us all fired, here are some principles for criticizing a thing that you love. That thing being, government and public sector institutions. These are just my own principles, but maybe they’ll work for you too:

Criticize systems, not people. Don’t single out individual people, tempting though it may sometimes be. Often, people’s behaviour is the result of the environment and incentives that we operate within – the game, not the player. Criticize those environments and structures and incentives, and treat the people within them with empathy and kindness.
Avoid routine or instinctive criticisms. Does your colleague write emails in a weird font? Are people from that one team always late for meetings? Criticizing routine things – or criticizing, well, everything – isn’t necessarily the route to fundamental changes in the public service; it’s probably worth saving your social capital for bigger-picture things.
Don’t bash small positive steps for not going far enough. In environments where change is hard, it’s sometimes tempting to call people out for making a tiny step in the right direction when a large one seems much more worthwhile. This can happen sometimes in activism and social change communities, and it makes it hard to bring new people onboard to do what they can to make a difference. As a good friend would say, moving a mountain an inch is still worthwhile. Celebrate the small wins, even if they’re just a first step.

The approach I want to champion is: openly criticizing things that are systemically broken, while still acting with the respect and integrity that public servants are meant to embody. I want this blog to be an experiment in doing that. If there are times when it crosses the line, I hope that people will let me know – and that, in turn, this will be a useful way of learning as a community where those lines are. If I can help create space for more people to have open conversations about how to make the public service better, awesome. I have a lot of unbridled positivity for that.

Public service tech tip: Please use headings

Tue, 14 Jan 2020 18:06:44 -0800

If you’re creating documents (which, as a public servant, you …probably do often), one of the most important things you can do is to use real headings. You’ll often see documents that are divided up by bolded or capitalized or underlined or slightly larger text, done by hand. That’s very 90’s. It’s very gauche. If you want to make great documents, please use headings.

Headings – real headings – are important because they tell people what the structure of your document is. Pretend headings (bolded or resized text) don’t include the information that tells your word processor where new sections of a document are. Using real headings means that people using screen readers or other accessibility tools can easily navigate and jump through your document. It also means that if your document is ever converted into a webpage or some other kind of format, it will already be properly structured and ready to go.

The other benefit of headings is that they let you format your document really consistently. You can make changes to the style of the headings you use, and instantly update them throughout your entire document. It’s a game-changer – once you start using them, you’ll never go back.

Adding headings in Word

These examples are for Word 2013 on Windows, for other versions see Microsoft’s documentation here.

To add a heading in Word, place your text cursor on the line you’d like to make into a heading. Then, click on the small arrow in the “Styles” panel and choose the heading you’d like.

Once you get used to it, you can do this much faster by using keyboard shortcuts. To add a “Heading 2”, for example, hold down “Control” and “Alt” on your keyboard then push “2”. For a “Heading 3”, it’s “Control + Alt + 3” and so on.

To change a line of text back from a heading to a normal paragraph, the keyboard shortcut is “Control + Shift + N”.

Customizing how your headings look

Let’s be real, the default Microsoft Word headings aren’t great. They’re blue and weird and would look out of place in any government document. It makes you wonder if whoever made these styles the default may have accidentally set back Word accessibility by a decade.

Fortunately, you can change them! The most reliable way of doing this is:

Set your heading text to the desired heading number (e.g. “Heading 2”), and briefly hold your tongue while it’s blue and weird
Change the font colour back to black, change the size (as needed), and make it bold, italic, etc. as you see fit
In the styles panel, right-click on the same heading number (“Heading 2” in this case) and click “Update Heading 2 to Match Selection”

That’s all you need! Then, repeat the same steps for other heading numbers (Heading 1, Heading 3, etc.). You can customize these even more by right-clicking on the heading number again and clicking “Modify” (which brings up a screen with more options) but you’re good to go with just the steps above.

Using these steps (setting the text to the heading you want first, then modifying the font styles and so forth) helps make sure that you don’t accidentally lose any extra information about where the heading fits into the overall structure of the document (accidentally turning a Heading 3 into a Heading 2, for example).

What’s great is that you can use these same steps to change each heading style down the road, and Word will automatically update all the headings throughout your document.

Saving your heading styles in a Word template

Once you’ve got headings that you’re really happy with, you can save them to a Word template file. That way, you don’t need to create or customize them over and over again.

My approach to this is the following:

Create a new, empty Word document
Customize all the headings I use (typically from Heading 1 to Heading 4), by making sample lines of text for each heading
Customize paragraph text (and update the style using the same steps as above), add page numbers to the footer at the bottom, and do any other page formatting changes
Delete all the sample text from the document (except for the page numbers)
Make the first line of the document a “Title” or “Heading 1” style, with no text in it
Click “File > Save as…” and save the file as a “Word Template (.dotx)” file, in the default templates folder (on my computer, it’s “Documents / Custom Office Templates”). Give it a name you’ll recognize, like “Sean’s template” (replace that with your name, of course!) Don’t forget to change the type to “Word Template”:

To create a document using your new template, click “File > New” and you’ll see the template in the list on the right beside “Blank document”. Choose your new template and you’re good to go!

You can create custom templates for different kinds of projects you work on, and each one can have different styles.

What headings do I use?

When you’re new to headings, it’s hard to know which ones to use. The main thing is to be consistent, and to use headings in a way that shows the structure or hierarchy of the information in your document. Wright State University has a really helpful backgrounder on headings, and uses the following example:

A Guide to the Babel Fish (Heading 1)

What is a Babel Fish? (Heading 2)

Physical Appearance (Heading 3)

Decoding Mechanism (Heading 3)

The Babel Fish in Philosophical Arguments (Heading 2)

Oolon Colluphid’s Arguments (Heading 3)

Argument for (Heading 4)

Argument against (Heading 4)

Agrajag’s Argument (Heading 3)

You can see how the headings are structured in a sensible, nested way. (You could think of a Christmas tree, or Babushka dolls, or a series of triangles – whatever metaphor works for you!) You wouldn’t have a Heading 2 “inside” of a Heading 3, for example.

Sometimes people tend to choose headings because of how they look – they want the particular font size or style associated with it. Don’t do that; think about the structure you want instead, use the headings that match that structure, and then change the font size or style of the headings to suit your needs using the steps above.

One of the big questions is whether your document should start with a “Title” or with a “Heading 1”. Here’s some quick rules of thumb:

With webpages (or with documents that are meant to become webpages) it’s very straightforward: there should only be one single “Heading 1” on a webpage, so start with a Heading 1 and don’t use the “Title” style.
With Word documents, if your document is short- or medium-length, start with a “Heading 1” as well and use “Heading 2s” and so on for each of your sections.
If your Word document is a thesis, a long report, or a book with multiple chapters, you can start it with a “Title” and use “Heading 1s” for each chapter, for example.

In most everyday cases, though, I’d suggest starting with a “Heading 1” and not using the “Title” style. Remember, if you don’t like the font size or style that each of these use, you can easily customize them.

Overall, the important thing is to keep a consistent, nested structure, so if you use a Heading 1 to start off your document, don’t add other Heading 1s later in your document. Use Heading 2s to start each section, Heading 3s for any sub-sections, and so on.

If you’re writing a longer document and starting with a “Title”, then the same principle applies – there should only be one “Title” in your entire document, and each section or chapter would then start with a Heading 1.

Whichever one you use, the Heading 1 or Title that you start with becomes the top of the hierarchy (or top of the metaphorical Christmas tree), and everything else follows below it. It may sound complicated at first but you’ll get the hang of it fast.

Bonus: use paragraph spacing, not empty linebreaks

If you want to become a heading superstar – and do a huge favour to anyone turning your documents into webpages down the road – this last bonus tip is for you. It’s about normal paragraphs, as it turns out, not headings.

To create space between paragraphs, people normally just hit “Enter” twice to leave a blank space. The problem with that is that, if someone were to read your document with a screen reader, they’d keep being told about the blank lines – interrupting the flow from one paragraph to the next.

The way to fix this is to add “paragraph spacing” after each paragraph. You can do this from the “Line spacing” dropdown menu,

…or from the Paragraph options box that you access by right-clicking on your text and choosing “Paragraph”.

I typically use something like “10 pt” after each paragraph, and “0 pt” before each paragraph. Choose what looks like a normal space and you’ll be fine.

After you’ve done that, and while your text cursor is still in the same paragraph, go up to the Styles panel (from above), right-click on the “Normal” option, and click “Update Normal to match selection”. That will apply your new line spacing to every paragraph, including future ones that you type. Now, you don’t need to hit “Enter” twice between paragraphs. You’re good to go!

Sometimes this kind of line spacing can confuse people, when they really want to make two lines of text that are next to each other (for example, for a signoff or signature and job title at the bottom of a document). In those cases, you can use “Shift + Enter” on your keyboard (hold Shift and push Enter) to add a line break that doesn’t have the extra line spacing attached.

When you customize your heading styles (using the instructions above) and save a reusable template file, adding a Normal paragraph style with line spacing is a great addition. You can use the same line spacing options to customize the space around your headings. It’s a whole typographic art. The more you know!

Learn more

A number of universities have great websites that discuss accessibility best practices in Microsoft Word. This includes how to create good headings, along with other important steps (alternative image text, using tables and lists properly, and using Word’s built-in accessibility tools):

Another great resource is the WebAim guide to creating accessible documents in Word.

If you use other tools (Google Docs, Pages for Mac, etc.), you can use similar steps to add real headings to your documents. Let me know if it’d be useful to add these as a future tech tip, and if you have any feedback, don’t hesitate to reach out!

Shipping

Fri, 10 Jan 2020 20:02:44 -0800

One of the terms that comes up often in digital government work is “shipping”. In a word, it captures a lot of what it means to improve government IT, and why it’s difficult.

What does it mean?

When you think of shipping, you might think of Amazon delivering a package to your house. It’s not a bad comparison: there’s somewhere where the package came from (a factory, a wholesaler, an Amazon warehouse), there’s some steps involved in between (maybe a cargo ship and Canada Post), and there’s you – the person receiving the package at the end of the line. Something was shipped successfully when it made it from where it started (without getting lost or breaking!), to you, where you can benefit from it.

In the context of government work, the metaphor is basically: something has “shipped” when it has made it from inside government, to outside. If you can access or use a government thing, as an everyday member of the public, it’s shipped!

What’s the big deal with shipping?

There’s a reason that shipping is a catchphrase of digital government teams around the world. The bottom of the original 18F website said, “Always be shipping”. GDS’s unofficial motto is, “The Strategy is Delivery”. They have awesome posters with that written on it.

The reason these teams define themselves using shipping-related catchphrases is that shipping, in government, tends to be a rare and complicated thing.

In government environments, it’s very comfortable and very safe to write planning documents, strategies, IT requirements, and other internal reports. Making something that will reach the public – and getting all the way through a daunting process of approvals and reviews in order to do so – is much more difficult. Even for things that, from the very beginning, are meant for public consumption, it’s common for them to get derailed or stopped before they make it out the door.

Why is shipping so hard?

When things interact with the actual public, it’s easy for people in government environments to get nervous. Whether it’s an IT team putting together a new service, or a communications team writing a new blog post or publication, when a thing is heading towards the door it’s easy for an entire department’s “immune system” to react. Examples of this could be,

A separate Quality Assurance (QA) review of a service, step by step
Comprehensive project management documentation requirements
Committee approvals (at several layers) to get permission to launch
Privacy and security assessments, often undertaken by separate teams
Communications plans that are scheduled separately from the thing itself
A formal launch by a minister or other political representative
Deployment of the thing onto production infrastructure, often done by a separate team or separate department

All of these steps tend to kick in as a thing gets close to being ready for the public – all intended to minimize risk and make sure that there isn’t any kind of negative reaction when the thing goes out the door.

The downside, though, is that – taken together – these steps make it difficult and time-consuming for a thing to make it out the door at all. Worse yet, it places a heavy burden on the original team, which has to navigate through all of these processes (sometimes several times over) to be successful. Meanwhile, the public service counterparts responsible for a given step might only be focused on or aware of their own process, and not how it contributes to a larger accumulation of complicated steps.

Imagine if, each time Amazon mailed you a package, it had to go to a review committee to decide if it could mail it or not. It probably wouldn’t ship packages nearly as often as it does today.

Why does it matter?

When things do finally make it out the door, after getting through the long and complicated gauntlet above, they’re often several years out of date. Or, they might not be user-friendly enough for the people that were supposed to benefit from them to use them.

There’s a really important reason why digital service teams focus on shipping, and on shipping more effectively, more easily, and more frequently.

Getting something from inside to outside government means that you can start getting feedback from the people that are ultimately meant to benefit from what you created. Not just from internal stakeholders, not just from other public servants, and not just from hand-picked members of the public in an advisory or consultation group, valuable though these groups may be. From the actual public, which (for services and other products meant for the public) is the most authentic and effective source of feedback you can get.

A recent 18F blog post captures this really well. Rather than a product launch being the end of the journey, it’s actually just the beginning:

A product team learns. It learns about the needs of its users (through user research) and about the tech choices and tradeoffs involved in meeting those needs (through software engineering).

“Keeping it running” post-launch should not be the goal. Your software launch is an opportunity to start getting feedback from users and making improvements based on what you learn. In other words, it is a starting point.

How to make shipping easier?

Technology companies like Shopify ship changes to their live services hundreds of times a day without a dedicated QA division. They invest a lot of time and effort in tools that make shipping reliable and easy. That frequency is noticeably different from government IT groups, who typically publish updates a few times a year.

Getting there involves a lot of changes to how governments typically operate – both cultural changes and operational changes. Moving away from all the challenging steps above (or, for the ones that add value, figuring out how to do them more quickly and effectively) is difficult.

Here’s a few potential approaches that can help. Depending on what you work on (online services, communications products, policy documents) different ones might apply:

Build QA directly into your development process, through things like linting, automated testing, and continuous integration
Adopt agile software development techniques, and stop doing traditional project management documents
Get executive support in advance to shield your team from various committee processes
Seek delegated communications authority rather than going through a central comms division
Use personal blogs and social media to talk about your work, while you wait for more formal communications channels to come online
Reduce internal approval layers as much as you can
Turn any unavoidable approval processes into templates that you can complete quickly
Use cloud infrastructure that your team controls directly, to avoid having to wait for outside teams
Publish your software as open source on GitHub so others can learn from it even if it hasn’t launched yet
Write “infrastructure as code” to make system administration work as automated and consistent as possible
Bake security and privacy best practices into your work from the start

If you’re curious what this looks like for IT infrastructure, Pete Hodgson’s “Hello, production” post is a great place to start.

Try as many of these as you can; any step that helps get things you work on “out the door” is a step in the right direction. It takes time to get to the level where you’re shipping, as the metaphor goes, hundreds of packages a day. But you can think of the small steps like, getting an envelope into someone’s mailbox. It might not make you a shipping mogul, but it’ll probably still make their day.

Archived tweet from Mark Headd

Bridging the technology-policy gap

Thu, 02 Jan 2020 20:18:23 -0800

Nicole Wong wrote a great piece last month titled, “Building a Tech Policy Movement”. It captures something that really resonates: there’s an urgent need for people who are fluent in both technology and public policy, and a real shortage of those people.

Back in 2017, I gave a presentation at a Policy Ignite workshop titled “Bridging the technology-policy gap”. It made the argument – as anyone reading this will be familiar with – that technology is changing more quickly than governments can keep pace with, and that citizen expectations are changing with it. Nicole’s article makes a detailed case for why this matters:

The need for modern technology in government is clear. Last year, our federal government spent almost $96 billion on IT. According to federal agency Chief Information Officers, about 60% of the projects today are at risk of being either over budget or behind schedule. The Social Security Administration, which pays $1 trillion in social security and disability benefits to 70 million Americans, relies on 60 million lines of COBOL, a computer language that was created in 1959. That is not merely inefficient — preventing us from taking advantage of things like open source databases and the scaling capabilities of cloud computing — it is clearly unsustainable. There are actually a diminishing number of programmers in the workforce who even know how to maintain this code. And that failure of our infrastructure and the modernization of our tech workforce puts the benefits of 70 million Americans at risk.

Our technology priorities reflect our policy agenda. If we can order a gluten-free chocolate cake on our mobile phone while sitting in our living room and have it delivered in an hour, then we should be able to help a single mother get food stamps without having to take a day off of work to fill out paperwork and stand in line at some government office with limited hours.

Addressing this requires people who are well-equipped to dive into deep conversations about technology implementation, and about public policy and government operations. What continues to stand out is how few formal paths there are to end up at the intersection of technology and public policy.

In my case, I ended up here by accident: growing up interested in political science in a family of engineers and teachers, and being introduced to computer programming by my older brother when I started high school. Studying public policy, and then working professionally as a software developer and product designer. In my current work today – working in policy on a digital services team – I’m perpetually grateful for the people and things that set me on this path. Friends and colleagues working in the same field have similar stories: chance introductions, fluke, or circumstances that connected them from technology to policy work, or vice-versa.

Very few academic or professional programs make this connection deliberately. In Canada, the number of public administration researchers working on digital government or technology topics is incredibly small. Prof. Amanda Clarke at Carleton and Prof. Justin Longo at Johnson Shoyama do stand-out work. Outside of public admin, a handful of outstanding professors do research on topics that intersect with policy and technology: Prof. Elizabeth Dubois, in uOttawa’s communications department; Prof. Tracey Lauriaut, in Carleton’s school of journalism and communication; Prof. Ron Deibert at the Citizen Lab in Toronto. A small number of digital practitioners teach courses on the topic: Sameer Vasta, at the University of Waterloo; David Eaves, at Harvard Kennedy School in the United States; and Gabe Sawhney and the Code for Canada team at Ryerson’s school of continuing education.

The courses that do exist are, by and large, recent developments. Most public policy grad school programs (including the one I attended) do not have any technology- or public sector IT-related courses. Computer science courses, likewise, do not seem to have any courses on how government works. Outside of the few possibilities above, no one is teaching public policy students how to be technology-savvy, or teaching computer scientists and IT specialists how to be government-savvy.

In a recent (excellent) publication on digital government units, Prof. Amanda Clarke points out how little public administration research has focused on these teams or digital government topics more broadly:

Outside a few recent and important contributions, the public management research community has failed to respond to these questions. To date, we know very little about what Digital Government Units are, whether they are worthy pursuits for governments struggling to reinvent themselves for a digital age, and most importantly, how they are altering, and could alter, public sector governance more broadly.

Public sector organizations the world over are struggling to keep pace with the pressures of governing in a digital context. Digital service failures abound, and citizen trust in government continues to wane … it is no longer acceptable for the public management community to ignore digital technologies and their role in contemporary governance.

The silver lining on all of this is that things are beginning to change; the researchers and practitioners above are connecting technology and policy in new and important ways. A new generation of public policy students (whose lives have been immersed in technology since childhood) is joining the public service. The importance of this work is being more and more widely recognized across governments.

And maybe most importantly, it’s fulfilling and exciting work. Being someone who helps bridge the gap means being part of fascinating conversations every day – about both technology and policy. It means helping deliver better services, that improve people’s lives and well-being. And it means reacting to technology-driven changes to society, and helping make sure that governments remain relevant and effective.

Nicole’s article closes by saying that, as technologists (and, I would add, as public policy practitioners),

…it is our responsibility to care for our future, to insist on being part of its development, and to take seriously technology’s role in our lives, our communities, and our governments.

If you’re interested in chatting about this – or about how to get started in the technology-policy field – don’t hesitate to reach out!

Suggestions for the next GC CIO

Thu, 26 Dec 2019 20:32:27 -0600

With a new Minister and new Mandate Letters, it’s an exciting time to be working in digital government in the federal government. Efforts to make the government more effective and more human-centred are gaining momentum, and it’s really refreshing to see the level of enthusiasm and ambition that people across the federal government are putting into this work.

Ambitious digital government efforts depend on an environment where public servants can use modern technology, learn from users, and quickly iterate and deploy improvements to services. That’s a pretty dramatic departure from how federal government IT has historically operated. In the federal government, a lot of these changes – to policies, procedures, and standard practices – rest with the Office of the Chief Information Officer.

The previous GC CIO was an enthusiastic proponent of change in government, and his successor has led the OCIO team with a lot of thoughtfulness and care. With a new GC CIO likely arriving in January, it seemed timely to put together a “new year’s wishlist” of suggestions – ideas to help put wind into the sails of digital teams across government.

Low-hanging fruit

Buying cloud services on a credit card. The government’s 2018 “Cloud First” strategy (inspired by similar approaches in the US and UK) recommended that departments use public cloud providers and software-as-a-service (SaaS) products as their first choice. In many cases, credit cards are the only way to pay for SaaS products. Uncertainty around doing so (and accepting products’ standard terms of use and liability conditions) has held back a number of departments from following the Cloud First strategy. Being instructed to use cloud services without being told how to pay for them has also encouraged teams to use the free tiers of products, which often have fewer security and user administration or data export features. Explicitly stating that departmental teams have permission to buy low-cost cloud services on departmental credit cards (and accept commercial terms) is an important next step.
Deprecating Internet Explorer 11. The GC CIO is responsible for officially instructing government departments to retire outdated software, through IT Policy Implementation Notices. In 2015, an ITPIN set an end-of-life date for older versions of Internet Explorer. This should be done as soon as possible for Internet Explorer 11, which Microsoft itself no longer recommends, in favour of Chrome, Firefox, or Microsoft Edge. IE11 doesn’t support many modern websites that public servants regularly use, and introduces security risks that will only increase as time goes on.

Medium-term

Switch from the Open Government License to a Creative Commons license for open data. The federal government’s open data and information is released under the Open Government License, a Government of Canada-specific license (overseen by the GC CIO) that allows for reuse but isn’t fully compatible with other open source and copyleft licenses. Officially switching to an internationally-recognized Creative Commons attribution license would make it easier for counterparts in other governments, the non-profit sector, and academic researchers to re-use and incorporate Canadian government information and data into other works.
Mandate that all new publicly-funded software code is published as open source. Open source software is widely recognized as an important way for governments to maximize the value of taxpayer dollars they invest in information technology. It allows other government teams (and other governments) to reuse, repurpose, and learn from software code – rather than it only being useful to one team – and also adds security benefits by making code more visible and auditable. Both the United Kingdom and France have blanket policies that custom software code developed for their governments should be open source; Canada should do the same.
Exempt small and medium projects from traditional project management and project gating activities. Many of the policies and guidance pieces on managing IT projects in government predate the technology industry’s shift from “waterfall” to “agile” software development. Following these practices (for example, project gating) often hampers teams that have adopted agile methods. Exempting small and medium projects from these activities can empower and accelerate them, while avoiding disruptive changes to large-scale projects that are already several years into waterfall processes.
Remove data residency requirements on cloud hosting and storage. Data residency – requirements to host data within national borders – is one of the most common pieces of “security theatre” seen in large institutions. Data residency practices don’t add any significant operational security benefits, and prevent the use of modern cloud services that don’t have regionally-hosted versions (which is to say, most cloud services!) Fortunately, the forthcoming Policy on Service and Digital removes explicit requirements for data residency (as of April 2020); this should be followed with updates to Public Opinion Research standards and any other earlier policies that require storing data within Canada.

Long-term

Streamline the government’s information classification structure. The Government of Canada has seven layers of information classification (Unclassified, Protected A through C, Classified to Secret to Top Secret). In April 2014, the United Kingdom replaced its similarly-complex system with a new structure that reduced the number of classification types to three (Official, Secret, and Top Secret). By doing this, it immediately eliminated a wide range of outdated, paper-oriented processes that had been attached to each layer of its old classification system. The UK’s new system allows for the use of standard commercial software products and services with Official data, and was a key success factor behind the UK government’s adoption of cloud services at scale.
Increase the maximum salaries for senior developers and cybersecurity experts. The government’s success at delivering modern digital services – and protecting Canadians’ personal information – is dependent on being able to hire world-class software developers and cybersecurity experts. Competition for this talent is fierce, and other governments (including the United States) have modified or made exceptions to their compensation levels in order to compete with private sector salaries.
Cap the maximum size and length of government IT contracts. The Government of Canada spends millions of dollars per year on contracts to IT companies. Many of these contracts are long-term contracts (more than five years), which limits the government’s ability to change or improve services that don’t meet users’ needs. The UK’s Technology Code of Practice introduced maximum caps on the size of IT contracts, limited certain contracts to a maximum of 2 years, and eliminated automatic contract renewals. Adopting similar steps in Canada would increase the value-for-money of government IT contracts, encourage modern technology practices like building small, modular systems, help build in-house capacity, and increase the percentage of contracts that go to small and medium enterprises.

Many of these steps are challenging, and involve coordinating with other parts of government (responsible for contracting, human resources, and other areas). But changing the environment that public servants work in, for the better, is essential – as digital government becomes a normal part of how governments work. I’m excited for what the next GC CIO will take on, and how the ripple effects will empower public servants across the Canadian government.

Moving to the Yukon

Tue, 17 Dec 2019 11:50:58 -0600

In mid-October, Heather and I moved to Whitehorse. So far we’ve really enjoyed it – Whitehorse is a lovely city, full of friendly people. Arriving just as winter started was a bit intimidating, but so far it hasn’t been too intense.

Heather started a new job with the Yukon government’s Department of Energy, Mines, and Resources. Her team is working on Yukon’s Our Clean Future efforts, including programs for building energy retrofits, electric vehicles, and more. I’ve continued working remotely for my current team. We both feel really lucky to have the chance to live and work somewhere new, and to see a part of Canada we hadn’t seen before.

After three or four years in Ottawa, it’s definitely a lifestyle change in some ways. Having a car of our own is a new experience (after being enthusiastic car-sharing members in Ottawa). Being able to do quick errands, or roadtrips out into the countryside around Whitehorse, has been useful for sure. We’re both excited to get our bicycles out of storage and to start biking to work, though.

I’m working from Northlight, a coworking space that opened about a year ago in a new location in downtown Whitehorse. It’s a really nice community, and being able to work in an environment surrounded by other people helps a lot to stay focused. I miss spontaneous in-person conversations with my colleagues (who are dear friends) but being able to continue working with them from here is something I’m really grateful for.

If you’re interested in our Yukon adventures, Heather and I have an informal email list going where we send out sporadic life updates. Send me an email if you’d like to be on the list!

Hello, world!

Tue, 05 Nov 2019 16:35:00 -0800

Let’s just say, it’s been a long time coming.

A lot has happened since I originally planned to start a blog. Years have gone by; I moved a few times. Andrew Coyne got back on Twitter!

The idea of writing things and publishing them on the internet has been appealing for a long time. I think it’s mostly because people I admire a lot – David Eaves, Sara Souidan, Brad Frost, Mike Bracken, Lucas Cherkewski – make a habit of doing that regularly. There’s some small fear that comes from that – on the one hand, living up to the standards set by heroes of mine. And on the other hand, putting down opinions of my own, that I know I will also eventually think are wrong, with the benefit of years of hindsight. Things on the internet last a very long time.

I think it’s worth it, mostly just to try it and see what happens. There are a lot of interesting conversations taking place every day – especially in my favourite niche topic, the intersection of technology and governments – and I’m excited to contribute small ideas to these conversations somehow.

The subtitle on David Eaves’ blog is, “if writing is a muscle, this is my gym”. That’s an attitude I’d like to adopt here. Expect a lot of imperfect posts as I, er, exercise in public. I think I’ve been to a real-life gym once in my life, so …this should go well.

There’s a few people who I have to thank, for encouraging me to do this since longer than I can remember. James, Leon, Alex, and Brad (my original Twitter friends!). Kwabena and Delalorm, who led a phenomenal workshop on blogging at Barcamp Kumasi in 2013. I promised I’d let you know when I started blogging – turns out I’m only 6 years or so late. The things I plan to write about here aren’t quite what I imagined they’d be then, but I’m excited about where they’ll go. And, thanks to Heather, as always, for a whole bunch of things.

Thanks for believing in me, years ahead of time. Here goes…!