“I hoped the system would have had more capacity for institutional reform than it has.”

Those are the words of Mike Bracken, the former head of the United Kingdom’s Government Digital Service (GDS), as he reflected on his departure back in 2015.

“We now have a different set of ministers, a different group of permanent secretaries, and you have to win these arguments over again. Just because you’ve won them once doesn’t mean you’ve won them permanently, especially in a system that will roll back to what it knows…

If government continues to not look at institutional reform as a necessity to enable better digital services, then it is destined to repeat the failures of the past.”

This past September marks a decade since I joined the Canadian federal government, as part of the team that became the Canadian Digital Service (CDS). I was already a fan of the UK’s GDS; I had written my end-of-grad school research paper on it, in 2013 as it was really ramping up. It was thrilling, a genuine dream to be part of the team trying to hatch a Canadian version.

Which, in September 2016, was five of us, known around the office floor as “Ryan’s digital government team”. It was a blast. It felt like a historic moment, to be bringing the federal government (somehow) into the internet era, following the footsteps of the UK’s GDS, the United States Digital Service and 18F, the Ontario Digital Service, and other early leaders.

By the time I left the federal government, in 2023, CDS was about 130 people. We built some things, we learned a lot. I worked with phenomenally talented software developers, designers and design researchers, product managers, and policy thinkers.

We did not, uh, profoundly change the Canadian federal public service at large.

More transformative transformation

In early September the federal government announced the creation of Digital Transformation Canada (DTC), a new department that will bring together several of the federal government’s IT-related organizations:

“Digital Transformation Canada will bring together Shared Services Canada and selected functions from the Treasury Board of Canada Secretariat, Public Services and Procurement Canada, and Employment and Social Development Canada – specifically the Canadian Digital Service.”

The new organization will be led by Patrick Pichette, a former Google executive. Patrick was on the board of directors of Engineers Without Borders Canada when I worked there (as an IT intern!) long ago; I never met him but people spoke highly of him.

The fragmented landscape of government IT has been a problem for a long time – infrastructure and application development siloed away from each other, IT policy determined by non-technologists, design standards-setting and design expertise existing far apart from each other, and so on. (Organizational turf protection seems to be an outsized skill of many public service executives, which compounds the problem.) Bringing these organizations into one department or agency is a promising step.

To the extent that these organizations and the teams within them have different cultures – reform-oriented versus status quo – it will be interesting to see what ultimately prevails in DTC at large.

As my friend Mike put it, this change is adding “the pint of water that is the Canadian Digital Service to the ocean that is Shared Services”. Several years back when Joyce Murray, then the (brief) Minister of Digital Government, was working on a digital strategy, her team asked CDS to work with the Office of the Chief Information Officer and Shared Services Canada on a path forward. All three of these organizations had different priorities, and the numbers (100 of us at CDS, 400 people at OCIO, and about 8,000 people at SSC) were at least a bit lopsided. Did the circa-2021 “government-wide transformation effort” pan out? Not yet.

High, high hopes

When CDS launched in 2017, our goal was to improve the experience and quality of online government services, and the way they were built. Already then, the Canadian government had a reputation of falling behind in the technology field. The government’s online services were hard to use, if they existed at all. Paper-based processes and fax machines, as then-minister Scott Brison liked to point out, were still frequently the norm.

Our team’s main operating assumption was that bringing in tech industry talent and ways of working would change how the federal government delivered digital services, for the better:

• Using modern programming languages, using Slack and Google Docs instead of emailing Word attachments around, using GitHub and working in the open.
• Recruiting technology roles – not just software developers, but also service designers and design researchers and product managers that weren’t widely established in government.
• And, helping departments build digital services that actually worked well for the people that used them. All the things that GDS had been doing for five years at that point.

That was the pitch, and it was what people told us they wanted.

It relied, of course, on a number of assumptions that (as always) we didn’t quite realize we were making:

• That other departments would be interested in our help
• That good software and design would make the case for itself

