High-altitude Projects

Altitude sickness has taught me two important insights about speed and trends, which can be applied to software development projects (and probably many other areas as well).

Photo: Krystyna Kupiszewska

Altitude sickness

After trekking above approximately 3,000 meters one has to take care not to climb too fast. The general rule is not to ascend more than 300 meters daily to acclimatise.

If your organism does not adapt to the height you reached, several symptoms appear (headache, fatigue, stomach illness, dizziness, and sleep disturbance).

This once happened to me in Nepal. The symptoms usually disappear within couple of hours. However, in some cases they may be getting worse, especially if you climbed significantly more than 300 meters within a day.

Altitude sicknes is quite a simple illness. If a patient is feeling worse and worse the end is always the same – death 😦 The only reliable treatment is to descend.

Speed limit

The first general thing I have learnt from altitude sicknes is existence of hard limit on velocity. Attempting to get above this limit is asking for trouble.

This applies to projects and speed of development as well. I like to keep that in mind when planning software development releases. Usually there is hardly anything we can to quickly achieve higher output (I am not talking about long-term improvements here) and the only reasonable option is cutting down on requirements.


Moreover, the way altitude sickness develops and comes away shows that it is all about the trends.

For instance, a percentage of code coverage in your project is relevant, but it is more important whether it is increasing or falling. The same applies to more general matters like quality, moods, financial situation and so on.

If we are on the wrong side of the trend, doing nothing and just waiting for better time to come will not help, exactly like in the case of sickness getting worse and worse.

All in all, I find those lessons on velocity limit and trends very useful – much often than in the high mountains.


I used information about altitude sickness from wikipedia and altitude.org. 

This post is a part of short series “What a ScrumMaster Can Learn From a Mountain Guide”. I previously wrote about preparing breakfast and getting up from breaks.


Introducing a Change – Stand Up and Make Room

Being a leader may sometimes feel like being an ambitious guy trying to sell the idea of getting up after the break and continuing hiking uphill to the group of exhausted backpackers.

How to make them stand up and go?

Stand up first

There is no other way. Just talking about any idea you want to sell to others will not work. You have to give an example, be the first one.

A mountain guide willing his group to stand up, stands up first, with a backpack on his shoulders, ready to go.

Photo courtesy of Krystyna Kupiszewska
Photo courtesy of Krystyna Kupiszewska. On the photo: Jakub Organ

Make room

OK, so we have got most of people standing and almost ready (adjusting their backpacks, talking to each other, drinking water and so on).

Now, a non-obvious trick to make the “process” of starting smooth is to make few steps forward, then call and wait for them to move.

This is important because:

  • if you just start walking you may end up walking alone and
  • otherwise, if you just stand and wait right next the whole group you are actually blocking the way you want them to go.

Introducing an organizational change

From my experience introducing a change in the team or an organization usually requires following similar scenario. If you want others to adopt a practice, after showing them an example, you need to make some room for them to start.

Understanding this is important if you want people to self-organize, or even just take over some responsibilities.

A very simple example might be introducing a habit of documenting important things on a wiki. Or keeping an eye on continuous integration system. To make this ultimately happen you need to stop doing all of it yourself  (not to walk alone) and stop reminding about this every time. Otherwise you block room for progress.


PS This post and a previous one are part of “What a ScrumMaster Can Learn From a Mountain Guide” – something that may become a short series.

What a ScrumMaster Can Learn From a Mountain Guide – Preparing Breakfast

Having experience as a mountain guide helped me understand how teams work in various situations. Some of the behaviours apply to the professional world as well.

Photo courtesy of Tomasz Rosiek

Imagine you wake up on a sunny morning in the tent piched on the mountain pass. The first task for the group, after crawling out of their sleeping bags: prepare something to eat.


You may count on some people being very helpful (or hungry ;)) and eager to spread jam on slices of bread, but most of your team is probably yawning or hesitating what to do.

What you need to do is:

  1. Start working – cutting the bread, vegetables, etc.
  2. Encourage others to join (inviting by name works best)
  3. Withdraw after short time, let someone else cut the next cucumber.

The most important (and the hardest) part is 3. It is easy to get involved into something, but there are probably more important things waiting for you (campfire, water supplies, plans for the day, oh, lots of stuff). If you do not start leaving work for others you will quickly end up doing more you can manage.


I have encountered it over and over again – some people do not pack knives. They are generally willing to help, but they do not have a crucial tool. I ended up bringing spare ones on each trip :evil:.

Your responsibility as a leader is to start, show an example and ensure people have everything they need to acomplish the job. After that do yourself (and your team – in the long term) a favor by taking a step back.