86: The 4 unintended side-effects of risk aversion and what to do about them
I’m writing about 100 things I’ve learned the hard way about product management. You can catch up on the previous entries if you like.
Risk is knowing there’s a steep cliff at the side of a mountain road.
Risk management is having metal guard rails to stop you inadvertently driving off the cliff.
Risk appetite is how far or close to the cliff-edge the guard rails let you drive. (Or possibly how easy or difficult it is for you to break through the guard rails.)
Risk aversion is simply closing the mountain road to begin with, and having to go the long way round instead.
When we become more worried about risk, four unintended things also tend to happen: bottlenecking, erosion of trust, ossification of process, and a risk appetite that tends towards zero. Here’s what you can do about them.
Risk and trainee pilots
Early on, trainee aircraft pilots practice ‘circuits’ to build up their experience with the two riskiest aspects of a flight. A circuit is a take-off, a quick loop around the perimeter of the airport, then a rolling landing and take-off again.
The take-off and landing are particularly risky because the aircraft is low to the ground and flying comparatively slowly. Should a problem occur, the pilot has little time, height and airspeed with which to manage the emergency.
Rather than avoiding the risk and hoping it never happens, pilots practice over and over so that if the worst does happen, they can react quickly without panicking.
Different types of risk
One kind of risk in product management is the risk that comes with uncertainty. We never have perfect information, so we’re always working with a degree of uncertainty and risk.
Another kind of risk is regulatory or legal risk. As organisations become larger, with more customers, turnover, investors to look after, their risk appetite often decreases: they have more to lose.
A symptom of this decrease in risk appetite is often an increase in process (more checkpoints, reviews, steering groups etc.) and greater power of veto to the areas where the greatest risk is perceived.
It’s for this reason that an organisation fearful of any legal action against them will probably require everything to go through a legal team for approval. Similarly an organisation in a highly regulated market, fearful of fines for breaking the rules, will have a team dedicated to checking regulatory compliance or adherence to accepted process. You sometimes see the same thing with information security (infosec) in organisations dealing with sensitive or secret information.
4 unintended side-effects
While there is often good reason to place focus on these areas, four unintended things also tend to happen: bottlenecking, erosion of trust, ossification of process, and a risk appetite that tends towards zero.
When responsibility for expertise in legal, regulatory, procedural (or whatever) decision-making is centralised in a single team, and this is coupled with a organisation-wide mandate for everything to go through that team, it’s reasonably likely that this will create a bottleneck. This will inevitably slow the rate of product delivery.
Part of the problem is that the centralised team lacks sufficient context, and so has to get up to speed with the specifics of the product and the situation that requires their guidance, before confidently making an assessment. In the same way, a centralised team will often have more open ‘cases’ than team members, so context switching will tend to occur, particularly if delivery teams are seeking updates on their case.
In the organisations I’ve worked with, there can be a tendency for people to become gatekeepers of ‘arcane’ (legal / regulatory / procedural / etc.) knowledge that lesser mortals could not hope to understand. Their knowledge becomes powerful because the organisation only trusts the people with ‘arcane’ knowledge to take decisions.
However, encouraging delivery teams to acquire the same knowledge for themselves empowers them to take their own decisions again, alleviating the bottleneck. Ideally, a centralised team should strive to make itself redundant by reducing the rest of the organisation’s dependency on it.
Solutions to bottlenecking: #
- scale up the centralised team (a short-term solution with diminishing returns); but then also
- decentralise to multi-disciplinary teams — embed specialists from the centralised team into the delivery teams to reduce context-switching.
Erosion of trust
Another unwanted side-effect is the erosion of trust in a delivery team’s ability to seek advice where needed and make sensible design decisions based on their understanding of the risk at hand. If the organisation doesn’t trust the teams to take sensible decisions, then it will shift their power to take decisions to the centralised legal / regulatory / process / etc. team.
When coupled with a drive to have teams deliver more stuff more quickly (to counter the decrease in output the bottlenecking has caused), the team will start to prioritise very low-risk work to allow them to keep moving forward. However, this has the consequence of stifling any real product innovation, which is reliant on a degree of informed risk-taking.
When something is going wrong, a common reaction is to pull decision-making further up the hierarchy, as if the executives higher up are simultaneously vastly more knowledgeable, experienced and infallible, all while being several steps removed from what’s actually happening on the ground.
Trusting and encouraging the people with the most situational awareness to learn from their mistakes gives them an incentive to grow; taking away that trust encourages them to abdicate all responsibility for mistakes.
Solutions to erosion of trust: #
- invest in up-skilling the delivery teams to be able to take sensible decisions for themselves, through training and assessment; and by
- embedding a specialist in the team both to guide the team and help to up-skill them.
Ossification of process
Itself under pressure to reduce bottlenecking, over time a centralised team will attempt to become more efficient in its risk assessments. Standardised processes will emerge and be codified into flow diagrams, but once that is done it becomes much harder to change the process — the point was after all to reduce variance in the process. However, it also is based on the assumptions of ‘one process fits all cases’ and of the context itself never changing.
This ‘ossification’ of process (the hardening of what was flexible into something rigid, as with bone formation) can be incredibly frustrating for delivery teams, and again stifles innovation and change through constraint.
Teams I’ve worked with often have found themselves constrained by ossified processes. I hear “that’s not the way we do things round here” and “that’s non-compliant” without anyone checking whether the received wisdom is factually correct. The fear of repercussions if the team makes a mistake and the reinforcement of the status quo by the organisation just make it too much effort for the team to attempt to change the process.
For years, a team I worked with had been persisting with paper application forms because of the received wisdom that they needed a physical signature from the user. When actually checking the relevant laws, it turned out not to be the case at all in many common situations. This let them ditch the paper forms and redesign the user interaction more freely.
Solutions to ossification of process: #
- an underlying assumption that (user / legal / regulatory) needs are not static, and change;
- an openness to evolving the process when needed to better serve the circumstances; and sometimes
- accepting that the circumstances are too variable to have a standardised process in the first place.
Risk appetite tending towards zero
The last unwanted side-effect can be when the centralised team starts to move from an appropriate risk appetite specific to each context towards blanket avoidance of all risk.
In general (assuming a normal distribution or bell curve), the minority of risk assessments will be an easy ‘yes’ or a hard ‘no’, then everything else is going to be a grey ‘maybe’, or ‘it depends’. As risk appetite decreases, the grey areas will simply become ‘no’s.
I worked with a team that insisted on manually checking every funding application for fraud. The fraud check was labour-intensive and time-consuming for the team, and made the user experience far more complex because of the additional information they needed to ask the user for. I asked them what proportion of the applications they received were fraudulent: essentially none.
In the short-term it would make sense to reduce the sampling of applications for fraud from 100% to 10% or even 1%. This would at least reduce the cost and effort of the fraud checking, if not simplify the user experience.
However in the longer term it would also make sense to review the percentage sampled in case users got wise to the fact that applications were being checked less stringently, and adjust their own behaviour accordingly. (The current fraud rate may have been very low because users knew 100% of applications were being checked.)
Solutions to decreased risk appetite: #
- better understanding of the likelihood and impact of a given risk in a given situation, which can take time to assess;
- maintaining a risk appetite that permits the undesired outcome to occur from time to time; and
- having a balanced portfolio of bets — some with higher risk and higher reward, some with lower risk and reward.
Risk is not something we need to avoid altogether. Rather it’s something we need to learn to live with safely.
Like airline pilots, stunt performers will take sensible precautions and practice over and over to minimise the risks associated with a stunt. They can’t control everything, and they accept that there’s a possibility that things will go sideways, so they endeavour to reduce the ‘sketchiness’ of the stunt.
In just the same way, we need to make sure we have a sensible safety net and other measures to keep us safe. We still undertake the risky activity. We do not avoid it completely.
Get articles when they’re published
My articles get published irregularly (erratically, some might say). Never miss an article again by getting them delivered direct to your inbox as soon as they go live.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton
Agree? Disagree? Share your views: