Organisations designed as well as products

Introduction

Digital Government is (kind of) 10-years old.* What will the next 10-years look like?

Last year one of the first-gen GDS folk led a project at my old organisation, I got a chance to work with them as part of this. In our final meetup I asked for any big trends they’d spotted and they said something like ‘figuring out what the next 10 years look like for Digital Government . . . some of the big companies give the impression they can do the Digital thing as well as the in-house teams, they’re competitors . . . what does that mean for the in-house Digital teams?’. Just a few days ago GDS took-on Deloitte to develop help develop an identity app. There are good and sensible reasons for this, as shared by Will Myddleton. There are good reasons for choosing suppliers to do ‘Digital’ work. I’m not a fundamentalist who believes everything should be done in house. I’m a pragmatist. Anecdotally, I’m seeing a growing appetite to work with suppliers on ‘Digital delivery’. In-house teams need to accept this and figure out what it means for them. What’s their unique selling point versus external competitors? And what does the next 10-years look like?

I was going to use this question - ‘what’s the next 10-years of Digital Government?’ - to help me and fellow Heads of Profession build our long-term vision. I’ve now left my organisation so we won’t get a chance to do this together. But it remains an interesting challenge in product-positioning. So after the first 10-years where ‘delivery was the strategy’, here’s why I hope that the next 10-years is about designing our organisations as well as our products.

Note: * It’s not as neat as being 10-years old. GDS was 10-years old last year but ‘Digital Government’ work began a couple of years before GDS officially appeared and you could argue that the ground work started being done as early as 2005-6. But that’s not a pithy opener for a blog post so you can see why I went with ‘10-years old’. The general point remains the same: Digital Government is getting old and hitting its teenage years.

Pioneering to settling

You’ve probably heard someone talk about pioneers, setters and town planners. I can be a contrarian, so I avoided using it for ages. But, revisiting it a couple of years ago, I was struck by how well it described patterns I’d been seeing. I got over my contrary nature and started using it.

‘Pioneers settlers town planners’ is the work of Simon Wardley. A summary of the model can be found on Wardleypedia.org. As Simon himself would say, it’s a model and it’s wrong but it still has value. So here’s a version I’ve simplified and tweaked for the purposes of this post.

Pioneers	Settlers	Town planners
Creates new technology	Grows use of products	Increases efficiency
Uses agile and components	Uses ecosystems	Uses six sigma
Accepts uncertainty	Accepts constant improvement	Accepts analytical decision-making
Deals with the new and poorly understood	Deals with increasing education	Deals with standardisation

Note: the terms pioneer and settler both have problematic connotations and I’ve seen Simon say online that he’d use different terms if creating the concept today and is, I think, open to suggestions for better terms.

Ground work

Preparation for Digital Government began during Tony Blair’s third Ministry (2005-2007), led by the Cabinet Office. Gus O’Donnell, the Cabinet Secretary at the time, regularly spoke about about two things: managing risk (instead of trying to avoid it) and customer insights. The Cabinet Office published a working paper called ‘Customer insight in public services - “A Primer”’ in 2006.It included guidance on using tools like customer journey mapping to improve services. The front page is a quote from Gus O’Donnell:

“We must be relentlessly customer-focused. Many people want a single point of contact for a range of services. The public are not interested in whether their needs are met by Department X or Agency Y, they just want a good, joined-up service where X and Y talk to each other and share information the public have provided. We should strive to meet this demand.”

First-wave Digital Government: Pioneering

First 10-years belonged to pioneers

It’s not a stretch to see the first 10-years or so of Digital Government as the age of pioneers. Simply existing in the first place was pioneering. Delivery of the initial 25 exemplars was pioneering work. The introduction of components following the ‘Government as a Platform’ movement was pioneering work. Every Government organisation with a Digital portfolio has done pioneering work over the last few years that adds-up to exciting change in how public services are delivered in the UK.

Components and trust

Components are interesting to me. This is where I joined the Digital Government work. I joined in 2015 to help the Ministry of Justice create what’s now called the ‘Platforms and Architecture’ business unit. I also got to work with, share with and learn from other Government Departments like Home Office and HMRC who were starting similar work around the same time. And GDS, where there was a lot of collaboration with the GaaP folks. I even got to lead the assessment of some of the early GaaP Alphas. I came to realise a couple of important things back in 2015:

It’s easy to think of components as ‘technical products’ and skip user-centred design. I don’t agree with this.The root of the word ‘technical’ is ‘technique’. What people mean when they say ‘technical product’ is ‘a product with techniques I don’t understand’. They’re staff-facing products. As staff-facing products they need to be well designed in order to be adopted.
The value proposition for components is trust. We all have a tendency towards exceptionalism. We believe we’re doing something so unique it requires a totally bespoke approach. The truth is we’re often more similar than we are different. Components take a custom activity that used to be in someone’s control. Removes that control. And tells people they’re not as special as they thought. That requires a lot of trust.

