I was intrigued because this tripartite structure seemed to mirror my own experience at Orange/France Telecom Group, in a division dedicated to the “industrialisation” of solutions pushed by the company’s powerful research and development division. At the end of our chat, Simon took my business card; on it he wrote, “Settler”.
Ever since, I’ve followed Simon’s writing, and, more recently the well-deserved success of his mapping technique as a way for large organisations to acquire some semblance of situational awareness. You should check out his highly readable and enlightening series of posts. In fact, the rest of this will only make sense if you have at least a passing familiarity with Simon’s model. But there are some aspects of the model that bother me, and this long-overdue post is to share them with you.
I write from the perspective of a serial settler. I’m the one who moved from print to new media just as America Online was carpet-bombing the developed world with connection CDs. I joined a mobile operator the year its customer base doubled thanks to first-time, pay as you go, phone buyers. I arrived at the Government Digital Service the week the first, 24-department, transition to GOV.UK was completed.
We settlers occupy a precarious yet privileged position. Simon’s other two archetypes can always reach for a handrail at one or other edge of the map. There’s always something so bleeding edge that only the pioneers geek out about it, and something so commoditised that only the town planners can get excited. But settlers are stuck in the middle, constantly jostled by both of the other tribes. I reckon this positions settlers well to see the others’ points of view, as well as to appreciate the pitfalls of the model.
My first big lesson is this: do not structure your large organisation by pioneers, settlers and town planners.
I know because I’ve been there. In 2009-10, Orange Group wasted valuable months that could have been spent learning about user needs for iPhone and Android apps on a turf war over whether to treat the app store as a site of innovation, industrialisation or commodity. Rather than seek consensus about where on the map any given component sat, each group was incentivised to claim it for their own. This set up a permanent three-way tug-of-war between the tribes.
As anti-patterns go, it’s not much better than the rightly derided “bimodal” approach to managing technology. By all means recognise that the map has different kinds of context, with different attitudes required. But put all the attitudes into cross-functional teams – that way they have a fighting chance of being able to respond as one when the world changes.
My second insight is that evolution is complicated – much more so than you’d guess by seeing the simple x-axis of Simon’s maps. As I traced in my post on the three lives of the front-facing camera, actor-networks form and re-form; unlikely components gain visibility; others recede. Things flip from commodity to innovation and back again.
The use of the term “evolution” bothers me. It carries strong implication of an inevitable unidirectional process. Only with the benefit of hindsight can evolution be said to be a straight line, and that’s just a trick of perspective.
In the words of Michael Mullaney who analysed 20 years of Gartner hype cycles, “we’re terrible at making predictions. Especially about the future.” Gaining a better grasp of the here and now – “situational awareness” – seems more useful. But mapping should not be mistaken for a tool with predictive power by implying that things naturally move from left to right.
It also troubles me that the axes on a Wardley map are not truly independent. There’s a clear correlation between visibility and commodification, which sees most maps take on a top-left to bottom-right drift. This begs some questions. Is there a causal link between the two axes, and if so in which direction? Or might there be a third factor at play?
My experience of organisational dysfunction and dissatisfaction with “evolution” as an axis combine to one big conclusion. Accept this conclusion and I think mapping can be a valuable practice.
Here goes: All maps are socially constructed. Wardley maps are therefore an artefact of social science, not (despite the Darwinian metaphor) a life science. The x-axis shows not evolution but level of consensus.
Exhibit, this table of the different characteristics at different stages. It’s a chart that can only have come from years of astute people watching. Whether he knows it or not, Simon is an ethnographer par excellence…
I say that as a good thing, not a criticism, but it has 2 important implications…
the process of mapping is itself part of the social construction. The act of observing always changes the outcome
a common manoeuvre to secure consensus is to create an illusion of objectivity, so maps contain the seeds of their own misinterpretation.
When we map, we are never disinterested observers. We all have agendas, and whether consciously or not, will use the mapping process to advance them. Elements only move from left to right on Simon’s maps because people move them! And not moving them, or moving them backwards is always an option.
Likewise, whether things are visible or invisible is often a matter of contention. People seeking prematurely to commoditise an element may claim that “users don’t care about x so we can treat it as a commodity.” For example, when it comes to matters like encryption, or where their data is held, user research shows that users don’t care – until one day suddenly they do.
As I was puzzling over this point a few weeks ago, Simon tweeted that: “All maps are imperfect representations. Their value is in exposing assumptions. allowing challenge and creating consensus.”
That is true. But one could just as easily use maps to launder assumptions into facts, delegitimise challenge (and still create consensus). If I wanted to lie with a map, the implied inevitability of evolution would be very convenient to me.
When historians of public service come to write the chapter for the 21st Century, more than a footnote must surely be devoted to the One Team Government unconference of 29 June 2017.
What I witnessed at Impact Hub Westminster was not the start of anything new. The roots of this movement go back years – from Martha Lane Fox’s 2010 letter to Francis Maude, through multiple UKGovCamps, and departmental digital transformation strategies. At times the event felt more like a school reunion.
Nor was it the end of our journey. Frustration and mutual incomprehension remain a reality between digital doers, service designers and policy people in many parts of the public sector.
Yet the way the event was conceived and realised felt like a functional prototype of the networked, empathetic, multi-disciplinary leadership that all big organisations will need if they are to flourish in years to come.
The purpose that animates One Team Government is itself a sign of a maturing movement. The digital pioneers won some early victories, but progress often stalled. Fortunately, from among their number is emerging a group who have figured out how to make friends with other tribes. Meanwhile the smartest people in the worlds of policy and strategy are drawn to collaborate with these designers and doers. Together they’re embarking patiently on a project to create shared new ways of working.
Paul Maltby is doing a great job of prototyping the One Team Gov manifesto, so there’s no point in me repeating here the full set of qualities one team leaders will display. Instead, I’ll focus here on some behaviours that came up in discussion as especially important at this time of synthesis.
They start by assuming that other people mean well and are doing their best. Harry Metcalfe reminded us of the risk of contempt culture, of looking down on others not in our chosen circle. I know I see that frequently among digital designers and developers. I’m sure it is present too among the policy and project crowds. “When people don’t understand each other they sound dismissive of each other,” observed Phil Martin. If we are serious about being one team, that stuff has to stop. Instead, as Lucy Knight put it, “make friends and don’t assume you know everything.” Find the thing that neither of you knows, and seek out the answer together.
They hold out for high standards of user-centredness and evidence. Being part of one team doesn’t mean lowering our standards to the lowest common denominator – it demands that we patiently explain to each other why we set the standards we do. This came across in the session led by Emma Gasson and James Reeve to share what they learned in the original #oneteam on the apprenticeships service. For service designers, this might mean insisting on ethnographic research methods to really understand what’s going on for users. For policy teams, it’s more than OK to seek robust evidence that triangulates the findings from design research. Share the video of the user struggling with the current service. Include the people who will operate the service, as well as those who will use it.
They’re militantly tolerant and inclusive.Kit Collingwood-Richardson, Janet Hughes, and the One Team Gov team worked incredibly hard to make the event a safe, diverse, inclusive space, and I hope their efforts paid off. In her opening talk, Department for Environment, Food and Rural Affairs Permanent Secretary Clare Moriarty encouraged everyone to “bring themself into work”. And that should also go for the people who weren’t at the unconference too. The scientists, the artists, the patient leaders, they may not fit the traditional mould of civil servants, but government needs their involvement more than ever.
They work at their most confident in the open. Clare reminded us of civil servants’ duties to be open and transparent, to maximise the benefits to society, and to account for decisions. We also need safe spaces to consider and make those decisions. Increasingly those spaces will be online, in digital public spheres. It was interesting to hear that when the Institute for Government sought to research among middle-ranking civil servants, the ones willing to talk to them were those working on digital services. I sense that for One Team Gov leaders, working in the open is far more than a legal obligation; it’s an emotional and practical necessity.
They’re not waiting for permission. Here’s the thing: these future leaders are forming their own networks and making stuff happen for themselves. They’re #OfTheGovernment not on the government. Please take that as a promise not a threat: they are a powerful force for good in the organisations lucky enough to have them. I’m quite sure that somewhere in the room that day was a future head of the Civil Service.
The One Team Government unconference was awesome. I’ll write another post about the event overall. For the time being, here’s a quick write-up of my session, in which I revisited the Gaps Model of Service Quality and how we might use it to embed #oneteam working in our organisations.
I might have done a better job of pitching my excitement about Parasuraman, Zeithaml and Berry’s seminal work from 1985, because when it came to the session, only two people turned up. But they were absolutely the best two people: thanks, Nayeema and Liam, for taking the time to talk this over with me.
I started by sticky noting the key features of the model, last cited on this blog in the post “Most of government is mostly service design most of the time. Discuss.” The authors propose that if we want to know why organisations so frequently fall short of meeting their customers’ service expectations, we should look to 5 gaps in the typical operating model where information and understanding get lost or misinterpreted. Becoming #oneteam means closing those gaps.
Nayeema, Liam and I talked though the gaps, and the tactics we might use to overcome them. As we talked, I tried to map the notes to the relevant parts of the gaps model.
These are some of the things we talked about…
Gap 1, between user expectations and organisational understanding
The importance of understanding the end-to-end service, which may be larger and more complex than the bit that our organisation or team delivers
We noted the positive trend for departments and agencies making big service maps, for example the Ministry of Justice’s digital justice landscape
The rising tide of user expectations, shaped by other digital services, making user needs a moving target that demands constant re-discovery
Gap 2, between understanding users and specifications that will meet their needs
We talked about the value of prototypes as specification – why describe the thing when you can show it?
But also the danger of confusion between a “vision prototype” and a functional one – when we show an alpha, we need to be clear what we mean it to prove
Risk of the team’s commitment to meeting user expectations being eroded in the face of organisational reality. We need regular top-up doses of primary research to keep us connected to users
Gap 3, between what we specify and the service we deliver
Are a user story and an epic enough? Probably not! The team needs to communicate and use multiple methods to make sure the intent becomes reality
Delivery is more than just the digital thing. We need to include everyone who contributes to the user’s experience early and often, not expect operations to come in at the last minute and fill in the gaps without context
Is it time to kill the concept of “business as usual”?
Gap 4, between what we communicate to users, and what we deliver to them
Rather than saving up for a big bang reveal to users, agile teams should be telling their story a little and often
We need to consider when to start communicating and to whom
As well as end users we should consider the expectations of other actors. Frontline workers’ past experiences may make them suspicious of change, and their cynicism will be communicated to users
Gap 5, between expectations and perceptions
This gap is different because it’s the cumulative result of the other gaps, rather than something we can influence directly
If we work on a service that people use repeatedly, we have more chance to influence their perceptions through experience of the service itself
Services with less frequent or one-off use profiles still come with expectation – but they’re more likely to be shaped by other services than our own
I asked whether this 32-year-old model was still useful to us in 2017. The consensus: yes, but we’d need to adapt it. We would…
Draw the gaps model to emphasise the feedback loop to understanding
Look for ways to cycle faster through changing understanding, specification and delivery to meet user’s rising expectations
Match the pace of introducing new ideas to delivering them
Minimise the hand-offs by asking one team to go on the whole journey together
On Monday I’m joining NHS Digital as head of design. My focus will be with teams delivering patient-facing programmes, while developing designers and the design profession across the whole organisation. I can’t wait to get started!
Over my years of consulting, I’ve been lucky enough to work on many and varied things, from Internet of Things energy controls, to digital skills development for health and social care practitioners. With GDS and the DWP Digital Academy, I’ve developed and delivered courses for hundreds of civil servants.
As I’ve gone along, I’ve evolved 4 questions to filter and focus the engagements I take on:
Is there a service design challenge here?
Does it involve digital innovation?
Will I be helping to develop capability?
Can I do this work mainly in Leeds?
When I saw this opportunity back in February, I realised I was missing an unspoken fifth question:
Could this be a massive, multi-year, challenge for me?
Through a series of interviews and informal chats with others who know this space much better than I do, the temptation to work alongside great groups of people delivering such important service continued to outweigh my trepidation at the scale of the challenge.
For one thing, there’s the impact of the stuff this organisation is delivering to meet user needs. Patients, service users, families and carers have a visceral need for information about their health and care; it’s about them personally. At system scale, small changes can make a massive difference.
Secondly, I’ve found it hugely rewarding in previous roles to help designers develop their practice into a strategic capability for the whole organisation — making visible what’s valuable, and supporting creative leaps to deliver better service.
And further, I have long held a hunch that the practices of co-creation and co-production emerging in health and social care will be the foundations for the next phase of people-centred service design. If we want to transform the relationship between citizen and state, we should start by understanding the changing dynamics between patients and practitioners.
Fully committing to this role means tying up my consulting engagements, including my coaching with the Digital Academy. I’ll miss them all! (My Stick People colleagues Kathryn and Sharon will carry on their work, including the GDS Service Manager Programme.)
As with any new job, the window of opportunity to shape things comes just when I understand the least. My week one priorities are to hear from the designers and key stakeholders, and to observe some user research on the programmes we’re delivering. Further out, I look forward to working more widely through the health and care system, and with the community of heads of design across government.
My colleagues and I will need all sorts of help from other people. We’ll need to develop ourselves as designers and design leaders, to strengthen our networks across the whole health and care system, to clarify and simplify every part of the service that we touch.
I’ve been reading up in preparation for the new role. The following seem particularly relevant right now: