Standing on the shoulders of average sized but very well organised things.
There’s a tension at the heart of building new things in better ways for government.
It’s at the heart of the books that alumni write because it is an important dichotomy. How do you balance delivering quickly and big enough to keep everyone interested/excited enough to make sure that the political capital and money keep flowing, but at the same time fix the plumbing?
There are examples all over. One of the original GDS exemplars ended the service with a nicely euphemistic “human API” who took the shiny stuff out of the digital service and typed it into some monstrous 1970s mainframe to make the thing actually go. The legacies of years of IT outsourcing, inhousing, technological dead-ends, too-big-to-fail meaning too-big-to-replace don’t get scrubbed away overnight because we did some service design on what the user interacts with.
Sometimes this critique of prioritising user-centred design can overspill into devaluing the approach. But I’m here to try and formulate something more useful.
User needs
I’ve worked in a couple of agencies over the years where in an early sprint plan with a client, you could sometimes end up tying yourselves in knots trying to phrase “sudo apt-get install wordpress” as a user story. “As a visitor to the site, so that I can see words on a screen, I need wordpress installed on an AWS instance”. Of course, there are other ways to cut that and phrase it (many that I’ve learned as a result of those sprint plans) and not everything needs to be a user story, but I use it because I’ve been thinking a lot about how we phrase our services’ interaction with data (open/closed/potential future) and why I think we could do a bit better with talking about it.
For once, there might be something to learn from hack days.
I worked on the Parliament hack days for a couple of years. One of the reasons the old Web & Intranet Service team wanted to run them was to show senior staff how much better the world could be if they let the internet people in. And I think that was a good message, but it ended up being the wrong one. The people are great, but every team that has ever made a hack at a public sector hack day starts off their show and tell with “this would have taken us about half the time to make if the data hadn’t been shit”.
But how do you phrase a user need for the plumbing? Especially when you’re someone like me whose lack of patience for excuses of “the institutional inertia was too big for us to deliver a good service, so we delivered a crap one, but we tried really hard” would make that a little hypocritical?
I think we need to talk about how we design user stories to think about their dependencies, and some of them might be quite deep.
A few weeks ago, I went to the Parliament data team’s show and tell to see how work is going and to ask challenging questions. The one I ended up with was “how do you justify your existence as a team”. I didn’t mean it to sound quite so challenging, I meant it to ask this question. How do you talk about data in a world that rightly has an incisive focus on the benefits to users, but can sometimes lead to short term-ist thinking that de-prioritises fixing the plumbing. But I’m not sure anyone has the right answer yet, but I think we should be talking about how teams do this and the benefits that they bring.
An educated guess at a way of doing this
Assuming we all agree that in an organisation of sufficient size you would have a team (of some size) working on the management and improvement of data, then how could you phrase that work and make it fit with the way that we talk about digital development at the moment.
Wardley mapping
No, no, hear me out. I know it’s peak hype cycle, but this is a good way to trace out the underlying things supporting your product. If we take something like a map of food hygiene ratings, then you’re looking at both the mapping tool and the food data needing to be in good shape, machine readable, openly licensed (or at least, easily licensed) and interoperable. Imagine doing that at end-of-alpha for products, seeing what they could rely on that is in the custom space and helping to move that over into product.
The voice of the user
nb I hate this phrase normally when it is used to mean “Dave met a user once, so we won’t be doing any research on this project, Dave speaks FOR ALL USERS”
Product managers (and, really, all product teams) should be thinking about how to trace a user need into better infrastructure. We’re through with “move fast and break things”, we’re into “move at a decent speed and be constructive”. I worry that the risk with this is that it gives licence to all development under a broad and vague banner of “it empowers the user (eventually)”.
Self organising, business supporting, multidisciplinary data teams
What if you had a multidisciplinary data team? What if their users were the other product teams across their department and the rest of the public sector. What if their users were the private sector. What if they did the research on finding commonalities and then were able to prioritise based on where they felt they could add the most?
Making a (business) case
I think most of these approaches have some merit, but I worry about how we demonstrate utility and gain budget. It often requires something big like GDPR to get cogs moving on institutional technical debt around data.
How can we phrase the benefits of data in terms that aren’t scary “you’ll be fined”, boring “we need to get a new tachyon grid generator to improve the inertial dampeners, but in JSON otherwise the API will transanimate” or routine (the risk of becoming part of the furniture and not given development and space within the institution)?
I’d love to hear how people approach the problem, and how we could codify, write and teach people that fixing the plumbing means replacing pipes just as much as a new bathroom.
With thanks to Dan Barrett, Hadley and Paul Downey for chats that brewed this post.
