Why new methods fail, and how system maps help us understand what to do about it
Sometimes, it’s easier to focus on introducing a new method for product teams in an attempt to change more fundamental things about how the team or organisation works. But any method or technique can only succeed if it has the right environment.
OKR’s is one popular method for setting goals. Looked at in isolation, it offers a great technique for communicating what you want to accomplish (the objective) and how you’ll know whether you’re getting closer (the key results).
But what might it look like if we mapped some of the behaviours that might happen outside of the OKR framework.
Key:
- Orange = The easy bit.
- Blue = The really hard bits surrounding the easy bit.
Setting OKR’s is the easy bit in the middle. Sure, it takes some time and some discussion, but there’s plenty to read that helps guide teams towards doing OKR’s well.
Then what happens?
If work that doesn’t contribute to the KR’s is explicitly prioritised or implicitly incentivised, then that work is done ahead of work that does contribute. This leads to reporting that the KR’s haven’t changed, and often without calling out that the reason was because other work came first. This can lead to setting new OKR’s (because the old one’s must have been wrong), continuing to do work that doesn’t contribute to the KR’s (creating a self-reinforcing loop), or no one takes any notice because the KR’s didn’t matter anyway.
If the work that can contribute to the KR is done, then one of two things can follow, either the change is reported or it isn’t. If the change isn’t reported, either no one will notice (which signals that no one cares about the OKR’s) or someone will notice and ask for the report. If the report shows no change, this can lead to prioritising work that doesn’t contribute to the KR’s and setting new OKR’s.
Of course, there are an infinity of variations in how these things can play out in real life.
I’m not picking on OKR’s specifically, that’s just for illustrative purposes. I want to show why introducing a new method or technique fails. If the environment isn’t also changed to create the conditions for success, in this example, tackling prioritisation and incentives, the culture around measurement, and the attention of leaders, new methods don’t stand a chance.
System maps can also help us design the consequences too. What should happen if non-contributing work happens? Or if change isn’t reported? Who does something about it? Consequences are the checks and balances that help keep the whole system optimised. Without them, or at least without intentional consequences, parts of the system will tend towards local optimisation.
So, if you want to improve prioritisation, incentives, measurement and leadership, don’t start by introducing a new method.