Weeknotes S1 E7 (2019 Edition)

Shwmae! (“Hi there! / Alright! / Hello!” in Welsh)

This is my two and a bit weeks worth of weeknotes. As I’m writing this, my bed is calling me, so I’m going to attempt to keep it reasonably breezy and slot thoughts into themes.

Theme 1 — Transactions & Interactions

There’s a thread of my work that is following the concept of ‘customer experience’. It’s interesting that this sort of thinking has suddenly landed in the world of social housing (or perhaps it’s that thing where I’m more aware of it so I’m seeing it everywhere).

Anyway, a couple of weeks ago I had an excellent serendipitous exchange with Matt Ballantine about the difference between transactions and interactions. Essentially he put it that we can scale transactions because they’re mechanical, but we can’t scale interactions because they’re human scale.

I’ve often said that as far as technology goes in social housing, we’ve got to be really careful about what gets automated. Arguably, freeing people’s time up so that they can add value to things that humans add value to is a good thing. Making all of our services totally faceless and devoid of compassion is a bad thing.

I’ll give you an example. Those automatic congratulation messages on LinkedIn *shudder*. They’ve automated what should be a pleasant unique human interaction, and in doing so have made the whole thing completely shallow and devoid of meaning.

So.. it’s important that we recognise what’s a transaction (I just want to do this thing and move on with my life) and what is an interaction (I would like to talk to someone about this because I need help understanding it) and treat them accordingly. (Matt’s given me some further reading on this which I really must follow up on)

Theme 2 — Data Disfluency

I’ve been talking a lot about data lately. We’ve got lots of it. It’s potentially really useful . But people often struggle to know what data they’ve got and what questions they can meaningfully answer with it.

We’ve also got lots of tools to interrogate said data. For people that are not used to working with data, that usually means DASHBOARDS! The problem with dashboards is.. well.. they’re often made by techie/data people for other people. They make things easier to passively view, but at the expense of really understanding what the data means or where it came from.

I’m reminded of the concept of ‘data disfluency’ coined by Charles Duhigg.

Duhigg introduces the idea of data disfluency as the best way to absorb information. We can’t passively accept information as it comes at us, but need to transform it into experiments to test ideas. By making data harder to interact with, or more disfluent, we paradoxically make it easier to understand.

We’ve been working with a head of service who wanted to collect data about service delivery. Many of things he wanted to analyse couldn’t be captured digitally. Largely it relied on staff marking down tally charts. Next came a laborious process where the head of service had to collate the data into a spreadsheet so that he could begin to make sense of what was going on.

It was, to paraphrase him somewhat, a pain in the arse. But, in working directly with that data he gained a much clearer understanding about what was going on. The work of actually collecting the data gave him more context about what the data meant and what changes he might need to make to move certain measures in different directions.

When thinking about ‘data maturity’ in organisations, it makes me wonder if there’s anything short of this approach to really helps people understand the data they have at their fingertips and what it meaningfully means to them. This is also another example of the benefits of doing things with people, rather than for or to them.

(This didn’t prove to be as light and breezy as I’d hoped.. but.. ah well)

I’ve been reading…

Leave a Reply

Your email address will not be published. Required fields are marked *