If I had to point out one skill that differentiates great makers I worked with, it would be deliberate derisking. Everybody does it to some extent, but rarely as a constant discipline. It drives success and, once in motion, molds thinking and triggers valuable practices in all areas of life.
In short, you derisk by identifying future, expensive problems early on and finding ways to circumvent them. It is asking yourself, how could this go wrong? It’s asking yourself whether your wallet is in your pocket when you’re leaving the coffee shop, or getting reviews on your paper before you publish it. It’s thinking about knowns and unknowns before you invest your time.
Derisking is applied skepticism. You allow yourself to venture briefly into pessimism for short bursts of time so your brain has the environment and background to identify edge cases and think outside the box without analysis paralysis. In the process, it turns you into a realist and builds a healthy optimism. You and those around you being understanding in more depth the factors and the conditions that will drive your outcomes and decrease failures.
The process is somewhat straightforward and can be done mentally for everyday tasks depending on size. The decision on whether to mitigate a risk will depend on the risk-reward ratio. If the cost is too high, it might make sense to do nothing. On the other hand, if the cost of mitigation is too low, it probably makes sense to do it. Sending an email is low cost, but could have a high impact on the recipient. These are what we call asymmetric opportunities, inexpensive actions that can result in high rewards despite low risk.
To start simple, create a table with four columns: Risk, Probability, Impact and Mitigation. Each line is a risk. If you have a larger, high-stakes project, you will want to go into full details about each risk and their ramifications. If not, do it mentally.
Here are a few examples of derisking from different areas in life and their positive ramifications.
Risk leads to change in work cadence: long projects usually cause a divergence between what is expected by the customer and what is built. That is why architects build 3D models before construction, for aligning expectations on physical aspects and feelings (cozy? sober?).
- Risk example: “Customer doesn’t find our solution useful”.
- Probability: “High”.
- Impact: “We lose trust and, subsequently, the deal”.
- Mitigation: “Deliver in small matches so we get signals from the customer as soon as possible”.
- This one is cheap to be done and can increase the customer’s trust. The Lean methodology was built around this problem, inspired by the scientific method which focuses on setting a small hypotheses and testing them so each step leads into the next.
The software industry suffered for decades with the so called “Waterfall planning”. It was meant to be like a house construction where you make a big plan upfront, document it, then develop it. The customer would only see the product once every detail was developed and implemented, often times with wrong requirements, a year or two later. In the 2000’s, a new manifesto was written proposing an iterative approach to decrease risks, by showing the software to the customer every day or every week.
Those small iterations reduce the risk of project dead ends.
Risk drives transparency: the risk of writing a 400-pages book and failing forces writers to get constant reviews and feedback of their drafts to make sure they’re going in the right direction. At work, the equivalent is getting feedback on plans constantly. That opens up the building process and everyone feels transparency, which helps with trust and aligning expectations early on.
In this new remote work world, I find it useful to say out loud the things I know most people are thinking about, topics such as anxiety about communications and expectations. It’s really to check in with people and hear their thoughts and identify what’s not transparent yet. This helps coworkers open up and support each other. This sense of transparency also helps leaders identify and anticipate problems before they have grown too much.
- Risk example: “Code written is confusing for coworkers”.
- Probability: “High” (most software code is painful to read).
- Impact: “No one can change the software quickly later on, therefore the company suffers”.
- Mitigation: “Create quick drafts of ideas and share with colleagues before work starts”.
- Besides helping yourself with feedback, it shows your coworkers that you value and trust their opinions. It drives a culture of transparency and soon other people will be reaching out asking for feedback, making the organization more proactive. More transparency means less mistakes and bad decisions. That’s one of the reasons why top-down orders are usually frowned upon.
Risk drives personal rewards: people in different departments and on different level of the hierarchy care about different things. Micromanagement happens in part due to lack of clarity into what leaders really care about (and some due to trust issues). While you care about how to get your task done, your boss is probably thinking about how to make sure the customer is satisfied, or how failure on this and other 10 projects could impact their career negatively. They feel insecure that you won’t be upfront in case you see a risk or blocker that could result in lost customers.
The “solution”? Progress reports. Every month, every week, every day. This helps them at the cost of being seen as a stereotypical boss and the hidden cost of spending more time writing reports than delivering actual value to customers. A better solution? Invert the narrative, and show that you have interest in communicating your progress without them having to worry about it in the first place. It should help decrease micromanagement in most cases.
- Risk example: “Not being recognized because my boss doesn’t know what I’m working on”.
- Probability: “Low”.
- Impact: “I could miss future promotions”.
- Mitigation: “Write up status updates and blockers publicly twice a week for alignment”.
- Your boss gave you the priorities for the week, but there’s are ramifications that they don’t have visibility into, including your thought process and the principles you’re applying. Although being Low risk, the cost of writing a paragraph is nearly zero and could help with that promotion the following year when you are seen as communicative.
Incentives, Perception and Expectations
For me, the most exciting part is derisking at the intersection of technology and people. I find useful to see it through the lenses of incentives, perceptions and expectations whenever trying to figure out elements that could hinder technical projects.
Everybody’s incentives are different. It drives their perception of reality, liking and disliking different things in different contexts and orders. That will always weigh on how your projects are ultimately judged. Your shiny project could fall short of people’s grace without alignment. Your boss is thinking about how that project will be factored into their goals and OKRs, after all that’s defining their bonus.
Here’s the critical problem is: everybody imagines and hypothetizes what everybody else’s incentives are instead of straight up talking about it. We think they’re aligned with ours, but they’re not. We forget that everybody had a different childhood history, different values and different principles. It’s not that derisking helps directly with that, but it forces you to understand the landscape in order to apply it.
There’s only one sustainable way forward: talking to them and practicing active listening. Some care more about quality than money, constant improvement rather than the work itself, self-image over actual work. Others just want to go home at the end of the day. You nurture a team by identifying their individual motivations and offering to participate in providing what they are looking for, never establishing rules and processes in a vacuum, without talking to the people and hearing what they have to say.
Derisk Early and Often
The earliest you derisk, the higher the chance of success. Any late derisking generally results in surprises - “why have you only thought about that now?” Finding out a pipe problem once the construction has been delivered is too late, or finding out the text you’ve written is not interesting after you publish is too late. The later we derisk, the more energy we need to steer the ship. Yet, we rarely focus on deliberate derisking, despite important projects in life. We are either too focused on the present, the quarter, a task at hand, and we forget to step back and reflect.
Derisking works alike in personal and work environments, and it’s mildly baked into our everyday life to the point we automate it. You look before you cross the street despite the semaphores. You check your tires before traveling despite the sensors being green. You check the destination’s weather despite it being summer. You set up Alexa to close windows automatically.
Now make it deliberate.