In a world where timelines and task lists rule project management, we often forget a crucial aspect of planning—risk assessment.

Imagine you’re a Team leader in a small tech company. Every Tuesday, you lead the Sprint Planning meeting, dispatching the endless list of items to your team members, asking engineers to give an estimation to each one. You ask yourself questions about the time that a task could take, about the cost of the future implementation. But, have you ever stopped to think about the risks of each task? How it could impact the team, your product plans, or even the whole company?

I’m bringing this up because I realized that I was often overlooking risk. We’re quick to ask how long a task will take, but we don’t often consider if it’s actually achievable. From experience, an engineer who finds himself faced with a sprint item that is unclear or on an unknown subject or technology will come up with a vague estimate and might not factor in the risk of failure. And, as a Team Leader, you might not instinctively think about the potential issues an unfinished task could cause. We tend to consider the task will be eventually completed, regardless of the time it takes.
But what happens when the task is never completed? When nothing gets shipped? In some situations, it is because we have decided to use a new technology, taking great care to think about all the implications that this could pose, and the time that it will take compared to an implementation with a proven technology, without adequately contemplating the risks associated. What then is the risk of not delivering any results on time? Are you aware of it? And are your stakeholders? I believe many of us grapple with these questions, but we rarely tackle them head-on.

To me, this is partly because we tend to confuse the necessary risk that a founder or a C-level takes when determining the product strategy of a quarter, and the day-to-day operational risk in execution.
I understand that we value the first one, but it’s not something we should be courting in daily operations. Even within an uncertain and challenging startup environment, a team lead should not view a significant risk in its sprint as normal. He should instead seek a low risk and focus on how to execute as safely as possible on a bold and risky roadmap. At first, this can be challenging.
We all have a competitive mindset, we all want to believe that we are capable of surpassing ourselves and carrying out the most complex tasks in a short time. And this is great. However, as a team leader, your role is to challenge this mindset and to rather acknowledge the potential for failure. While we can indeed surpass our expectations, we cannot do so every week or with every task. You can’t build your entire strategy on that. You can leave room for uncertainty, but you need to know how to manage this risk.

I had a revelation when learning about Nassim Taleb’s “barbell” investment strategy. It focuses on extreme ends of the risk spectrum, bypassing the medium-risk investments. In practical terms, this involves putting a large portion of one’s investment portfolio, approximately 80-90%, in extremely safe, low-risk assets such as Treasury bonds or cash.
The remaining 10-20% of the portfolio is then invested in high-risk, high-reward assets. These can be speculative investments, emerging technologies, or other volatile and potentially highly profitable assets.
The core idea of this approach is to ensure a certain level of safety with the majority of one’s wealth while taking calculated high risks with a small portion. If the high-risk investments do not perform well, the overall impact on the portfolio is limited, and the loss is cushioned by the safe, low-risk assets. Conversely, if the high-risk investments perform well, they could potentially provide significant returns.

To me, this can be applied to project management. When planning, we tend to fill it the sprint with “moderately risky items”. The problem is that these items provide moderate returns when successfully completed but expose the team to a significant risk of not delivering anything by the sprint’s end. It’s a gamble with potential mediocre rewards. A more balanced approach would be to populate a sprint with about 80% of low-uncertainty items, and 20% of high-reward/high-uncertainty items. This way, we secure a consistent flow of work and maintain a stable pace of progress (thanks to the low-uncertainty items) while creating a space for experimentation and potentially unlocking fantastic outcomes (if the high-uncertainty items are successful).

Beyond what it can bring to the project, I think this can also lead to deeper conversations during planning. Rather than just estimating the duration of a task, openly discussing the associated risks encourages everyone to prepare and review their tasks more thoroughly, instead of just diving in blindly. It helps young engineers to grow faster, by prompting them to consider the broader implications on the product and the organization, instead of solely focusing on their individual task. It also enhances the dialogue between the Product Manager and the Team Lead: Product Managers would certainly appreciate more insights into the risk associated with a product item before suggesting it.

The one cautionary note I would add is the need to avoid the trap of choosing only low-uncertainty items for the sake of safety. The 80/20 ratio shouldn’t be seen as an inflexible rule, but rather as a guideline. It’s a reminder of the importance of frank and explicit conversations about risk during the planning process.