The hardest part is getting started. But once you have decided on a path, you should follow it consistently – at least as long as the chosen path is feasible and makes sense. This applies to both mountain climbing and software development. At some point when climbing, you face the mountain and know the goal – namely the summit – but you don’t yet know precisely how you will get there. Many uncertainties play a role: for example, the weather conditions, the difficulty of the mountain face or maybe you don’t know your companions well and don’t know how they will react in precarious situations. And yet, if you want to reach the summit, you have no choice but to start out on the route.
The situation is often similar in software development. You start a project with a defined end goal, but don’t yet know where particular difficulties lie in the project, precisely how you will achieve the end product and how well the team and customer will work together. But here too, you need to start programming if the product is to reach the market at some point.
Commitment drives success
Regardless of the conditions, once you are on the mountain or immersed in the project, you need the commitment of everyone involved or otherwise you will flounder. It takes commitment to follow the chosen path steadfastly and without distraction. Ideally you get into a flow that allows you to work or climb without hesitating or losing focus. Being committed means being fully invested and involved in the project. By committing yourself explicitly to the cause, you convey to yourself and others involved that you are doing everything you can to achieve the agreed goal.
In terms of a software project, this means: You commit yourself to the product – even if this is difficult at times. Sometimes it takes a little grit and staying power to keep going. But the more progress you make, the greater the negative consequences tend to be if you give up. If you stop half way, you may have wasted a lot of money. You need to be aware that there will be difficult phases that can be stressful – both on the mountain face and in the software project. You will struggle, it will be tough, problems will occur. But when you are really committed to the project, you will also be prepared to accept that.
At the same time, this also means taking responsibility for your actions. If you choose a new and more challenging path than originally planned on your climbing route, it might be exciting but it also means that the rest of the rope team has to take this path too – even if the level of difficulty has increased significantly. If engineers make a technical decision in the project, this also affects those entrusted with the ongoing development of the product down the line.
Risk assessment and risk appetite
It is not only the developers who need to be committed, but also the customer. If the customer is fully behind the project and is willing to play their part through investment, advice and action, the risk of the project failing diminishes. If a customer suddenly finds it difficult to express their ideas about the project, then perhaps they are lacking commitment. But there are also other risks that can lead to failure. On the one hand, there are the calculable risks or risks that can be mitigated and, on the other hand, the residual risks that cannot be mitigated. In the mountains, the weather conditions can change suddenly, a stone can become loose or material can malfunction. Similarly, the economy can collapse, new competitors emerge or a pandemic turns everything upside down. You are more or less at the mercy of such – often highly improbable – risks. They are almost impossible to mitigate.
Other risks, on the other hand, can be easily mitigated. These include the three main risk factors: ignorance, lack of seriousness and distraction. Again, these apply to both mountain climbing and software development.
Ignorance can be reduced through learning, in other words through experience and regular training. Lack of seriousness can be combated by (joint) reflection in order to achieve a certain system awareness and grasp the context of the situation. This allows you to assess risks more easily, respond accordingly and thus mitigate them. Commitment and focus on the problem help to counter distraction.
Risk and commitment influence each other mutually
The combination of focus and commitment creates accountability and thus reduces the risks. If we are working on a product that is only an insignificant sideline project for the customer to which they attach no importance, there is a greater risk that we will not achieve the planned goal. There is a great danger of getting caught up in defining goals or that the people in charge will be difficult to reach.
The same is true of a climber who is not fully focused, since they risk endangering the entire rope team. The perceived risk is a distraction and concentration wanes. Focus and commitment become interacting forces. “The distraction caused by the risky situation makes it difficult for the people involved to make a binding commitment. Conversely, the risks are regarded as higher if there is a lack of commitment. A vicious circle is created that must be overcome.
There are various approaches that lead to success. On the one hand, both developers and climbers should reflect on their risk perception and learn to maintain focus despite fear of pitfalls. Furthermore, experience with risky situations helps you to treat the situation with appropriate seriousness. But it is important not to overreact. The more often you expose yourself to risk situations in a controlled way, the more effectively you can deal with the risk. If we as individuals and as groups are aware of these effects, then it is more likely that we will achieve our goal together. Whether this is a mountain summit or a software product designed to excite users.
The author
Dominik Berner
Dominik Berner is a Senior Software Engineer at bbv. Thanks to his know-how in the MedTech field, he knows the growth limits of start-ups and small companies, but also the conditions in large companies. As an agilist, Berner regards software development as a team sport that requires a strong corporate culture.