Pioneering and settling happen at the same time

More recently I’ve realised that ‘pioneering’, ‘settling’ and ‘town-planning’ are not discrete, sequential stages. Rather, they all need to start at the same time because they each take longer than the last. Each phase happens at a different speed because each phase is harder than the last. I came to realise that ‘settling’ is where trust is built across the organisation. This trust is a critical dependency for adoption of components. And maybe, the pioneering work has become a means to an end. The real goal, right now, is to focus on settling: designing the ecosystem in which we operate as well as we designed our pioneering products.

Second-wave Digital Government: Settling

I saw a Tweet a few months ago. It said something like: ‘the must-have skills in the 2010s was software development, in the 2020s it’s going to be community management’. I think there’s truth in this. Viewed from the perspective of the Civil Service, ‘Digital’ has become part of the furniture. No longer are people excited by the simple act of creation of in-house software. Now it needs to actually be used, at scale. Fundamentally, there’s a switch to return on investment (or benefits realisation in the language of Government). There’s an increasing need to (i) seek the best opportunities for benefits realisation and (ii) focus on the mature phase of the product lifecycle (or ‘Live’ in the language of Government). Both of these things need us to be as interested in our organisations as we are in the problems we’re solving for our users. And both of these things require us to recognise that the software is (usually) not our product.

If we want to grow the use of our products and develop new opportunities we need to invest in understanding the ecosystem we’re a part of. We need to switch to constant improvement of mature products. And we need to deal with the increasing need to communicate and educate. We’ve always had to do these things but, in my experience, it’s always been invisible work. Activity to understand our organisation or to develop our culture has largely been invisible from portfolios that tend to favour our ‘official’ class of work: reporting delivery of IT assignments alongside budget lines. In many instances we’ve been rewiring the house around us in order to achieve relatively simply ‘digital delivery’ but this organisational change doesn’t appear on any sprint backlogs or roadmaps.

Making this work visible, investing in it and setting explicit goals is the stuff of the second wave of Digital Government. Working on organisational culture can lead to spurious workshops to help define ‘what even is culture?’. Nobody wants that. So allow me to recommend Simon Wardley once more. Simon’s provided a starting point for thinking about culture, called ‘doctrine pattern’. Here’s a helpful summary in table form. It breaks culture into phases with clear elements. As I said earlier, it’s a model and it’s wrong but it still has value. This gives a day-1 starting point. The next 10-years needs us to introduce an explicit-class of work focussed on how we work within our ecosystem and how we interact with users of our mature products. We need to invest in designing our organisation and its culture as well as we design our products. And Simon’s doctrine pattern gives us something to help. We’re starting in the middle, as ever. We’ve been doing this for ages but it’s been treated as invisible work. Now’s a chance to make it visible, so we can grow use of our mature products and develop new opportunities. The pioneering work needs to continue, this isn’t about stopping that. This is about recognising the need to start investing as much time and effort in ‘settling’, which requires transformation of relationships to be on equal-footing with transformation of technology. If the first 10-years was about introducing the Lean Startup to Government then the next 10-years is about introducing the Lean Enterprise to Government. The Lean Enterprise is about how to run an entire organisation that’s designed to work as well as an individual team using Lean Startup.

An example

I’ve just left the Ministry of Justice where I worked in the ‘digital and technology function’. This Digital and Technology Function is over 1,000 people. The Digital half is separated into a unit that support the MOJ itself, alongside a unit each for Criminal Injury Compensation Authority,,Legal Aid Agency, Office of the Public Guardian, Prisons and Probation. There’s also a unit for shared platforms. Collectively as MOJ Digital and Technology, these units are working to 40 separate strategies and supporting over 80,000 staff alongside millions of public users.

Communities of practice were introduced into this mix. If ‘what’ we need to achieve is set by the senior leadership teams then professions are ‘how’ the goals are achieved. This ‘matrix management’ in action. Professional communities of practice bridge across organisational silos. Silos can exist at the scale of individual teams right up to entire divisions of an organisation. Digital, data and technology professions cut across these silos and help us to work in the larger ecosystem of our organisation.

Except when they become silos themselves. We realised that professional communities in government had defined ourselves to ourselves and for ourselves. But we’d forgotten to define how we work together in teams to get things done. It’s hard to figure out how our specialist roles work together in multi-disciplinary product teams. We need to figure out how we work together. The unit of delivery is the team, not the profession.

It became clear that professional communities of practice are just one of the features needed for us to design our organisation as well as our products. Communities of practice need to sit with other types of communities, knowledge management, curation and standards.

