Trust is an important enabler when developing software as well as in other endeavours in life. Some of the lessons are very obvious in climbing — so what can we learn?
Last week, I had the amazing opportunity to run a workshop with a software team on the subject of Trust at a climbing gym (Blocs & Walls in Copenhagen).
"Amazing" because Trust is one of my favourite topics; because I used to be a climber and frankly miss it a lot; and because there are so many things to learn about Trust (and life) when climbing. Feedback is immediate, and consequences are obvious.
The speed of trust
My main point about Trust is that everything is faster and simpler when you have trust (see e.g. Tillidskonto) — I'm sure you have seen this in you own life too.[^See the reference section]
| Climbing | Software development |
|---|---|
| Not feeling safe makes us slower, or unable to move at all. | If we are in a work environment where failing is "not an option", we freeze or move with so much care that progress is almost not possible. |
| When bouldering (near the ground, no rope needed) there is no danger, neither real nor perceived, so we dare to try things and learn. | Feeling safe allows us to try things and learn. |
| As beginners, we were instructed to have both a belayer and a back-up belayer for each climber, plus wait for an instructor to double-check every critical step we made. Very sensible (thanks!), but it was obvious that we would save a lot of time if we could be trusted to belay safely on our own. | If we can trust our test process to catch errors before they reach production, we can move faster. If it is fast, reliable and automatic, we can move even faster. |
| At least once, the extra rope-work involved in having a back-up for the belayer introduced rope tangling. The extra layer of security became an impediment to the climber who had to wait, midst climb, while the rope was untangled. | Extra layers of safety are not free, and sometimes the extra layer of safety is what slows us down or causes problems. |
Trusting the system
Ok, so we want to be able to trust our systems, but how do we learn to trust?
| Climbing | Software development |
|---|---|
| The system must be trustworthy: the rope and harness etc. strong enough, the person holding the other end reliable enough, and their job clear and easy enough that it cannot fail. | We will (and should!) only trust something that is trustworthy. An automatic test suite is a great enabler if it is reliable, but if we know that there are categories of errors it won't catch, it is not (on its own) worthy of our trust. |
| We must learn to trust the system, not only rationally, but really trust it (mind and body and instincts and sixth sense). It helps seeing the system in action: fall, and get caught; or see your climber fall, and feel the belay working. | Every time our safety mechanisms (automatic test, manuel test, code review,...) catches a problem in the making, we feel safer, and we learn to trust the system more. |
| We can get overly confident when things go smoothly for a while. In climbing, I think you can see why you would want to avoid that... | Getting overly confident and behaving like we do have an adequate test harness even when we don't is also dangerous in software development. Do a reality check from time to time: is this actually safe? How do we know? |
| Trust is built from the small to the large. Is the rope strong enough? The belay device reliable? The anchor at the top? The belayer? All the parts must be absolutely reliable for the system as whole to be reliable. |
Start with you. Are you trustworthy? Could you become even more trustworthy? Practice by making a point about keeping promises that you make to yourself: If you said you would go to the gym, go to the gym. If you said you would have just one beer/cookie/bag of crisps, have just one. Then the team and the way you cooperate. Can important issues fall between chairs? Then the product. Then the organisation as a whole. |
Earning their trust
We also need our co-workers to trust us — how do we gain their trust?
| Climbing | Software development |
|---|---|
| We need to be trustworthy. Would you trust yourself? | Keep promises, meet commitments. (Again: practice by keeping your promises to yourself.) |
| We need to prove our trustworthiness. How do your climbing partner know that you can be trusted? By seeing us in action, by taking a chance on us — and by being "saved" by us. |
Prove yourself in actions; make meaningful promises and keep them. If we never promise anything, there are no promises to break — but no promises to keep either. I am not advocating promising a lot or as much as possible, but making meaningful, strong promises (that you can keep), like "Yes, we can go live with the new customer module before the invester demo." |
| Seeing the system in action "for the small stuff" builds trust, but seeing the system work when it really counts — on the large falls — is even more convincing. | Be trustworthy where it counts, where there is something on the line and where it matters to the ones whom you want to trust you. |
| Be open about what you can and cannot promise. I strongly prefer having a climbing partner who would admit if they did not feel ready to "have my back" to one that pretends to be in control when they are not. | Do not make any promises that you cannot keep. Yes, it may be tempting to go for "stretch goals" and "overcommit" because it makes you look good today, but if you promise and do not deliver, you won't look good for long. |
| If you admit that you are not yet ready to take on the responsibility of belaying, you invite a conversation about what is missing — what part is unclear, what can we do to get to the point where you would be comfortable taking on that responsibility? | When you admit that you are not ready to, e.g., commit to a proposed deadline, you invite a conversation about what is missing: is the scope unclear, are there unknown dependencies, is it just too much work? This conversation allows us, as a team, to clarify and get to a safer, better deadline/scope. And you've just proven yourself more trustworthy. |
The seed of trust
We want them to trust us, but we also need learn to trust people that we have not yet learned to trust.
| Climbing | Software development |
|---|---|
| Until we have seen the system in action, we may not feel that we can fully trust it — but we decide to try anyway. We start with a seed of trust, realise that it works, and build on that. | For the people whom you want to be able trust: show them some trust so that they can prove themselves. Usually they will. |
| When at first we decide to try to climb before we really trust the system, it may be based on our trust in the instructor. | Trust can be helped on the way by a trusted third party, at least for that initial seed of trust. After that, it is up to them and you: prove yourselves to each other. |
Losing their trust
Losing trust is all too easy.
| Climbing | Software development |
|---|---|
| Climbing is fun, and after a while we may get comfortable enough to forget our fear and concentrate on the climb and the moves. If we get overly confident, feedback is usually swift — and it just takes one slightly uncomfortable fall to make the height very present again. | Trust is gained slowly, but lost swiftly. |
| Falling can set you back quite a bit. The trip down is much faster than climbing back up again. | Winning back lost trust takes much longer than losing it... |
Regaining trust
Can you regain trust that is lost?
| Climbing | Software development |
|---|---|
| After a surprising or maybe even slightly painful (but at this workshop only to our pride) fall, we are suspicious. Maybe this was not so safe anyway? But if we reconsider: we fell, but the system worked — the rope was there. Thinking about the system again, we may find that we understand it even better, and trust it even more. | If we have given someone a reason to lose trust in us, we should admit it, "own it", and try to make up for it. If we are sincere, this will shine through. Has anybody failed you, but then made up for it so you trust them even more now? |
Without a safety net
| Climbing | Software development |
|---|---|
|
I got a great question: what did people do before mechanical belay devices and modern ropes? I read an old climbing book about climbing in the 1800s, with hemp ropes. "Rule #1: the lead climber does not fall." Because that... would be really bad. |
If our automatic test harness is only reliable to a point, we have to supplement it with manual tests and other safety meassures. How much faster could we go with better automatic tests? How much harder problems could we solve? How much higher could we climb? |
Practical info
We met up at Blocs & Walls, and talked about today's subject: Trust, and what it has to do with climbing. We then had a two hour session with two instructors from Blocs & Walls, including warm up (with lots of laughs), bouldering, and top rope climbing. Safe, instructive and good fun — highly recommended!
Afterwards, we had our workshop in a separate room. Great facilities for a workshop like this.
References
I'd claim that you can learn about trust just from reflecting on the title of the book The Speed of Trust by Stephen M.R. Covey. Read it too, and you will learn even more ;-)
