Post-digital

In public service, we want “digital transformation”.

That is, we want to use technology to better serve citizens, and we recognise that our institutions need to change if we’re to accomplish that.

This process will be complete when we no longer use the word “digital”. There will be no “digital” and “non-digital”, no “technical” and “non-technical”.

Those distinctions will be a relic of the current transition.

We’ll be post-digital.

Find “digital” and do the opposite

That small step of logic, that digital transformation means moving away from “digital”, leads to an appealing rule of thumb:

If your actions tend to sustain the role of “digital” as a separate function in your organisation, you are working against digital transformation.

Here’s a concrete example where I think that rule of thumb applies.

In 2019 two teams were established at the Department for Education (DfE) to build GOV.UK services for teacher recruitment: finding courses, submitting applications for training, etc. These teams were different from ordinary multidisciplinary delivery teams. They had “policy people” - that is, traditional “non-technical” civil servants - in them.

The service manual page linked above, by the way, is quite clear on the role that policy people should play in teams: we should “provide the team with access to the specialist expertise it needs, for example legal, policy, or industry-specific analysis”.

What DfE did went way beyond that.

These teams were successful. The deeper they dug into the world of teacher training, the more data they collected, and the more understanding they gathered, the more and the better interventions the teams and their “non-technical” members were able to make.

“Policy people”, armed with piles of evidence and the levers for acting on that evidence, were proposing new services, new user journeys, even new APIs—jointly with “digital” colleagues.

Something else happened too: the teams got a reputation. Neighboring divisions in DfE noticed them. Those divisions had technical problems which researchers, analysts and software developers could help with.

Let’s say these are your teams. How do you choose between pursuing the things you’ve discovered, and solving obvious and perhaps pressing technical problems you can see next door?

Option 1 doubles down on the domain knowledge the team has. It bakes the technical specialists into the policy division where they’re working. It grows organically, at a cost of being highly dependent on the individuals in the team—and because of that, you will be advised that it is “not scalable”. After all, if you leave this team where it is, you’ll have to start all over again with the next one.

Option 2 doubles down on the technical skills you’ve developed in the team. It lets this team, which is a weird and novel hybrid, answer to the name of a traditional “digital team”. It also plays to the better instincts of the team to be useful and fix things. And it is “scalable”—you’re scaling out! But it clearly signals that the organisation considers “knowing” and “doing” to be separate activities.

Here’s a way to make the decision: which of those options is likelier to leave you with a “digital” function? The other option is the truly transformative one.

Digital fragility

Leaving “digital” behind requires cultural change amongst “digital” practitioners.

We have good reasons to mark our own work out as fundamentally different from “non-digital” work.

Holding on to status is one. Another reason is that there is an entire industry built on selling specialists to government, and people need to get paid, so specialists must be perceived to be special. Yet another reason is that when “digital” teams collide with “non-digital” systems, they have a tendency to imagine they have a monopoly on pragmatism and empathy—resources, by the way, which are equally available to literally everyone.

So here’s a second way of looking at “digital transformation”: it’s transforming “digital”.

If you ever want the transition to take, which is the only way you’re ever going to complete the work, you have to not only not gatekeep, you have to invite people into the mysteries of your profession. You have to find the limits of what they can understand about it, and allow them to reach those limits. And you must invite this, in the teeth of their self-doubt and uncertainty, because you are making up for the unfriendly face that gatekeeping has painted on software, or on user research, or on interaction design, or whatever.

That means teach-ins, workshops, mentoring, patience, and humility. And recognising that a Civil Servant who can understand the complicated regulations around initial teacher training is not going to have any trouble understanding what an API is.

Waving across the gap

Whatever set of practices collapses “digital” will be different in different organisations, but it will have a few things in common.

It will upend the model of a “delivery” function lending its skills to a “policy” function. It will create new structures of accountability, like policy divisions responsible for software systems. It will create new roles, such as policy/technical partnerships at senior levels, or roles that combine policymaking and product design.

The two halves of those future roles are waving at each other across the gap between policy and “digital”.

Our leadership has to go beyond “I will support you, digital teams, to carry on your digital practice according to the service manual”. We have to show teams, and our organisations, that when the comfort blanket of “digital” is taken away, the future is better and bolder.