Where GDS went wrong and what could be done about it

David Durant
10 min readJul 5, 2020

--

A couple of months ago I wrote this blog post about the many excellent things GDS has done since it was created in April 2011 (I’m looking forward to the tenth anniversary party next year).

I wrote it because for a long time I’ve wanted to say something to highlight where I think GDS has been lacking in both vision and implementation right from the beginning — but without sounding like I think the organisation has been a failure, which is far from the truth.

I think GDS has missed the opportunity, provided by creating a new body at the heart of government, to provide a conceptual environment where civil and public servants can collectively build a co-owned space to collaborate in solving real-world problems, regardless of the type of issue or the organisation they happen to work for.

Below I’ll go into more detail about some of the ongoing problems this is causing, but what I really want to highlight in this blog post is how there is an opportunity to change how people feel about the role they play in government. Currently, civil servants will likely say they work for a specific department solving issues related to their department’s particular remit. If they are technical they may use freely shared open source products and a tiny number may even contribute to some of those. What they largely don’t feel is that they are part of one cohesive group, working together to solve problems for citizens.

Before I go into some of the specific impacts this has, I’m going to take a moment to highlight a couple of cases where that kind of collaboration is happening — albeit with minimal support from leadership. The first way is via cross-government continuities of practice. These continue to slowly organically build with some groups becoming well established, such as Data Scientists, some forming, such as Product Managers, and some notably absent (software developers). The other way people are starting to come together to collaborate across boundaries is via the cross-gov Slack. I wrote an article for aPolitical about that.

Moving on to the impact of the lack of this collaborative mindset. The most obvious issue is the massive duplication of work, and hence significant waste of public money. This occurs whenever new digital components are built that duplicate those already existing elsewhere. But, importantly, it also occurs whenever research is done into a particular policy issue without being able to build on work done previously in a different organisation. This is particularly impactful as to be able to do so would likely introduce a more fully rounded and nuanced view of the subject.

It also means that five years after Tom Loosemore spoke at the Code of America Summit we still find it very difficult to bring people together to deliver comprehensive end-to-end services designed around the ways citizens see government — rather than based on how government happens to be structured.

For the record, I’m aware of the GDS Design System step-by-step pattern, but that feels like a patch over a more systemic issue.

Thinking about all of this in the wrong way has led GDS to produce an albeit excellent set of products that organisations across government can use for free, many of which I mention in my post about great stuff GDS has done — linked above. What’s been missed is an opportunity to exemplify and encourage civil servants to feel like they own these things, rather than just getting to use them.

A great example of this is DfE Digital recently posting about how they are creating their own DfE Service Manual. The GDS Service Manual contains a huge amount of excellent content but I strongly suspect that most civil servants wouldn’t know how to provide feedback, offer suggestions for improvement or add new content. I’m sure the gatekeepers are friendly, but they’re also remote and unknown.

From a more technical point of view, GOV.UK Pay and GOV.UK Notify are both fantastic products but they are not Government as a Platform as described by Mark Foden all the way back in 2013. They are high quality free services that government organisations can choose to use instead of a number of similarly cloud based commercial offerings. What they are not are components that are part of a single co-owned and co-produced government digital environment. More on this below.

After years of repeated attempts there is still no single cross-government people directory. Even a simple version of this would be very powerful — and would certainly help provide organisations like the Institute for Government with better data to scrutinise the civil service — above and beyond the value of expediting further cross-organisational collaboration. Ideally, over time, such a service could be expanded to contain the kind of information that significantly enhances the government’s institutional memory. Beth Novek wrote in detail about the possibility of such services in Smarter Citizens, Smarter State.

It’s not that attempts haven’t been made to introduce this kind of thinking. The GDS Submit service (FOI response) was designed to be a mechanism to deliver digital services that spanned organisational boundaries. Meanwhile the GDS project “Tools for Civil Servants”, which was set up while I was still working there, was planned to start providing excellent user needs based services for staff — until it was shut down in favour of the oft-maligned, highly expensive outsourced Shared Services platform.

Bringing things to the present day — GDS very recently released the new Digital, data and technology functional standard. The contents of this document are actually very good. The issue, yet again, is that it is advice being offered from the centre, rather than a co-developed and co-owned continuously evolving document defining the ways of working for a single group of dedicated individuals working as one cohesive group while being spread across different organisations.

At this point I want to point out, just in case it’s not clear, that I’m not advocating for a single GDS-style organisation encompassing everything to do with digital technology in government. There are a number of reasons why that would be a terrible idea. The main one leads on from Janet Hughes’ statement that “Digital is something you are, not something you do”. The whole concept of having a Digital team is something that we should be working hard to make go away. Multidisciplinary policy area focused teams should include digital expertise in the same way as they would have any other appropriate functional expert. In fact, having centralised digital infrastructure would enable staff with digital skills to undertake their job more easily. It’s vital that staff remain grouped together by an area of user needs that they can specialise in — and the department structure works fine for this. What’s needed are centralised systems to make their work easier — for delivering services, to discover previous work done related to their current task and to be able to easily share their work with colleagues across organisational boundaries.

The situation reminds me of a deck that Gareth Rushgrove used to present (which, alas, I can’t locate online) which started with a slide saying “Your organisation is not special” before going on to detail how many self-important government organisations are actually significantly smaller and less impactful than many private sector organisations. If those companies can provide common infrastructure, why can’t the government? That said, I’ll leave the question of whether we need to duplicate HR, Finance and procurement organisations across government to another time.

Although I’m not advocating, at this point, for changing the departmental structure of government, a lot could be improved in relation to how people are able to move between organisations. I’ve known civil servants who have been on secondment for over 10 years due to the massive hurdles of moving to a different organisation. The Canadian Free Agent model is one of a number of viable alternatives.

I’d like to pause for a moment to compare all of the above to the situation at Google. I recently read the excellent book Work Rules by Laszlo Bock — former Senior Vice President of People Operations at Google. In the book Bock describes how new engineers at Google are given access to all of the code in the entire company from day one. They can read and submit change requests to anything almost from the day they arrive. Furthermore, they are not only given time for, but are actively encouraged to build their own new services either for customers or for staff use. Most of their internal staff services, e.g. holiday recording and expenses, have been built by engineers within the company with 1000s of updates keeping them continually fit for purpose. Compare this to the current government practice of outsourcing such services via expensive long term contracts where there is little ability to influence how those systems evolve over time.

Probably the closest thing to what I’m advocating for is currently the MHCLG Local Digital Fund. This is specifically set up to ensure that money is only allocated to local authorities that can demonstrate that the services they are building will be used by a number of organisations. This is still some way though from being what it could be. I would love to see an amendment to the award to require services created with this money to be designed to enable any local authority to use them. I have thoughts on how to achieve that which I hope to go into another time.

So, given the current situation, what am I suggesting should be done? It’ll surprise no-one, I’m sure, that I have a number of suggestions.

Quick wins

There are five things GDS could do relatively quickly to encourage much more collaborative thinking.

  • Create a cross-organisational group of cyber-security leaders to define what cloud based systems should be accessible to staff and implement that decision across government. In 2020 it’s frankly ridiculous that not only is it very difficult to coordinate cross-organisational teams due to lack of access to the same cloud based productivity tools — but that in most cases we don’t know who is making the decisions about what can be accessed.
  • Legitimise the cross-gov Slack and encourage all civil servants to use it. Recognise this powerful tool, pay for it and make using it part of standard civil service induction by all government organisations. There should be a particular focus on bringing many more non-technical people onto the platform — particularly generalist policy specialists. Senior leaders should join the Slack and via their departmental communications make it plain that they expect their management and staff throughout their organisations to do the same.
  • Create a simple cross-government staff login system. Instead of basing this on pulled-in data from Active Directory or any other data sources, it should start with a clean database. A pending user is invited after two existing users nominate them to join and more users can further confirm their identity — providing a crowd-sourced rather than hierarchical mechanism of authentication. Accounts go dormant after a period of non-use (instead of chasing to find out if people have left). Usage is logged with pattern analysis used to locate bad actors.
  • Create a government cross-organisational wiki. This should require a login to update (see above) but should be readable by anyone — significantly improving government transparency. To begin with there should be a small team supporting staff to begin using the service and to be the final arbiter of disputes. However, that group should definitely not be seen as gatekeepers and as many civil and public servant staff should be encouraged to participate as possible. Consider this to replace and greatly expand the role of the Pipeline tool currently used to record information about the development of local government digital projects. Nb — that particular use of the wiki should not be done by making it the responsibility of a specific role. Instead all staff should be encouraged to take pride in the fact that information on the wiki relating to what they are working on, whether related to policy development or service delivery, is up to date.
  • Invest more money in community managers. Examine why some cross-organisational communities are more successful than others and replicate what works. Bring the digital communities and longstanding functional organisations, such as the Finance and Policy professional groups, under one leadership. Strongly encourage the take up of Emily Webber’s thinking on community building. Government should challenge itself, via the Civil Service People Survey, to ensure that the vast majority of staff are active in a cross-organisational community.

Medium term goals

  • GDS should create a “microservices playground” based on the technology described in Sam Newman’s excellent book. Encourage use by technical staff across government by asking departments to allocate half a day a week to working on related projects. Fully support internal staff services built on the platform (especially ones that build better user experience over the top of existing hard-to-use staff services). Define a way to take organisation-spanning services for citizens built on the platform through the Government Service Standard into live production (this will likely be the much more difficult part as the government is not set up for cross-organisational service ownership, never mind risk or financing).
  • Strongly encourage engineers using the microservices platform to focus on building tools to further enable better building of services. I would love to see drag-and-drop service builders, data-connectors, fantastic analytic tools, intuitive A/B testing setups and easy-to-use end-to-end automated testing across the board.

There are numerous blockers to many of the above happening. Entrenched ways of thinking and working, not to mention good old fashioned empire building, are certainly issues — but the biggest problem is likely to be risk aversion. To enable a cross-gov wiki we have to trust that staff can make updates without adding personal private information, part-formed policy discussions or anything that would fail the Daily Mail test.

For the microservices platform (proper Government as a Platform) to be successful organisations will have to start making their data available beyond their current firewalls. This is already often done in the private sector. Most highly successful digital companies have APIs that could provide sensitive private data if compromised but have experienced no such loses. Yet, it still feels like we’re in very early days for that in government — with little encouragement from the centre. I look forward to seeing more about this in the forthcoming National Data Strategy.

Naturally I’d be very happy to discuss any and all of this with anyone. It’s the product of several years of thinking about and, much more importantly, discussing all of the above with a number of people who are smarter than me.

I’ll leave you with this post from Matthew Cain, Head of Digital where I work at Hackney Council. In it Matthew talks about the new AWS Open Government Platform. We don’t know much about that yet, and many people have highly justified issues with Amazon, but perhaps it’s the kind of environment that could be used to create the kind of playground I’ve outlined above.

I hope GDS thinks seriously about what can be done with the opportunity.

--

--

David Durant

Ex GDS / GLA / HackIT. Co-organiser of unconferences. Opinionated when awake, often asleep.