And underneath those assumptions: that departments (not homogenous entities!) would be internally aligned on missions and goals; that decision-makers in government would be able to tell the difference between good and bad software; and that we would be able to overcome institutional resistance to doing things differently. And that we wouldn’t have to continually re-make the case (within our own department!) for the organizational flexibilities and ways of working that we had established at the beginning.

Thus began a years-long adventure of CDS enthusiastically jumping into new projects with partner departments, and then realizing (well into a design or software development phase) that some fundamental conflict between one part of a department and another was unresolved. Or that a better (or newly-existing) service would threaten key existing stakeholders.

A colleague once observed that teams within departments where these fundamental conflicts existed were more likely to reach out to CDS for help. If a program team had a great working relationship with their departmental IT unit, they wouldn’t have needed us.

Another colleague described CDS projects as “cheap to start but expensive to finish”. We could spin up a product team quickly to do user research, prototyping, and testing, but getting something through the gauntlet of internal departmental compliance to ship it was a huge (and often insurmountable) chunk of work that would show up at the end.

And, born (as CDS was) in the long aftermath of Shared Services Canada’s problematic launch, from the start CDS was established as all carrots, no sticks. Unlike SSC’s services, CDS wasn’t mandatory; you could just call us if you wanted help. If you changed your mind partway through or decided you didn’t like our advice, you could cut CDS out from the project and carry on without us; that was it.

We were a free service intended to support other departments; unlike GDS or the US Digital Service or the Ontario Digital Service at the time, we intentionally didn’t have any kind of standards enforcement or domain management or service quality control role. (David Eaves told us, months before we launched in 2017, that he “didn’t think this was going to work” if we didn’t have any GDS-style sticks. He was correct!)

We thought we could solve government service delivery problems with design and technology expertise. We couldn’t. And as time went on, we realized that the problems we were running into weren’t technology problems, they were organizational and policy problems: HR and classification, procurement, leadership selection, decision-making processes, project management and approval gates, organizational culture.

We did our best to model the ways of working we hoped other government technology teams would adopt. On the CDS team blog (still active today) we talked openly about in-flight projects, things that were working well and (at least to a greater extent than most public service teams) things that weren’t. People would often email me links to other government blogs that launched in the following years; many of these were internal-only (restricted to the GC network, on an intranet site or GCconnex) and I’d think so close yet so far.

We became a Canada-wide distributed team, with staff from coast to coast, very early on. We had team members working from home across the country from 2018 onwards, or from public co-working spaces like Communitech in Waterloo (leading to fights with various government real property folks). Following the Ontario Digital Service’s inspiration, we wrote a series of posts on ways to effectively work as a distributed team. All of these became very widely read in the early months of the pandemic (before, several years later, the Treasury Board Secretariat would aggressively roll back remote work options).

Even having a social media icon for CDS that wasn’t the plain Canada wordmark (identical to every other Government of Canada organization, as was done in 2017) was a brief fight with our departmental comms folks but is now more common. We used Slack to communicate long before government-wide Microsoft Teams was rolled out. We built software with programming languages like Python and modern Javascript from the start; not Earth-shattering by tech industry standards but very rare in government at the time. We used Macbooks.

Other government teams have adopted many of these practices since then – often things that working-level staff wanted to do all along, and CDS’s public example-setting helped make the case. We’d find out about these efforts as public servant friends emailed us asking how we got permission, or how we worked around gatekeepers telling them they couldn’t, for example, pay for low-cost cloud software on a credit card.

But we weren’t able to achieve a systemic level of impact, at least in terms of how federal digital services are built, in the way we had hoped to.

As Mike put it, “A startup would have pivoted, but CDS was never really able… the problems they discovered were firmly in the mandate of other departments.”

CDS’s pivot, in some ways, was establishing its platform team, which to this day runs several very successful government-wide platform products (GC Notify, GC Forms, and the GC Design System). Our efforts to influence how other departments built and delivered digital services slowly scaled back.

Where to from here?

For DTC as a new organization, it could be tempting to re-try all the mistakes we made when launching CDS. Bring in external talent, build some cool prototypes, and then lurch to a halt when departments decide that, no, their existing decade-old case management system is fine the way it is.

