Working open works (1)
I gave a talk at (the amazing) Service Design in Government conference yesterday as something of a last minute speaker (I got the call Sunday afternoon for Wednesday) and as such I didn’t create the talk in quite as structure way as I usually do
. This meant that while I had slides and a basic framework of what I wanted to talk about I hadn’t actually written the talk — nor rehearsed it outside of the voices in my head. I think it showed but I hope my passion for the topic got me through. Amazingly I kept to time as well!
Anyway this is basically a preamble to say I am now retrospectively writing the blogpost(s) that would usually provide the detailed notes for the talk. Lets see if it bares any resemblance to what I said on the day!
Hi I’m Matt Jukes — usually known as Jukesie. I was a public servant for a long time — most notably at ONS, spent a year as Head of Product for digital democracy social enterprise mySociety and these days I am a ‘Product Coach’…apparently….but you could have found all this out in advance of this talk as I am an ‘open book’..
..well I am sort of…professionally I operate in something of a radical transparency approach and I also subscribe the ‘whole person’ approach to social media and life online — no separate ‘work’ accounts for me. That said though there is a LOT I do not share..
I firmly believe that my career has been significantly improved by my openness as have every project I have worked on and it is something I look for in organisations I might work for now as well (at a minimum a willingness to — paraphrasing Aaron Sorkin here — Let Jukesie be Jukesie :D
[sidebar] I have taken to referring to this user-centric, service designed, agile, dev-ops-y, putting people first way of working as this ‘thing of ours’ — every other term seems to annoy someone and I loved The Sopranos.
Anyway back to the main track. My hypothesis — in fact the metaphorical hill I’m going to die on — is that working in the open is the (not so) secret sauce that makes this ‘transformation’ even possible. That it is the foundation all these other great ways of working are built upon.
In the morning intro Lou talked about the new ‘Government Service Standard’ that is replacing the original ‘Digital Service Standard’ with a broader, more end-to-end service focus. Part of that is about the importance of working across organisational boundaries and that has to happen at multiple levels — openness makes this a reality.
Then Whitney talked about the need for content, collaboration and communication in making service design work in complex Government environments with broad range of users. All these Cs are made easier with an open approach.
IMHO.
So I’m going to broadly break this talk up into 3 sections though nothing is quite this clear cut — I’m going to talk a bit about what I consider working in the open (and a bit about what it isn’t), a lot about Why you might do so with a bunch of examples and then just a few people, projects and places I admire for their approach…
[This blogpost is mainly the What]
Given the subject of this conference I shall assume you are familiar with GDSs Design Principles? These principles remain amongst my favourite things GDS have ever done (for the record the Service Standard, Assessments, Service Manual, Spend Controls and Blog.gov.uk make up some of the others) I only ever really cared about about 2 of them — the first (you all know that one — for many of you it is what brought you into the world that led you to this conference) and the tenth — this one. This was the one that really gave me a warm glow when I first saw it as I felt like this gave me permission for all the decisions I’d already made about how I operated! It is difficult to just articulate how radical this actually felt — openness was not how people thought about the Civil Service. Quite the opposite. Some of that was just perception but much was true so this was amazingly brave.
Actually though it is Mozilla with whom I spent some time as a volunteer where I really learned about how and why open was important — particularly lessons I learned from another Matt (Thompson). He has written a number of posts over the years where he outlined what it meant to ‘work open’ at Mozilla (in fact I think he might be writing a book about it all now). Hell even his Twitter name is OpenMatt.
Here are a couple of things he said them that have always stuck with me:
participation. rocket fuel for smart collaboration.
agility. speed. flexibility. getting shit done.
momentum. communities want to push boulders that are already rolling.
testing and rapid prototyping. iterating and refining as we go.
leverage. getting greater bang from limited resources. punching above our weight.
and importantly:
Working open is more of a slider or dial than an “on/off” switch. At a given point in time on a given project, you might collectively agree to work in a range of different gears or levels of open.
I’ve always defined ‘leverage’ somewhat differently in this context I have to be honest. Working open and putting the change you want to see out there for others to see leverages change locally — basically you create external pressure for internal change. Risky but often worthwhile.
The thing about all this openness is it absolutely has to be authentic. There is no point in doing it if you are just going to share the wins, are going to spin the hell out of everything you put out into the world. The savvy can smell that a mile off. Like Matt also wrote — Working open is NOT about ‘public performance — creating the fake appearance of consultation.’ Or the fake appearance of transparency.
It is also not about ‘endless opinion sharing’ — which apparently ended up sounding like this live →
That is the end of Part One. In Part Two I go into a lot more detail of examples of WHY working in the open works for specific use cases.
