Post-it participation

Why “pain points” analysis keeps us paddling at the surface

Doing a PhD can be a lonely journey – you get warned about this early on. Recently I’ve been thinking how long it’s been that I’ve been part of a team routine: the stand-ups, team meetings, 3 o’clock quizzes… Then I had coffee with a friend who told me of their recent team off-site, and a mixed-bag of memories came flooding back. Visions of standing by large whiteboard walls, clusters of coloured notes, people sitting back with their tiny stack of post-its, ready to get up and stick their thoughts to the confetti wall…

There’s something beguiling about the aesthetics of post-it participation. When I recently analysed my restructure documents for sign of staff participation, the hallmarks of early-days “pain points” workshops were clear. Restructure documents are an imperfect source for this, but within its limitations, about a third of restructures references from form of staff workshop in which people had been asked to share their thoughts and express what change they wanted to see.

Pass these around please

These sorts of workshops are almost always “pain points” formats. Everybody gets pens and sharpies, you write down where you think the issues, barriers and blockers lie in your team, or in your wider working environment. You gather, group, discuss. Then you do the same for solutions or improvements. Some facilitators get more creative with this format and might bring limitations or external factors into the discussion.

This is, unfailingly, the rite by which we orchestrate criticism and feedback for teams of people.

I want to write about this today, because I believe that many people are unaware of the blinkers that this way of conveying information introduces into a process of sensemaking. As a technique, it’s so simple and logical – what could be wrong with that? It can put our thinking onto tracks that it’s difficult to come off from later down the road. And thus, I believe that the almost universal use of “pain points” analysis as our main information avenue, is rendered another little piece to the puzzle of our groundhog-day cycles of change, which many of us are frustrated by.

Speak your truth

The great things with simple, open: “let’s list all the things that we thing don’t work well and should be changed” calls is that it lets people express their views in their own words. That itself, as an action, matters. And it’s often the best way to enter a more complex discussion, a warm-up.

But very quickly, when people bring their thoughts to a white board and we see the clusters of “pain points” forming, we find ourselves thinking: haven’t we been here before? We said the same thing at the last off-site, didn’t’ we? When we group and theme such information, they tend to gravitate around the same themes, like communication, tools, culture.

This can spin the whole mood of the team around, as my friend reported from their off-site where an initially good vibe soured after a post-it session that made the repeating patterns of frustration all-too obvious.

A “pain points” discussion intended to have an honest discourse on improvement can confront the members with a sense of futility, when little to no perceived progress has been made.

Photo by Kevin Yudhistira Alloni

I see two reasons for this:

Pain points without systemic maps are (nigh) useless

The way that many facilitators handle the open-ended grouping of pain points can be misleading: it’s a brainstorm tool, one that can help you take the temperature, it helps you find patterns and some sort of order in a messy system.

But if the next step after this is immediately: “what can we do, what are our solutions, what do you want see done?” – then we have left the stage where we can discover any more depth, find the levers and root-causes of the themes we have just generated. We literally jump to solutions.

In my view, this stems from the same toxic-positivity culture corner that told us we should not speak of “problems” - only of opportunities. The fertile ground o fhustle-culture.

Pain points on their own, suspended in the air of discontent, don’t do us a lot of good – until they get placed into context.

This is where a trusty methods comes handy: mapping. On a very base level, if we can anchor our issues and complaints into a systemic representation of the dynamics and conditions that influence them, we turn a single-dimension concern into 2D.

To stick with out team off-site example, it might be wiser to bring out a map of known issues or questions that was produced at the last team day, and ask people to update it. I’ve seen this done a few times, it’s not like it’s a massively different and energising technique, but it shows a.) that there is some kind of institutional memory - that what is being raised does not just get blow out the post-it window. And b.) it can lead us to discuss more meaningful things: What has changed since then? What is the same? If something has not changed that we wanted to change – howcome?

I’m setting this reflection in a team-day setting, but the very same is true for much more impactful scenarios, like those tense team workshops at the dawn of a new restructure, when you know this may be one of the few opportunities you have to put your two cents in before the restructure machine gets into gear.

Give us your paint points, we’ll find the answers

Just asking people for their issues and what they want changed may demonstrate openness, but it sets up your responded to give you information that requires processing and contextualising. And in our current understanding of what aspects of organisational change are managerial prerogative, we place the processing and extrapolating in the hands of decision-makers who take responsibility to interpret the “pain points” they had their staff report.

That’s not an issue in itself, but even if you’re mustering all your empathy and expertise - interpreting someone elses reports is not the same as the person speaking for themselves. There can always be: “yes, but” or “no, unless” conditions that are invisible to even the most well-meaning leader charged with improving their team’s work.

Yet, there’s an approach that I find is massively under-valued and under-used in change scenarios (and perhaps even more in team away-days): and that’s Planned vs. Actual analysis.

If you google this term, you’ll get a baffling list of project management blogs and consultancies. They tend to talk about comparing baseline schedule and project completion milestones…

I advocate, however, to apply just the same question to organisational improvement.

Let’s say a common pain point is a classic: we work in silos – to which the suggested team-offsite solution might be: we should have regular catch-ups.

In a Planned vs. Actual analysis, we would be prompted to put this idea into context: where does this silo occur, and how? Where on the map of our business processes can we point to the silo (likely it’s several places)? And at each of these spots – what is supposed to happen, and what happens actually?

Really, this is a form of root-cause analysis that is cognisant of the ubiquitous existence of workaround. I’ve written about those in a very early post.

Because work in the public sector especially is complex, because we never have enough time to follow process to the t, and because most of us are buddy-trained by people who were also buddy-trained, the un-addressed elephant in most meeting rooms is how much of our BAU is not quite what is supposed to happen.

In a formal business process map (should that exist), information A should be entered into the system by person x, and then accessible to person y who can then add their information B. But the system is a burning platform that doesn’t work well. So person Z told person X when they were buddy-trained to just go and ask the person in the team who has been there the longest, because they always know. And person X only enters half the information anyway, because it takes too long to do it all and they have the next task breathing down their neck.

Workarounds. Unintentional design.

If we don’t know exactly where they lie and what dynamic they add to our machinery, how do we stand a chance of making any informed and balanced assessment on what means can remedy something, or propel us into the direction that the new strategic papers says we should go?

Pain point analysis, used universally as a means to get to solutions, can tunnel-vision us into finding the same repeating mechanisms that likely fuel their existance in the first place.

Investigating the planned vs. actual behind any pain point is, to me, an essential method to make our efforts a lot more realistic, to get skeletons out of closets, and make the next team offsite a little less frustrating.