Centralized digital transformation: What works well, and doesn't (Part 1)

Disclaimer: The views expressed here are my own, and don’t represent the opinions of my current or previous employers.

In September, the BC government announced plans to bring all digital and IT roles into Connected Services BC, a centralized team in the Ministry of Citizen Services, which includes myself and many (but not all) of the human-centred designers, researchers and content folks across government. I've been working on putting my thoughts into a blog post since I heard the news a few months ago - But, then I (and thousands others) went on strike, and I've been catching up ever since.

The short version is: I'm cautiously optimistic. It's a change change is centred on better service delivery, it brings together people, and it's a pretty bold move (we need more responsible boldness in public service).

But I've also seen a lot of uncertainty and some outright negativity from folks who say, "we've tried this before and it's never worked." I can understand people's pessimism, and I think it's healthy to question big decisions like this. Especially considering the amount of large IT project failures - we should all be a bit more skeptical.

But, on the other hand, it has worked before. Some governments and public sector organizations have changed service delivery in big and important ways, from the centre of government. I've worked for some of those organizations and experienced transformation from the inside, and I've also been an end user of better government services.

I've learned that changing government isn't magic. It's mostly a combination of hard work, smart leadership and a culture of empowerment, along with the right timing. It can work in BC too.

The real question is: what can we learn from other organizations? This blog post is me doing that - reflecting on what worked and didn't in digital transformation, from my designer/user researcher perspective.

👉 First, some context
I'm mostly going to speak mostly from my experiences working for the UK's Government Digital Service (GDS) and federal government’s Canadian Digital Service (CDS).

This is a rundown of the basic structure and mandate of those organizations, from my perspective at the time I worked there (both organizations have changed a lot since then so this may not be accurate for today.)

These two transformation models are fundamentally different from what Connected Services BC is doing (where some but not all services and teams are being moved to the centre of government) - but I still think the learnings about how to change digital delivery at scale will apply. So, onto those learnings....

What's made centralized transformation efforts successful 

• A strong mandate with political support & financial leverage: GDS having open political support and financial controls radically changed service delivery across government, not just in the UK but worldwide. As a smaller organization, CDS didn't have the same whole-of-government impact, but I saw small and meaningful changes in the federal space while I was there.
• Building the org culture as a top priority: Much of the success of both orgs is due largely to intentionally creating a culture where talented people could thrive while doing inspiring, mission-driven work in openly supportive teams. I personally believe a lot of this can be attributed to the more relaxed and connected communication practices (both orgs used Slack as the main workspace which boosted connection and culture), but also a strong focus on empowering the people doing the work while reducing the influence of leadership (such as allowing people to share work without needing permission.)
• Clear standards for services with guidance on meeting them: GDS set clear standards and built a peer-led assessment process that everyone had to meet. But, crucially, they also published the Service Manual which outlined how to meet those standards and why they were important, along with providing things like frameworks, patterns and code that could be easily replicated.
• Org-wide focus on user needs and user research. At both CDS and GDS, "the people we serve" wasn't some abstract concept - user research was visible and embedded into everything. Product sprints and roadmaps were built with user research in mind, senior execs attended playbacks and research sessions, and the experiences of real users were a focus at events like all-staffs and showcases.
• Investment in digital upskilling & capability building across gov at the working level: GDS invested heavily in building digital capability in government departments through training and communities of practice, as well as hiring and procurement frameworks. CDS built digital capabilities in teams through close partnerships, on-the-job training and shared agile rituals, which helped ministries and departments take the work forward. Importantly, both organizations had practice leadership to support mentoring and upskilling of staff (including heads of design, development, delivery, policy and product.)
• Accelerating delivery by removing barriers & admin burden: GDS rapidly sped up delivery by ensuring people in development and design roles didn't lose momentum to administrative burden. For example, GDS user researchers were able to deliver frequent insights because research recruitment, compensation and scheduling (which took up an immense amount of time) were taken care of by someone else.
• Connecting services through shared platforms: Both GDS and CDS focused efforts on building tools and platforms that were free or low cost to use within government and worked for many use cases, such as Notify. These platforms allowed digital to scale more easily across government, and earned trust, praise and respect from department heads and politicians.
• Partnerships with Departments and Ministries: CDS built partnerships exceptionally well by collaborating closely with Department teams to understand and work within their context and limitations. On the other hand, GDS's prescriptive approach for all of government created some resentment that may have backfired.
• Openness as both a default and an organizational priority: GDS changed digital service delivery across the world, but they couldn't have done that unless the world could see what they were doing. Their tremendous impact has been largely thanks to making open code, data, sharing and standards the default, but also putting a high priority on blogging, events and community. In 2019 CDS used GDS' open source code to create GC Notify, which at the time of writing this sentence is used by 888 government services and has sent 271,668,317 messages.

What hindered centralized transformation progress

• Control without support: There's no doubt that strong service standards changed government in the UK, but for some smaller teams and departments I worked with, GDS raised the bar to a level they felt was impossible for them to meet. I saw how imposing standards on teams that don't have the staff of capability required sometimes led to secretive political manoeuvring and shadow technology.
• Separating digital from the rest of government: Holding digital up as some kind of government unicorn (or “blue-jean kids” as GDS folks were sometimes called) can lead to other parts of the public sector feeling alienated, particularly policy and frontline delivery who are an integral part of the service, yet are left out of technology efforts. CDS tried to avoid this by integrating policy roles into their multidisciplinary teams and it strengthened their efforts.
• Loss of vocal political support. Public Digital wrote about how GDS started to slowly decline after losing their political sponsor, Lord Maude, allowing some departments and teams to revert to how things had been done before, undermining progress that had been made.
• Individual ministry or leader agendas overriding collective standards: Government is an inherently political system, and I've seen that even the strongest standards mandate can occasionally get overridden by a Very Senior Executive or even a Minister with good connections. But when any department can find a way to do its own thing, it risks creating chaotic experiences for those on the other end of government services, while also creating resentment across sectors.
• Persistent historical clashes: In my time in government, I've come across work, teams, platforms and services that are divided in ways that don't make logical sense. When I ask why, I sometimes hear stories a power tug-of-war that happened years (even decades!) ago at senior levels, leading to decisions that have occasionally been revisited but never changed for reasons that are unclear (but are alluded to in rumours about old grudges and personality clashes.) I've seen clear examples of how permitting these organizational issues to persist can impact service delivery and the employee experience in detrimental ways, leading to an erosion of trust and confidence in public services and government leaders.

So....

Those are my basic reflections on what helps and what hinders. Up next is a part 2 post with the main opportunities I see in these experiences. But first....

A final note to all the pessimists...
Hang onto your skepticism - it's needed. Raise concerns. Ask questions. Point out the risks, and the things that are not practical or realistic. Be bold and speak truth to power when it's important to do so, but when you do, remember that empathy is a two-way street.

Hang on to your hope as well. Everything will change and evolve over time, including you, so be curious and humble, and perhaps offer some of your energy to building what comes next.