Learning to be comfortable with ambiguity

This is a version of a talk I gave alongside my colleagues, Polly Thompson and Jonathan Abraham at Housing Technology 2020 on the 5th of March.

Polly talked about where to start when everything is on fire; helping senior managers understand what’s going on and winning their support. You can read a blog post on the subject here: https://medium.com/valleys-to-coast-design-tech-blog/the-state-were-in-c7549cb03938

Jonathan talked about moving our infrastructure into the cloud and how we’re replacing traditional windows devices with Chromebooks. (Slides to follow)

Hello!

My name is Neil. I’m the Delivery Manager at Valleys To Coast and spend most of my time focusing on the top end of the technology stack where the people and the technology meet… and I genuinely love it!

I love it because I’m really fascinated by people and how delightfully messy we can be. And regardless of the scale, whether it’s teams, organisations or communtities, we’re really talking about impressive complex adaptive systems made up of people and relationships.

And it’s the people that matter most of course. All this whizzy technology is for nought if it’s not improving people’s lives.

This talk is an attempt to compress a 5(ish) year journey of discovery into a short story which will culminate with a small recent example of how we’re currently helping people navigate ambiguity by testing assumptions and learning through doing.

Technology is no longer a thing that’s confined to the IT department. Technology now needs to be a core capability of any organisation. Even where it’s not visible in service delivery, it’s almost always an enabling factor that helps people do the things they need to do.

This image (above) was scribbled by Paul Downey to capture a mantra coined by James Arnold, both of who at the time working in the Government Digital Service.

And what it’s trying to convey is that a small multi-disciplinary team working in an iterative manner can achieve things far beyond the sum of its parts. It means celebrating the output of the team rather than banking on the heroic efforts of individuals to get things done.

As IT people there’s only so much we can do in isolation. To deliver true value, we need to undestand the needs of our colleagues and customers. We can’t do it without them.

I know previously in my work, it felt like “The Business” asked for technological solutions, but often struggled to play an active role in figuring out what the solution looked like. Picture lots of stakeholder workshops where people were ‘volunteered’ to come along and provide input for process mapping and requirements gathering.

Around this time, you may have heard me utter things like..
“If only the business would just clarify what it wants, we can get on and do it.”

What I’ve come to realise is that concept of IT and THE BUSINESS is increasingly a false dichotamy. We are the business. The business is us. Any hard dividers between technology people and non technology people can ultimately only lead to further dysfunction.

To realise the promise of modern, joined up, digitally enabled modern service delivery, we’re going to need to close the gap between IT and THE BUSINESS and make them a cohesive thing.

That does afterall, seem to be one of the distinguishing characteristics of organisations created in the Internet-era. Technology is a central enabling feature of the operating model, not a bolt on or a back office cost.

But understanding how to get there seemed perplexing. I could see the boundaries, the us and them-ness of the relationship, but wasn’t sure how to address it. Why was it often so difficult to work together?

Walking through the housing department one day, I spotted a two by two grid roughly drawn on a whiteboard. It was not entirely disimilar to what’s shown here.

This is called the social discipline window (see above). It leapt out at me as a fairly interesting way to frame the way we work with people and technology.

I would later learn that this is part of restorative practices.

Restorative practices can be thought of as a proactive set of tools for avoiding harm through good, close relationships. Essentially it’s designed to bring people together before situations escalate.

It got me thinking about how people have worked with IT previously, and how the nature of those relationships may have shaped the outcomes we got.

How many previous interactions have ended up being permissive (doing things FOR people), punitive (doing things TO people) or even neglectful (NOT doing anything for them at all)?

What really sold me on the relevence of Restorative Practices to this thing we commonly refer to as ‘digital transformation’ was this unifying hypothesis. And I quote..

“Human beings are happier, more cooperative and productive, and more likely to make positive changes in their behaviour when those in positions of authority do things with them, rather than to them or for them.”

This made me realise that we were only ever likely to get good, sustainable outcomes if we, as technology people, started to work much more closely with colleagues and customers in a more equitable fashion. It seemed like we needed to reframe the relationship to be more adult to adult.

What does that look like?

