Last night I went along to the first Ad Hoc enquiries. It's a new approach to doing an event. Someone is invited to present on a topic within the broad sph...
A quick explanation of what Patchwork is
Patchwork is a simple service that allows social workers to see contact details for other social workers working with the same family and when they last visited them. So far it's been trialed with two Local Authorities.
It's often very difficult for case workers to easily find out who else has been working with a family using existing systems. They can spend hours tracking down contact details and phoning round. This means that care isn't joined up and that it's harder to manage good working relationships with the families. Unsurprisingly research shows that the better the relationship between families and social workers, the more likely you are to safeguard the well-being of the children.
In summary then, Patchwork uses technology to provide an effective solution to a known problem which in turn contributes towards achieving a much greater goal. It's great to see local government experimenting in this way, especially in an area which as as sensitive as social care.
There was a fair amount of debate about Patchwork's process, aims and success last night. Given the theme of the evening was "imaginative, liberating technology", much of the conversation revolved around two points - are we investing too much in technology as the agent of change and is this service really an example of "disruptive innovation"?
There were a lot of diverse points of view and challenging comments but a few things stuck in my head, which I think have relevancy to anyone interested in innovation.
Can user needs drive disruptive innovation?
Last night one of the key themes was whether you can innovate when working within a system. If you think the status quo is fundamentally wrong but your design is driven by the needs of those working in that system, will you not end up being constricted by the very system you want to challenge?
Ok, I have a few thoughts on this but I'm going to start by re-iterating that I'm in favour of user-centred innovation. If you're creating a service, I think putting users needs first works.
Understanding user needs doesn't just mean giving people what they say they want. You have to be endlessly creative to find ways to understand what peoples' underlying needs and motivations are - that's why this process is hard. And then you have to collide your own expertise together with that understanding to develop new approaches and propositions.
People might be surprised by what you come up with, but if you have understood their needs well then they'll get it and, crucially, want to use it. You can innovate alone in your creative cave all you like but there's just no point if the people you are making things for won't want to use it.
You need to consider everyones' needs to be able to design a service well. In this case, that means children, their families, social workers, the Council and also those who have a more indirect relationship to the delivery of the service. But when you design that service you will probably find you have to carefully balance those needs with each other, and end up making some tough decisions about your priorities. At this point, I think it's helpful to always question whether the decisions you are making help you achieve your overall vision.
If you want to create change in a system, you need to gain the trust of the people working inside it. This means making compromises and sometimes taking smaller steps so you can show people they don't have to be afraid. You can be far more disruptive when you're working outside the system, but in the case of something like social care this is very difficult to do.
Yesterday we dicussed the best possible way to innovate within a system. Where possible, work with the mavericks - identify the people who are already innovating and are most open to trying new things, help them and then lead others by their example.
The role of technology
As Dustin O'Hara said:
we're at the point where our knowledge is being rewritten from prose to code
The tools and technologies we use in our lives now play a far greater role in how we do things than before. Ian told us an annecdote about how social workers often tailor what they ask families to the questions they have to fill out when they write it up later in the system. The technology they are using determines how they do their job, not vice versa.
Today we change the platforms and applications we use more and more frequently. The decisions that are made by those of us who design and develop these platforms and apps has a huge impact on how people will use them. We can embed existing behaviours or open up routes to new ones and we need to be hyper-aware of that.
I'm not going to go all Marshall McLuhan about it, but it's naive to think that organisations can innovate now without having technologists in the room. You want people embedded in your working culture who get this stuff or it's going to be done wrong.
It reminds me of an old post by James - the concept is the execution.
The part played by technology is of course just one piece of a much wider picture but it is an increasingly vital one, especially as 'digital services' expand beyond web and mobile. The number of digital touchpoints is proliferating in everything that we do.
Being innovative = lots of experiments in pursuit of a greater vision
Last night, someone criticised Patchwork for being "just a CRM" and Ian responded that it was acutally so much simpler than a traditional CRM, and that's what makes it special.
I was reminded of something we talk about a lot here - how small solutions to small problems can be much more effective than grand ideas. Innovating is often about starting lots of small experiments with many different approaches to the same problem. An environment that fosters that kind of behaviour is far more likely to come across ideas which disrupt the status quo.
It helps to have a unifying vision that holds these experiments together, an overarching goal you are working towards. I came across a comment from Dave Morin lately which summed this up for me:
When the first version [of Path] did not work entirely, it became imperative to unlock the things that were working and become a more true version of the original vision. You must stay in the problem long enough.
I also think you need to leave a healthy amount of what Conor calls "hackable space" in the service you develop so that users can bend it to their own needs and desires. Often this is where unexpected innovation occurs.
Lastly, I'm not sure who said it last night, but Patchwork definitely feels like a "yes and…" solution. The aims of the team behind it are much more ambitious than the initial service might lead you to believe. It's not the final answer to a problem but a gateway to new approaches.
I know I'm biased on this side of the debate, and I really enjoyed having a critical discussion with people at Ad Hoc who have very different perspectives.
Huge respect to Ian for being so open about the process behind developing Patchwork, and to the team who continue to take Patchwork forward. Hope you don't mind me using you as such as extensive case study in this post, it wouldn't have made much sense without the context.