As Mat points out, one of the unwritten stories about if Brexit can be implemented is that of the changes required of ‘government IT’.
How many databases will need to be updated to store a distinction between U.K. and EU citizens? How many government services rely on access to EU systems and APIs? What EU systems do we rely on today that will need to be rebuilt from scratch in the next 18 months?
For all of the above: What are the timeframes? How much will it cost? Has the civil service leadership recognised the problem yet?
If Brexit is going to be anything approaching a success, we need answers to some of these questions asap.
Edit: renamed post to the much better ‘Bye2k’ suggested by Matthew Harris
To finish of this seris of retrospective posts I thought I’d list 7 things that have changed for the better as a result of the things GDS and others across government have done over recent years:
Understanding the needs of users through research (and other methods) is part of how digital services get designed and built. So is testing real things early with real users.
It is now accepted that it is OK to use open-source in government, and that code and designs can be shared across government.
There are the beginnings of shared tools and communities across government that could, in time, start to change the shape of government.
Development cycle-times have been reduced through the widespread use of integration testing, open-source, and user research. (Side note: these are only going to get shorter and different and skills will be needed to take advantage of that).
There are the beginnings of shared platforms that could change how at what speed and at what cost services get built for the better.
It is possible to get a job in government as a developer, designer or researcher and for it to be an aspirational thing to do, and it is possible for government departments to develop services in-house where appropriate.
Accessibility is approached as a core design, development and research activity, rather than a question of meeting a particular standard. (Arguably, this most radical thing that GDS collectively did, and it still looks like it’s leading rather than following several years later).
Question is: what should this list look like in 5 years time?
Transformation projects can be hugely rewarding, but something that needs talking about more is this: they can take a toll on the people doing them.
With transformation projects, you generally can’t talk publicly about the work you are doing. If it fails, it’s like you never did it. And if it works, it (rightly and justifiably) has to be other people’s success.
You can find people who feel threatened by a transformation project, if not quite shouting at you, or subtly trying to undermine your work, then at least being non-cooperative.
The balance between teaching, showing and getting things done is a hard one.
You have little direct control and have to accept you will never get to finish anything, success looks like getting something started, and if it does get started, then that it may head off in a totally different direction.
Being not quite ‘of’ the organisation you are trying to transform is also hard. And when you go back to your ‘home’ organisation, things have often moved on and it’s not clear where you fit in anymore, and there’s no career path.
I’m not ashamed to say that a combination of some of these things, and some emotionally demanding projects, made me quite ill for a while.
Something that has only occurred to me with a bit of distance is this: I think any significant transformation programme should consider putting mental health support in place.
It should also be a risk that people talk about more openly in digital. This stuff can be hugely rewarding, that’s why lots of us do it, but it’s also hard and we need to look after each other.
In reality, it’s something I think to be simultaneously true and not true.
It’s true because you only get good stuff from people with different skills working together, when every member of a team can contribute to the design of products and that it is important to use and understand the materials available.
I also think it’s also true because how we build digital products was changing - platforms like Twilio and Heroku, and mature CSS and web frameworks making just easier to build things. We are increasingly assembling things from components, the lines between development and design have blurred, and development cycles continue to shorten.
In some circumstances, the best designer for a given task might be a developer. Sometimes, an understanding of what you could build, if only you had good data, or could apply a particular bit of technology to solving a problem are the most important thing.
That stuff’s just harder the more distinct the identities of dev and design teams are.
Certainly, some of the civic-tech design thinking that had been in and around at the beginning of GDS seemed to evaporate as professions emerged, and some of the technically driven design ideas from the alpha and beta of GOV.UK, didn’t come near happening for a long time.
However, it is simultaneously not true because making design and development separate, distinct things meant that some amazing designers and developers were attracted to GDS and have gone on to do amazing work.
Creating professions can help scale an organisation. They also mean people have a home, a professional network and a clear understanding of what their role is on a team. That might not have happened without there being a design and development teams in place.
But prematurely optimising for professions does come at a cost.
Professions are an abstraction against a background of constantly shifting practices and technologies, and ideas and people will always fall between the gaps between them. That’s a balance other transformation projects need to think hard about.
## Addendum:
This was hard to write and I didn’t get it 100% right (despite, or maybe because, it has been rattle around in my head for some years).
In the absence of any doubt - and the way I worded some of this created some - I think having world-class designers in government is an important thing. Getting designers and developers into government was why we started RewiredState back in 2008.
Giving those designers a home and a sense of mission was also critical and a huge achievement.
However, I do think that the way teams emerged in GDS had an effect on the type of products we designed, the way we designed, and who practised design, where perceived ownership lied and what our strategic priorities were.
Collectively this also, to some extent, limited our approach to things like shared platforms, data and use of recently emerged technology. However, that does not take away from the achievements.
To put it another way: the shape of organisations inevitably has an effect on the products they make.
Changes: 3rd July 2017 changed: “how we build digital products is changing” to “how we build digital products was changing” to clarify period I am talking about. 3rd July 2017 changed: “That stuff’s just harder when you have separate dev and design teams” to “That stuff’s just harder the more distinct the identities of dev and design teams are” as it is not a dichotomy 4th July added addendum
In 2013, Ian Duncan-Smith said “looking for work should be a full-time job”. This was to be policed through the ‘claimant commitment’ a document that would detail, among other things, the number and type of jobs that someone would be expected to apply for. People would then present evidence that they were spending up to 35 hours a week trying to meet those targets when they signed-on.
Proving you are spending time looking for work has been a component of the British welfare system for a long time. Before the Claimant Commitment, people had to fill out a paper form detailing the jobs they have applied for, and you can go right back to 1921 and the introduction of the “seeking work” test.
Also in 2013, an anonymous group of benefits campaigners released an app called Universal Automation. Universal Automation automatically submitted random job applications on behalf of users of the government’s Universal Jobmatch website - a service that benefit claimants are told to use to look for jobs (and which allows Jobcentre staff to see what jobs they are applying for).
Universal Automation was an exercise in digital disobedience rather than a useful service, but it was an interesting weak signal too. It asked the question: what if finding jobs became something that took seconds rather than a day?
Last week, Google announced ‘Google for Jobs’ which promises to use AI to determine which jobs people should apply for. This is possible, in part, because of the slow but steady adoption by job boards of a standard for publishing structured data about job vacancies* - the schema.org jobPosting.
Traditionally, job search services have used free text search plus a basic understanding of location to help people find jobs. With jobPosting, in addition to the textual description of a job, structured machine-readable data about things like location, job category, skills, hours and benefits can be included.
Better data, in combination with increasingly ubiquitous AI, mean it’s possible to do smarter things - like recommend jobs that fit both your skills and when you need to pick the kids up from school, or tell you which jobs you could apply for if you developed a particular skill.
Google for Jobs currently looks quite basic, but it (or something like it) will soon start to make looking for work into a ‘push’ rather than ‘pull’ activity, and release an enormous amount of wasted human potential in the process.
So what should happen to welfare policy when digital assistants replace the job of looking for a job?
One response could be to carry on regardless - forcing benefit claimants to continue to present evidence of time spent. But if digital assistants get good enough, then this will become tantamount to getting people to dig holes and fill them in again.
A more mature response would see changes both to what is expected from benefit claimants and to the data infrastructure that government provides to support job seeking.
Benefit claimants should be freed up to spend more time on learning and other activities. They should be able to submit digital proofs that apps were looking for jobs on their behalf or that they completed a course online.
The government should support services like Google for Jobs by investing in data infrastructure that increases the quality and quantity of open data about the labour market and skills.
It should prioritise creating open, real-time datasets about career progression, job titles, available skills and demand from people’s interactions with job centres and HMRC **.
Data about child care availability and training courses should be made available, and research into what skills are needed for particular jobs needs to be invested in.
Finally, government needs to create a regulatory framework for services like Google for Jobs to ensure that they support people from all backgrounds and that any potential for bias baked into the service can be spotted early and addressed.
As good design and AI start to become a feature of the working-age welfare state, one of the most effective interventions government can make will be to improve the quality of data those systems use. The days of having to prove “actively seeking work” are nearly over.
- I’m reading between the lines here, but it fits with how Google has approached other sectors, like events ** aggregate, not individual
Tools that help teams make things faster and tools help teams talk to each other better are very powerful levers when it comes to digital transformation.
That networks eventually emerged across government in the form of Slack channels and deparmental git repositories is great, and I am genuinely excited everytime I see an update to the GOV.UK prototyping tools and design patterns that edge them towards becoming a more solid, generic tool-set*.
But, collectively, we did not realise that this stuff was important early enough at GDS.
The Government Service Manual project could have gone in that direction - a place to share and view the progress of projects across government.
And it nearly did (I think the prototype is still on Github somewhere). It could have become a place to link to the source code on GitHub, to list team members and resources of a project, and to share progress against the Digital by Default Service Standard throughout a project. A bit like Launchpad does for various FOSS projects. In doing so, it could have set the expectation that projects should be open and that they should share their work, as well as set the expectation of the sort of infrastructure that needed to exist to support teams like email groups, git repositories, blogs, IRC (this was pre-slack IIRC).
That project was probably never the right place to do that work, but we should have done it in some form, somewhere. We could have provided more tools for communities across government earlier, and we could have built more tools to make it easier to make things.
It’s hard to say why it didn’t happen. Partly, we just didn’t collectively realise it was a priority. Partly, these things are quite boring, quite geeky and hard to explain to people who’ve not had to rely on such tools before. Partly, they cross disciplines/professions, which makes the ownership problem harder and the opportunity harder to see. Partly, there was just lots going on!
Anyway, my main reflection on this is: start investing in your tooling early.
- The accessibility thinking baked into the design patterns is so good it has the potential to have a big impact if non-government developers started regularly using it in place of Bootstrap or Foundation.