Beware tech voices dominating change programmes

The other day I had an epiphany.

I was trying to explain to someone what my job has involved in the last few years.

The answer to which is I’ve mostly been working in transformation programmes which aim to improve how the public sector works and interacts with citizens. (If you’re wondering whether at this point they had to urgently leave for some kind of vague ‘emergency’, yes, yes they did).

But I didn’t say that to this person. Instead I said that I had been working on digital transformation programmes in the public sector.

And then I stopped and checked myself.

Digital transformations.

Why had I done that?

These programmes involve a technology element, sure, but they’re not exclusively about technology. They’re about making improvements across a wide range of areas, one of which is technology.

Somehow I had lazily inserted the word digital where it shouldn’t have been.

And then I realised, I did that because these programmes had, over time, become largely about technology.

Some of the other stuff that needed fixing, which came up when we spoke to staff and people using the services, seemed to have become less of a priority.

And that got me thinking.

In all my years working on digital projects, I have never had a specialist from another area such as policy or data working alongside me.

Not one.

Not only that, we rarely explicitly invited them to research sessions, demoes or opportunities to feed into the work.

Could those missing voices be part of the reason why my brain was so quick to claim these programmes as ‘digital’ transformations?

Let’s get some perspective(s)

This speaks to an important truth about the importance of cognitive diversity in teams.

There is not 1 way to solve a problem.

There are many.

If what I understand is how to build a piece of software, I’m going to view every problem through that lens and my solutions are more likely to revolve around creating or fixing software.

But there might be a different solution that doesn’t involve software.

Imagine businesses are asked to send data to a government department and they’re frustrated by the time it takes to fill in and email the form.

A software engineer might build a mechanism that makes it faster for them to upload their data.

A content designer might redesign the form to make it simpler and clearer so they don’t have to phone up to clarify things.

A business analyst might suggest removing data points that are providing data of insufficient quality so businesses need to provide less.

A policy specialist might identify data points that no longer provide useful insights for policymakers and can be removed.

A lawyer might realise that since our exit from the EU we no longer need to collect this data at all because the UK is launching a new data strategy.

Five good solutions.

But only one of them is the right solution.

And that was only possible by having the right knowledge in the room.

This bias towards solutions we’re already familiar with is called functional fixedness. It’s another reason why it’s so important that teams working in transformation programmes are genuinely diverse (links to video).

This is not to say that digital specialists can’t think outside their disciplines (many can and do). But our training means we are predisposed to find solutions in our areas of expertise.

That’s why it’s so important we have the most diverse set of perspectives we can manage when exploring solutions to organisational problems. And we ensure all those perspectives are given equal weight in conversations.

We don’t know what we don’t know.

No software without soft power

Also, for virtually every organisation, success is as much about getting people on side as it is about delivering great outcomes.

When you leave key stakeholders out of the loop, you risk creating misunderstandings and frustration.

But government consistently underestimates the amount of time and effort it takes to get buy-in from stakeholders, particularly those from outside of government.

Even if an organisation can deliver everything they promised (which is rare), everything can be derailed if powerful stakeholders withhold their support.

The best way to guard against that is to invite people in. Not just as observers of the programme’s outputs, but as contributors and influencers.

When people are able to contribute meaningfully to these programmes, they’re far more likely to put their precious time, skills and influence towards making it happen.

Not everything can be solved with IT

Organisations engaged in transformation programmes naturally want to leverage the benefits that technology can bring.

But if every conversation is being dominated by discussions about tech stacks for example, it could be a sign the programme is drifting away from its original remit.

And that could have far-reaching consequences if what gets delivered is a piece of software and not the deep, organisational change that people really need.

From now on, I’m going to be a lot more mindful about whose voice is — and is not — being heard on my projects.

I’m also going to try and find a better way to describe my job.

Public service delivery specialist?

Oh, wait, you’ve gone 🤦🏾‍♀️

Photo by British Library on Unsplash

This piece was first published on Medium.