Improving digital service delivery is not a technology problem; it’s an institutional reform problem. Prof. Amanda Clarke (who I’ve worked with previously) wrote a great piece on this in the Hill Times (unpaywalled here):

“Most transformations prioritize additions: strategies, governance bodies, executive roles and, in the case of Digital Transformation Canada, a fellowship program. Less attention goes to what should end. Pichette should start there. Rules that generate paperwork without reducing risk, and reviews that repeat decisions made elsewhere, should go. So should executive layers that separate decision-makers from delivery, and briefing practices that leave leaders exhaustively informed yet unable to act. Every inherited function, process and executive position must earn its place…

There will be a natural tendency to measure Digital Transformation Canada by what it announces: strategies, partnerships, shiny products and uses of artificial intelligence. Doing these will be easier than confronting the organization’s inheritance. Pointing new technology at old government problems is a fool’s errand; real transformation attacks the conditions that produced those problems in the first place.

We should measure this organization first by what it stops. Which rules disappear? Which approvals go? Which contracts are exited? Which leaders are asked to seek a new mission because the institution they sustained is the one being replaced?”

A standalone department helps; a wide series of reforms to current Treasury Board policies (more flexible hiring and classification; more flexible procurement; fewer reporting requirements and instead a high priority on working in the open and public ownership of software) would help more. Policy exceptions for DTC could be a start but broader reforms would clear the path for both it and other federal organizations with similarly ambitious mandates.

Ryan Androsoff – who saw this firsthand getting CDS off the ground – wrote a similar recent piece here:

“To me this goes far beyond software, servers, and online service delivery (though all of these are important) – it means getting at some of the root issues that have held us back from making measurable progress. Things like HR rules and classifications that largely represent a pre-internet era reality of how we should be managing a modern, digital-savvy, multidisciplinary workforce. Or procurement and contracting rules and practices that tend to work at cross-purposes with agility and user-centric design and favour large, established vendors… The question here is does DTC see a role for itself in this? And if not, then who does? Because without these types of deeper structural and incentive issues being tackled, there will be a very real rate-limiting factor on the depth and speed of progress DTC can make against its mandate.”

Since leaving the federal government I’ve spent a lot of time thinking about how and why decisions are made the way they are. Part of this is “coasian hecks”, structural situations where no one – even in senior leadership positions – seems capable of changing a broken situation.

Another is the mechanisms by which the status quo gets established and reinforced. The federal public service’s deeply hierarchical structure and consensus-based culture means that dissent is often costly.

Honey Dacanay, who played a key role in the Ontario Digital Service and then worked for the federal government, has written a set of compelling pieces on these mechanisms and how they hinder attempts to change things for the better. In The Unwritten Map and The Inner Circles, she writes about how government institutions bring in change leaders to change the way they work, but those leaders spend most of their time fighting to get to the actual work.

Changing public service culture, then, becomes a complex task of building and spending social capital. The more you push for (necessary) change, the more you threaten the relationships that brought you towards access to power in the first place. It’s rare to see these dynamics talked about, which is why I’m really glad to see Honey’s writing on it.

A continuous effort, versus, how long does political support last?

In moments when bottom-up change efforts felt impossible, it’s been tempting to see political pressures as the solution to the status quo fixation of the public service. In that sense, if Patrick Pichette is friends with the Prime Minister or Clerk, it bodes well for being able to overcome at least some institutional resistance to change.

There’s two caveats to that; one is that public service transformation is not always in a positive direction. The past two years of the US government’s bleak chaos is an example of this. And organizations that are good at digital service implementation can be enlisted to make services harder to access, or crueler, as Ron Bronson writes. Bianca Wylie takes this thought further in her current series, Less Computer, which explores how the mystique and novelty of computers and technology are used to exclude people from democratic decision-making and access to power.

The other caveat is that political support is short-lived. There are always other fires to fight; ministers change, elections happen, and the political attention that helped drive change suddenly evaporates.

