Lessons from Climbing: Handling Risks

As an experienced IT Architect who has worked on complex and risky projects to develop large Business Solutions, I understand the importance of risk management in ensuring the success of such endeavors. However, I believe that the term "risk management" can come across as too clinical and detached, failing to convey the gravity and importance of the concept.

Drawing from my personal experience with climbing and mountaineering, I have come to appreciate the significance of risk management in a more personal and visceral way. In high-stakes situations where lives are on the line, it is essential to have a framework for identifying, assessing, and mitigating risks. This framework must be ingrained in the minds of all team members and practiced regularly, much like the routines and protocols that climbers and mountaineers use to navigate dangerous terrain and handle risks in dangerous situations.

In both IT and climbing, risk management is not just an afterthought or a box to be ticked. It is an integral part of the process, woven into the fabric of every decision and action. By examining the parallels between these two seemingly disparate fields, we can gain a deeper understanding of the importance of risk management and how it can be applied effectively in IT projects.

Objective vs Subjective Hazards

In mountaineering and climbing, risks can be broadly classified into two categories:

• Subjective risks are hazards that are associated with the climber's own abilities, experience, and decision-making. These risks are influenced by factors such as the climber's skill level, physical condition, mental state, and personal choices. Subjective risks can include things like falls due to poor technique, poor judgment, or inadequate training, as well as the risk of overexertion or dehydration. Subjective risks can be mitigated through proper training, experience, and decision-making, as well as by taking steps to manage personal factors such as fatigue, stress, and anxiety.
• Objective risks, on the other hand, are hazards that are inherent in the environment and are independent of the climber's abilities, experience, or decisions. These risks are typically associated with the natural environment, such as rockfall, avalanches, weather conditions, and terrain. Objective risks can be identified and assessed through careful observation, monitoring, and analysis of environmental conditions. Climbers can take steps to mitigate objective risks by choosing routes and itineraries that minimize exposure to these hazards, using appropriate safety equipment, and staying informed about weather and other environmental conditions.

In summary, objective risks are hazards that are inherent in the environment and are independent of the climber's abilities or decisions, while subjective risks are hazards that are associated with the climber's abilities, experience, and decision-making. Both types of risks can be managed and mitigated in different ways through proper preparation, experience, and decision-making.

Let's look at both types of risks and compare them in both Climbing and IT Project situations.

Handling Subjective risks: "Projecting" with Unit Tests

Subjective risks are mainly handled through learning and knowledge. Here a Growth Mindset is key to enable effective learning.

In Climbing, the best way to raise skills is by doing, failing, and trying again until a successful redpoint ascent (Climbing the entire route in one go without intermediate rests). This approach is called "Projecting", and implies choosing a route just outside of your comfort zone and trying it with an open mindset and willingness to fail and fall. To do that safely climbing routes are safely bolted to avoid injuries when falling.      

Projecting a redpoint ascent of a sport route with secure bolts and software development using Unit Testing, TDD, and BDD can be compared in several ways:

1. Preparation: In both cases, preparation is key. Before attempting a redpoint ascent, a climber must first inspect the route, identify the crux moves, and practice them until they feel confident. Similarly, before writing code, a developer must understand the requirements (maybe even with TDD and BDD approaches), identify the critical components, and design a plan.
2. Safety measures: In climbing, secure bolts are essential to ensure the safety of the climber. In software development, Unit Testing, TDD, and BDD serve as safety measures, ensuring that the code functions correctly and meets the requirements.
3. Iterative process: Both climbing and software development involve an iterative process. A climber may attempt a route multiple times, adjusting their technique and strategy until they successfully complete the ascent. Similarly, a developer may write and test code multiple times, refining it until it meets the requirements and functions as intended.
4. Feedback: Both climbing and software development provide immediate feedback. A climber receives feedback from their body and the route, while a developer receives feedback from their tests and code reviews. This feedback helps refine techniques and strategies in both cases and can be very specific (failing a move at a specific bolt vs a single specific unit test failing) to learn effectively.

On top of these, there is a documentation value, with a bolted route remaining available to further climbers to try their skills on and with unit tests providing documentation to the maintenance team joining later into the project, reducing risks and multiplying skills over time.

Handling Objective risks: Navigating dangerous terrains with Agility

Mountaineering objective risks, are inherent in the sport and cannot be eliminated by subject skills, such as rockfall, avalanches, and weather conditions.

With Objective risks, a paradox emerges: Mountain guides have high rates of avalanche accidents and deaths and this highlights a dangerous cognitive bias in experts. Experts are at risk in two ways. First, they may make assumptions without verifying them due to their extensive knowledge. Second, their familiarity with the risk scenario can desensitize them to the potential dangers, leading to a loss of risk sensitivity.

So, to counteract this bias, mountaineers explicitly try to adopt an iterative OODA loop for evaluating Objective risk scenarios:

1. Observe: The first step is to observe the situation and gather information. In mountaineering, this means monitoring weather conditions, snow stability, rock stability, and other environmental factors that could impact the climb.

2. Orient: After observing the situation, the next step is to orient yourself to the environment. This involves analyzing the information you've gathered and identifying any patterns or trends that could impact your climb. In mountaineering, this might involve studying the route, identifying potential hazards, and assessing the risk level.

3. Decide: Once you've oriented yourself, the next step is to make a decision. In mountaineering, this might involve choosing a route, deciding when to start the climb, or determining how to respond to changing conditions.

4. Act: After deciding on a course of action, the next step is to act. In mountaineering, this means executing your plan and accepting the risks associated with the climb.

The Cynefin framework is a decision-making model based on these concepts that help individuals and organizations navigate complex, uncertain situations.  This model is particularly useful for evaluating the applicability of Agile methods in Complex and Chaotic scenarios to contain risk through a continuous feedback loop.

So, Agile methods are useful for handling IT Project Objective risks outside of the control of the project team (Unstable market conditions, Uncertain Requirements, Non-committed Stakeholders, First-of-a-Kind situations), by containing and accepting the risks in minimizable chunks (e.g. MVP, some iterations), and continuously adapting to changing situations. An honest and continuous evaluation of the current situation is required here to avoid the Exper Cognitive bias and other ones (e.g. Sunk cost fallacy).  

"Summit" it up

A Climb is never finished until you are back home or base camp, with statistics showing that about 80%  of incidents are during the descent.

In the same way, on complex Software projects and large Business Platforms, we are not finished when completing design, implementation or even reaching production. Long-term evolution and maintainability of the system is the long view that is absolutely essential for a successful IT career and navigating risks.

In conclusion, risk management is an essential aspect of both IT and climbing, and the parallels between these two fields can provide valuable insights into how to apply it effectively. By embracing a culture of risk awareness and mitigation, teams can ensure the success of their projects and the safety of their members.