Why are we so against service standards and assessments?

I’ve discovered the quickest way to get a Canadian public servant to roll their eyes / visibly grimace / scoff / change the subject.

All you need to do is say the words, “maybe we need some service standards and/or service assessments in this government.”

Having worked in the UK government, I’m used to service standards and assessments. But since re-joining Canadian government in 2019, I’ve found that any time I talk about how important I think they are, it doesn’t go down well.

Here are some of the responses:

• “We don’t need more performative paperwork.” (I agree)
• “Why would you hire smart people and then tell them what to do?” (agree, but also standards don’t do that.)
• “We want to empower teams, we shouldn’t be in the business of gatekeeping or policing them” (it is actually possible to empower people and have standards at the same time.)

Look, I’ve sat through many assessments in the UK gov (as both an assessor and and assessee.) They can be painful. They take a lot of time. Overall, enforcement is really hard work. But I still think they are better than the wild west, everybody-for-themselves alternative.

What I mean by standards

With a strong caveat that I am not an expert on either of these, and this is based on my understand of working within the system of a few governments, here are my working definitions:

• Service standards are criteria that service teams must follow when building digital services. This is enforced and there are consequences for not following it.
• Principles or guidelines are things that teams should do. They may be official rules, even legislation, but there’s no one enforcing and no clear consequences for not following them.

The UK Government has standards (see service standard and technology code of practice) and the BC Government has principles (see Digital Principles and Chapter 12 Core Policy.) The content for all of these is mostly the same. The only difference is that in the UK Government, teams are held publicly accountable for meeting the baseline through the assessment process, and most teams are required to meet the standard to obtain funding. In BC Government, these principles are strongly encouraged, particularly by our Digital investment Office, but as far as I can tell, there are no clear consequences for not following them from within government, and no one’s checking up on teams.

I think it’s important to recognize that neither service standards nor digital principles tell people how to do their job, they just set reasonable baseline expectations for what is acceptable, which people want and need. The UK government doesn’t tell you what tech stack or research methods or security tools to use, they just ask that you show you’ve put work and thought into those things — which I think is completely reasonable. Plus, standards aren’t set in stone. Exceptions with good reason are made all the time.

Three reasons we should embrace standards and assessments

1: The people doing the work want them

In the Digital Office / Exchange Lab where I work, we see our role as enabling and supporting digital teams, rather than telling them what to do. We will give them the tools to be successful, but we want them to figure it out for themselves. I think this is a good approach.

And yet, in the research I do with digital product teams, something that comes up again and again is: Product teams want standards, and they want someone to check that they’re on the right path. They don’t want to be micromanaged or “policed”, but they do want to be checked in on and supported. They want the ability to push back when they think its appropriate, but mostly they want us to be very clear on what the expectations are, and they want to be checked on and told if they are doing it right or not. (At the exchange lab, we do do this, but for individual teams who work with us, not the organization as a whole.)

This goes directly against an assumption I think many of us have long held: that product teams want to be left alone to do figure out how to do their work on their own. Qualitative research is showing this isn’t true. This doesn’t mean these teams and people aren’t smart or experienced or good at their jobs. Smart people need guardrails too and that’s perfectly normal.

2: Enforcing standards motivates the organization change needed to transform services at scale

Service standards, when enforced, can give much-needed leverage to product teams. Here’s an example:

When I was in the UK government, I was in an assessment for a team that didn’t have a dedicated researcher or designer and hadn’t done enough user research to meet the service standard. They failed the assessment. But they were able to use that failure to make a business case for hiring a researcher and designer. This wouldn’t have happened without the assessment process. Their service assessment failure was a tool that the team used to convinced leadership to invest in user-centred design.

Kate Tarling said recently: “Rather than modernise just one service at a time, it’s the underlying organisational conditions that need to be transformed — anything less is futile.” Service standards are way to push the transformation of organizational conditions across all service delivery teams.

3: It’s better for end users

In the UK Government, user research and user-centred design are not optional. Every department and team working on a high-profile public-facing service is required to provide evidence that their service works for users. This should not be optional. I’m not saying this doesn’t happen in BC Government, but without enforced standards, there’s no evidence or accountability that it’s happening.

When things like user research, user-centred design and user data protection are requirements, it leads to services that are better for users. When one centralized team is looking at all services and the service landscape as a whole, it leads to better services for users. When service standards are enforced, it results in consistency (not uniformity) across services, and this — you guessed it — leads to better services for users.

At FWD50, Pia Andrews said: “Principle-based approaches leads to widely inconsistent implementation”

I don’t think the wild west is good enough for the people we serve.

How I think about service standards

Nobody asked me, but if they did, this is how I see standards working best in government:

1. We can’t just set standards, we must also support people to meet them. There’s a sentiment in the UK Government that GDS burned bridges in the UK government by setting a standard that felt impossible at the time for some departments to achieve. Any org that sets standards needs to invest in funding things like in-house training, mentoring and coaching, and doing the hard work to unblock things that get in the way of user-centred service delivery. (for the record, GDS did a lot of this while I was there, but then defunded and shifted things, so I don’t really know how it is now.)
2. Standards and enforcement will be more successful if they are co-produced and co-designed, not imposed from the centre. This means building up cross-government communities who work together in a productive and meaningful way, and it also means re-thinking organizational and power structures. We have to be ready to dismantle some of the arbitrary silos we’ve built.
3. Standards and enforcement need to evolve over time. They need to be treated and iterated on like a service. They are not a one-and-done process.
4. This needs to be internal. When things get hard, government teams often throw money out to RFPs so we can outsource it. But this is something we can’t outsource to an external vendor; Nobody else can tell us what we’re getting right and wrong. It has to be a process made with, for, and by public servants.
5. But most importantly, none of this can work without executive buy-in. It has to have top-level sponsorship and support to work. GDS had this. As Kate Tarling says, “everything else is futile.”

I’m open to the idea that standards might not be the way to go. I’m open to and curious about other opinions and ways of thinking about this. But at the end of the day, I don’t think the alternative— where research and design and security and privacy are optional and not validated—is good enough for the people we serve.