When CDS launched, it was pretty clear that we wouldn’t have made it off the ground (as a small internal effort) without the support we received from Scott Brison (the then-president of the Treasury Board) and his office, particularly his senior policy advisor, Ashley Wright. Through her work in the minister’s office, Ashley had met GDS folks from the UK and was far more understanding of what our team was trying to accomplish than most of the public service executives we met with.

That dynamic was a strange thing to grapple with as a non-partisan public servant, but it was obvious very quickly that effort from both sides (the grassroots up, and the political level down) was needed to overcome a “clay layer” of inaction in between.

Scott was an enthusiastic minister and champion of our team’s work. He retired from politics a year and a half later. Our new minister, as president of the Treasury Board, was Jane Philpott. As she got up to speed in the role, she met with the CDS team for the first time on a Friday at the start of March 2019. Our team demoed a number of ongoing projects and prototypes; everyone was excited. She resigned from cabinet the immediate following Monday.

I wondered, for a while, if CDS’s across-government impact could have been different if we had had more sustained political support. If Scott Brison or Jane Philpott had championed our work continuously for four or five years, could we have overcome more institutional resistance or built more cross-government support? Could we have achieved some level of formal authority to influence or direct other organizations in the federal IT landscape?

It was hard not to be jealous of teams like the United States Digital Service, which had, it was said, a direct phone line (at the time) to President Obama’s chief of staff. If a department was blocking some important change or improvement, the rumour was, they could call that line and get things unstuck.

Even that was short-lived. As Mikey Dickerson, the first-ever administrator of the US Digital Service, described it,

“That honeymoon lasted three to four months. Then everybody moves on and starts to forget why we’re there, and the teacher’s pet phenomenon begins: USDS is competing with other wings of the White House for office space, budget, and most of all attention. That’s the most coveted resource at the White House. We started to be “accidentally” left out of meetings and having to deal with a lot more pushing and scratching.

By this point, the sheen of specialness had worn off. We were just another entry on Deputy Chief of Staff Kristie Canegallo’s schedule. The default answer to everything became “no.”

The wormhole to the autonomous zone — the only space where we could get things done — had closed. We were now operating under regular order.”

The regular order – “running on the track” in the Canadian federal public service, as Donald Savoie calls it – is one of slow and dysfunctional approaches to information technology and digital service delivery. Whose job is it to change that? How broadly will DTC try to take this on?

For Mike Bracken and GDS in the United Kingdom – my original digital government heroes – their work had a tremendous impact in the early years of the organization. Their political support diminished, too; their original minister retired and the rest of the UK bureaucracy subsequently pushed back on many of their initiatives. The system did not, as Mike put it, have as much capacity for institutional reform as he had hoped.

Even without that initial political support, GDS has continued to do great work. Over the years it has had a genuinely huge impact on the way the UK government delivers online services and communications. Beyond GDS itself, people who worked there or worked closely with it went on to play a big role across UK government departments.

From our small CDS team here in Canada, people went on to work at Employment and Social Development Canada, at the Public Health Agency of Canada, at Natural Resources Canada, at the Department of National Defence, at the Court Administration Service, and at a number of other departments and agencies. The impact that digital service teams have had goes beyond the work of the team itself.

For other colleagues, running into bureaucratic barriers over and over again wasn’t the experience they had hoped for; a lot of good people got burnt out and went back to the private or non-profit sectors.

I hope that DTC will make more progress than we did, the first time we tried this. Maybe it will take a decade before we know. In my mind, it’s still worth trying.

For more on DTC’s launch, Kathryn May’s The Functionary newsletter is a great read. Reflections from Lucas, Alex, and Ryan and Amanda and Mike (mentioned above) are all worth reading. Thanks to Jeff for the Mike Bracken quote that started off this piece.

CDSers and the folks we worked with in partner departments are many of the best public servants I’ve ever worked with, and some of my closest friends to this day. I didn’t include CDSers in my Public Service Heroes series a few years back; I thought it would seem self-serving to hype my own team members at the time. Y’all know who you are; you’re all legends. Keep on rocking.