Raising Problems Without Raising Blood Pressure

As you move from owning individual problems to owning projects, you'll often find yourself in a position where you're surfacing risks to your manager or other senior folks. Doing this well can be an art; on one hand you want to stay stay aligned with authority and make sure that leadership is aware of the problems. At the same time, constantly surfacing risks without helping mitigate them can erode confidence in your ability to deliver. Striking this balance can be hard, but can be repeatedly done with the right communication strategy.

Where Do Anxiety and Confidence Come From?

When considering how to do this well, it’s worthwhile to think about building confidence in your ability to deliver. I like to think about this with the two equations:

perceived_risk = perceived_impact * perceived_likelihood_of_occurrence

perceived_confidence = sum(perceived_ability_to_impact / perceived_risk)

These aren't scientific, but looking at them gives an idea of the levers we can use to increase peoples' confidence in our ability to solve a problem: We can

1. Lower its perceived magnitude
2. Lower its perceived likelihood of materialization
3. Increase others' perceived ability to impact it

We'll assume that #1 is outside of our control. There may be reasons to inflate/deflate the perceived magnitude of a problem, but those are beyond the scope of this post. Fortunately, we can manage #2 and #3 by how we talk about risks.

How to influence confidence perception

The simplest way to affect these two factors is to follow a simple rule: every description of a problem contains a description of its probability and either actions being taken or a request for support. This is really easy to do when you've got the problem under control. I like to follow the below template to make sure I get it right.

There's a risk that ${PROBLEM} is going to bite us on ${TIME-HORIZON} at ${PROBABILITY}, we're mitigating this by doing ${ACTION-1} and ${ACTION-2}. How does that sound to you?

This template is nice because it describes the problem without making us seem helpless. It gives the other person a clear anchor so that they’re aware how much they should keep an eye on it. This phrasing also shows that we're aware of the risks, are actively taking steps to prevent them from materializing, and that there’s an obvious path to influence that risk through guiding us.

Sometimes you don't know about the solution up front, and you need to escalate for support. You can still do this in a confidence-building way by saying:

Hey {X} I have ${PROBLEM} and I'm not sure how to solve it. Can you help me brainstorm solutions?

This clearly shows that you've got the monkey on this problem, but you need help figuring out how to deal with it. By including a clear ask for help, you've shown how the other person can impact the problem, which can help control their concerns.

An Example

All of that is great in theory, but how does it work in practice? To consider that let's take a simple example: you've been asked to prepare an estimate that you are targeting to deliver in 4 months. After running the numbers, you find that your estimate range runs 3 - 6 months. This means there's a risk the project will slip its 4 month target. Your first intuition may be to present this as:

We believe the project will take 3-6 months, so we may miss our 4 month target

This is an okay place to start. It clearly raises the risk of missing the delivery date, but someone who reads this will have no idea how much they should worry about this. That doesn’t inspire a lot of confidence in our ability to deliver. We can make this better by adding probabilities.

We believe that the project will take 3-6 months. We're 30% confident we can deliver it in 4 months

This is getting better. We’ve now given people a percentage that this risk will materialize. If 30% probability of success is acceptable, people can move on with their day. If it’s unacceptable, they can dig in and start to help. This presentation still puts a lot of onus on the listener to deal with the situation though. We can take clearer ownership of the problem by saying:

We believe that the project will take 3 - 6 months. We're currently 30% confident that we can deliver it in 4 months. Can we brainstorm areas ways we can increase this confidence?

Ending with a question makes a huge difference! We've turned a problem without an owner into one with a clearly defined owner (us) and a clear path for others to influence it via a brainstorming session. This may be the best we can do if we don't control the project plan. If we control the project planning, we can show even stronger ownership.

We believe that the project will take 3 - 6 months. We're currently 30% confident that we can deliver in 4 months. Much of the risk is in implementing the new UI components, so we'll mitigate that with a spike next week. In the meantime, can we brainstorm areas where we can possibly cut scope or otherwise increase confidence?

This approach gives us everything that the previous answer does, but it also shows that we're aware of the risks and are decreasing their likelihood of materialization. This builds confidence in our ability to manage the project to a satisfactory conclusion.

This example makes it seem easy, but the truth is managing other people’s confidence levels is hard. In the swirling world of project leadership you've got many things to juggle, and sometimes perfect communication gets dropped in the process. Fortunately, you can consistently create confidence and avoid alarm by making sure that you describe risks with a probability and either an action or a request for support.

Discussion, links, and tweets

Hey! Thanks for reading! If you like what you read and want more, you can follow me on Twitter.

Tweet Follow @maltzj