Communities. Communities of practice within professions are not enough. We need other communities that cut across professional boundaries. Like communities of interest. For example, somewhere that anyone working on a Discovery can come together, share and learn from each other. And communities of action. For example, somewhere for people to come together and improve knowledge management.
Knowledge. Communities generate knowledge. Usefully storing knowledge is hard. There’s work to use common tools, to have common taxonomies, to keep the information up to date and useable. The most radical act of innovation that many large organisation could make is to invest in a Content Designer and Librarian.
Curation. “We consume information recreationally, not as a way to achieve our goals”, to quote Sari Azout. I spent years running my profession’s product management handbook but it was already being forgotten after a few months away on shared parental leave.Knowledge needs to be curated and regularly put in front of us, discussed and explained, if we’re to actually use it. Communities, 1:1s, coaching and mentoring are all great places for knowledge to be curated and brought to life.
Standards. Standards are the ‘so what’ to this whole thing. Standards reward us for starting from what’s already been figured out. And provide consequences for needlessly reinventing the wheel. They frame knowledge and incentivise its curationt. When standards truly matter, an organisation can solve problems once and share with everyone.

In 2021 my role was leading the ‘user-centred professions’, 350+ people across business analysis, content, delivery management, design, product management and user research. Many organisations solve the same problems again and again, in silo after silo, in generation after generation of the workforce. This is the definition of inertia. My hypothesis was that we need to design our bit of the organisation as well as we define our products. Initially focussing on how we work together in teams: if we tried designing our relationships with each other as well as we designed our products (using communities, knowledge, curation and standards) then we could expect to see common problems (like how we really work together in teams) be solved once, for all. For me, innovation is when we solve new problems. This whole thing was about reconfiguring ourselves as a component. A knowledge component. Which is pioneering work. But realising that we can only grow our internal market by simultaneously settling, building and understanding ecosystems. Designing our bit of the organisation as well as we design our products.

Positioning in-house teams

I think we may have to accept that, for all sorts of reasons, some of the pioneering work of building bespoke software to run steps of public services may be done by suppliers. I’m not building the case for this or making a prediction, just naming something I’m seeing.

But there’s a saying, ‘you ship your org. chart’. I think in-house teams have a unique advantage in a couple of spaces at opposite ends of the product lifecycle: (i) generating opportunities and (ii) settler work of developing organisational ecosystems needed for constant improvement.

Generating opportunities. ‘Discovery’ and ‘Alpha’ are simply two phases of developing opportunities. They require huge situational awareness in order to be done well. If you have one two teams with roughly equal skills but one of them has been embedded in the organisation for 1-2 years then it will out perform a comparable team new to the organisation. This is not to say that external teams can’t do Discover and Alpha, they can. And this is not to say that every internal team can do Discover and Alpha well, as that’s not true. If the team is new to each other and/or the team members are new to the organisation or domain then competitive edge is diminished. But all things being even - internal digital teams have the competitive edge when it comes to generating opportunities. If the opportunity is well-developed by an internal team then a supplier can legitimately be provided with a good brief and setup for success for a private beta where they are building software through build-test-learn iterative cycles. Once again, I’m now trying to build a case that this should happen just being pragmatic and suggesting refinement of something I see happen already.
Settling. Understanding and developing an organisation, designing it as well as we design our products, is always going to be best-led by the organisation itself. Transforming relationships requires trust and that trust has to be built internally.

If we can be a little looser about all software having to be built in-house and recognise that in-house teams no longer have the exclusive competitive advantage here, it may free us up to focus where we do have our competitive advantage.

Reflection

I almost didn’t write this post. It’s sketchy. It’s emergent thinking. It needs challenge and refinement. The story around it needs to be clearer. This all takes time that I don’t have right now, leaving this post imperfect. Then I thought, that’s the perfect time to share a sketch - to test it against reality now, learn and improve. I’ve written this with a tight timebox and stream of consciousness. Apologies if you need to squint a bit to see what I’m trying to share.

Brain-splurge over. Now I can look back and see what stands out to me. Here’s are the main things:

The first 10-years of Digital Government have focussed on pioneering work of creating in-house software and components
The ‘settler’ activity of understanding and developing the larger ecosystem has always happened alongside but has been invisible and unofficial work
In-house Digital teams no longer have such a clear competitive advantage when it comes to software development
As our products become more mature, community management starts to overtake software development as a the critical skill
. . . so Digital Government needs to focus on settler work in its next 10-years, eventually investing as much money in improvement of elements of the doctrine pattern as it does in the development of technology
In short, it’s about designing our organisations as well as we design our products.

For what it’s worth, my instinct is that the NHS might be the place that leads (by doing) the settler phase over the next 10-years. Showing by doing. The work of the last 2-years during the pandemic, the recent restructuring, and some conversations with people leading this work all make it sound like they’re explicitly investing in the work of the settler phase. Looking closer to my old home, the Office of the Public Guardian is doing this at a smaller scale. Modernising lasting power of attorney is all about Digital, Operations and Policy working together, along with other organisations in the wider sector, to make deep changes for the better.

I’m going to refine my thinking, improving and simplifying it. Hopefully make it less sketchy, better defined. But I hope there’s at least one thing in here already that you recognise or find useful. And I’m interested to know what you see for the next 10-years of digital government.