I changed my mind

I hurt my back at the end of last year and have spent six months seeing various specialists about it (stick with me here).

Each initial appointment set me back $250 and always started the same way: do an assessment, develop a theory, ask me to get some more tests, then come back for another appointment to determine the next steps. Six months and thousands of dollars later, I had a very detailed picture of my still very sore spine with inconclusive evidence about the root cause.

Then I saw a physio therapist who barely asked me anything. She said “tell me where you’re experiencing pain”, did a short assessment and a bit of massage, gave me some trigger point work to do and told me to come back in a week. The reasoning:

“Based on how your body responds to the treatment and the trigger point work, we’ll get a better idea of the problem and what to do next”.

She was right. My pain reduced by a good 30-40% in the first session and by session 3 it was 70% better. She wasn't skipping the diagnosis. She was getting more information from the treatment itself instead of a bunch of tests that gave inconclusive evidence.

I've spent most of my career arguing to always run a discovery first. I've said in this newsletter that there is always time for discovery, that it just scales to the time you have. I still believe that. But I've changed my mind about what discovery looks like and is for.

I think given where the world is at now, it’s time to start looking at experimentation as a more informative method of discovery than pure discovery alone.

​

PREVIOUS NEWSLETTERS

In case you're a new reader (or just missed them), here are the past few newsletters:

1. ​Is your performance framework too complex? Why borrowing someone else's performance process rarely works, and the principles worth deciding on before you design your own
2. ​What if your promotion was in your hands? - How Juro flipped the script on how promotion decisions are made
3. ​AI isn't the disruption. Our inability to design for humans is - the key takeaways from a roundtable about taking a human-centred approach to AI adoption

When HR gets stuck in diagnosis

People teams do plenty of diagnosis:

• Running annual or bi-annual engagement surveys,
• Holding exit interviews or stay interviews,
• Pulse checks,
• Culture audits etc.

Problem is, a lot of the time the insights from these exercises never truly get translated into real change. And I think it comes down to the kind of data they give us.

All of the methods above collect attitudinal data: What people think, or what they think they'd do. That's useful for understanding how people feel, but it's weak evidence for solving a problem, because what people say and what people do are often two very different things...

Behavioural data is what you get when something changes and you watch what people actually do. It's the difference between asking your team whether the wellbeing program improved their productivity and looking at what whether absenteeism dropped and delivery quality & speed improved.

The other thing attitudinal data does is return themes, and a theme isn't a problem you can solve. "People don't feel like they can see a path to progress" is a feeling, not a root cause. So the honest next step is usually more discovery; why don't people feel like they can progress?

Problem is, we tend to think of this as a trade-off between doing it properly and doing it fast. Discovery feels like more work, without the reward of solving a problem.

But running a small experiment and watching the impact, that can get you much closer to clarity on the root cause & the solution at the same time. My physio got better information in three sessions than six months of scans gave me, and she got it by treating me.

Scope the discovery to the problem in front of you

My physio therapist wasn't doing less diagnosis than the other specialists. She was just doing it more incrementally whilst also solving my problem immediately. That's the shift I'd make with discovery: prioritise testing solutions to symptoms, that allow you to course correct as more information about the root cause comes to light.

In practice that means scoping discovery tightly to the specific problem someone is actually feeling right now, doing the smallest thing that would change it, and treating the response as your next piece of evidence. Instead of rolling out a solution for the entire organisation, pick one manager to work with on a challenge in one team, and then once you’ve found a solution that works - test it with another team.

​Russ at Pixelogic, who I interviewed for this newsletter earlier in the year, is a great example of this:

He didn't start with a People Experience strategy or an audit. He started with the one problem making the most noise, built a single workflow in Crewmojo to address it, put it in front of a small group, and watched what happened. What he learned from that one shaped the next one. Within a year he had around ten workflows running, none of which existed on a roadmap at the start, all of which came from a real problem someone had named.

​

Building solutions iteratively has become easier and cheaper

When I started out, changing a process meant a project, a vendor, a configuration cycle and a big comms launch, so the cost of being wrong was enormous and heavy discovery was the rational hedge. That math has changed. When you can stand up a workflow in an afternoon and change it the following week, spending three months de-risking a decision you could test in ten days is its own kind of waste.

I do have two caveats though:

Discovery should still win when the stakes are high or the decision is hard to reverse. Redesigning how pay is set, restructuring a team, changing something that touches people's security or their sense of fairness: those aren't things you iterate your way into. Getting it wrong there costs you trust you won't get back, and trust is the one thing you can't rebuild in a sprint.

And speed on its own isn't the point. If AI lets us build the wrong thing ten times faster, we haven't become more iterative, we've just built a bad solution very quickly. Iteration is only valuable if it’s helping you solve the right problem, with the right solution. Don’t just “ship it” for the sake of showing you’ve delivered something.

​

Where I'd start this fortnight

None of this means running less discovery. It means changing where you get your information from, and being honest about which method will actually tell you something.

So if you're sitting on a survey report full of themes and struggling to know what to do with it, here’s my suggestion:

1️⃣ Pick the one problem causing the most pain right now. Not the biggest theme in the report, the thing that seems to keep coming up time and time again that is blocking teams from moving forward

2️⃣ Find one manager and one team to work with. A solution tested with twelve people will teach you more than a policy rolled out to four hundred.

3️⃣ Design the smallest change you could make in a fortnight WITH the manager and team. You're not trying to get it right the first go. You're trying to learn something concrete by the end of it.

4️⃣ Decide upfront what you'll look at afterwards. What would tell you it worked, what would tell you the problem was something else entirely.

And if the decision is one of the expensive-to-reverse ones (pay, structure, job security), go and do the proper discovery. That's what it's for.

I'd love to know which problem you'd start with. Hit reply and tell me.

‍