• Leading with generosity and curiosity.
• Spending more time have open conversations and listening to understand underlying needs.
• Welcoming a constructive dialogue on what we could reasonably do to improve the situation.
• Being honest about what we couldn’t do.. at least for now, and why.

So, having understood that we need to do things WITH people, not FOR them or TO them, how might we decide where we should focus our combined efforts to make the most difference? Where do we start?

When I think about how I’ve previously delivered change in organisations, it strikes me it’s often been inside out.

For example, a problem is identified, an IT project is initiated, a external technology supplier is selected and then we spend a load of time working on the scope of the work to ensure it resolves the problem for front line staff and/or customers.

The trouble with this is, if we haven’t defined the problem correctly, or we’re acting on untested assumptions, we probably won’t know until we put it in front of colleagues or customers. At which point, making changes to accomodate their actual needs will be much harder, more costly and more time consuming because many of the fundamentals will already be cemented in place.

Typically, starting inside out also results in systems and processes being shaped or constrained by internal organisational silos. This often manifests itself as a mish mash of different portals and logins for the customer to navigate.

If we agree that organisations are really just collections of people, and that people are complex and have all manner of concious and unconcious biases that shape our preferences, it seems like we’re not setting ourselves up to succeed in all but the most genuinely predictable and well understood contexts.

Starting Outside in means we spend time really trying to understand what our customers or colleagues actually need. We can then test our assumptions early and often. We design things that are agnostic of the technology we currently have and instead start with an understanding of what people need.

So.. how can we understand what people need BEFORE we commit to any expensive or time consuming actions?

This is a very small example of how we’ve taken assumptions about what we think people need, turned them into a hypothesis and then tested that hypothesis with the people who are going to actually use the thing.

First, a bit of context.

We were in the early stages of putting the requirements document together for a self-service customer app.

Because we were in the middle of some changes to our repairs service, it was thought entirely sensible to start with rents information first, with a view that repairs would appear in a later iteration.

However, some housing colleagues speculated that customers would value reporting a repair over and above anything else. We spent a while debating it around a meeting room table and hit a bit of an impasse about the way forward.

How could we understand customers needed?

What about if we showed the thing to the people who were going to use it and gathered some feedback?

First we thought that we’d show customers the test system, but we couldn’t get access to a test system because we were still trying to specify requirements so that we could get our test system built.

So, instead we mocked up the various screens using Google Drawings and printed them off in a sort of A4 flip booklet. Two of my colleagues from the Housing team (shout out to Howard and Marie) took the paper prototypes out and about with them and showed them to a range of different customers to gather feedback, flipping through the paper prototype, pretending that they’d tapped on certain buttons or menus. Noteably we excluded the repairs button from the prototype to test our hypothesis.

Even after speaking to just a handful of customers, we started to see a trend that although people appreciated having more direct access to their account and paying their rent.. many noticed that a repairs option was missing and asked where it was.

Through open ended conversations, we also gathered lots of other interesting insight which helped inform other decisions that we hadn’t even considered yet. For example…
“It’s asking me for an account number to register, I’ve no idea what that is.”
“I’d like to login via my fingerprint like I do with my bank..”
“I don’t understand this account balance. It’s confusing.”

Even with just a day or two of user research, it proved to be a useful way to have a more qualitative data informed discussion with stakeholders and helped us build a fuller picture of what our customers actually needed.

I actually shared some of this with the supplier of the self-service product as I thought it was likely to be useful for them to really undestand our customer’s needs and shape the development of their product.

Something else we learned from this process was that our digital prototype actually proved to be a bit too polished. People often presumed it was the finished product and were resistant to suggest changes on the assumption that it was too late to change things. We would’ve actually been better off with hand drawn doodles to better convey they were a work in progress.

So to summarise..

• We need to understand customer and colleague needs FIRST to ensure we focus on delivering things of value, and stop delivering things that don’t.
• We ARE the business. Multi-disciplinary teams focused on improving service delivery is I think the direction of travel for the future.
• We have to get comfortable with the fact that some areas we work in are inherently complicated or complex and will require an iterative and experimental approach to understand what works and what doesn’t.. and that’s okay!
• Cheap prototypes that show the actual thing are a great low risk way to test assumptions and learn something.
• Make sure you prototypes and suitably scruffy to indicate they are a work in process that are easily changed.