The Tightrope Walker: A Metaphor

“How did it get this bad?! How could anyone on my team have thought this was okay?” -Anonymized Client

Over the years, we’ve seen a bunch of projects in different states of disrepair. We approach each one of these projects with the assumption that every person who touched it did their best at the time with their given constraints. This is the embodiment of our first core value “Act With Empathy.”

Assuming the best intentions is something that comes naturally for us but it’s not always easy for our clients to do the same. After working with us for a little bit, many of them are only just beginning to understand the rough state that their project is in. This often comes as a shock, especially to the less technical people who are involved with the project.

On a call a few months ago, a client was in despair, trying to understand how any reasonable team could have made the series of decisions that got their project to its current state. For that project, there was virtually no documentation: nothing to describe how to set up a development environment; not a single passing test; and commit history comprised of epically large sets of changes with very terse change descriptions. The client was extremely frustrated and expressed dismay while wondering aloud how the project had gotten so bad.

We often use metaphors to help people, especially those who don’t code very often, understand the context of a given situation. Metaphors can be a valuable tool for communicating abstract concepts. In this situation, and in others since, the metaphor of a tightrope walker has helped explain the complex nature of risk. Here’s how it goes:

Imagine someone learning to walk a tightrope for the first time. The rope is kept low to the ground. This significantly reduces the risk of falling. The person on the rope simply puts a foot on the ground to regain their balance and keeps moving along the rope. They keep going back and forth and, eventually, they don’t need to put their foot down anymore. So, they feel more comfortable with the idea of raising the rope higher and higher. They know this rope really well by now. They can travel back and forth very quickly, and the few times that they do start to fall, they are able to catch themselves very quickly. Then one day someone who hasn’t watched this progression shows up and exclaims, “Where is your safety net!? You’re going to get yourself killed!”

I think this is similar to what happens to new teams that build a project from scratch. Early on in the project, the most pressing thing on the team’s collective mind is to ship the next release, which, in the context of the metaphor, can be thought of as getting to the other side of the tightrope. It’s okay if the team stumbles along the way. The project is very young and the risks are very low. They are able to recover quickly, learn from each mistake and keep going. They keep pushing out releases all the while amassing a larger system with more users, more features, more revenue, and more risk.

The team has been working without any safety nets. No project documentation to describe how to set up a development environment. No description of how to deploy the application to production. No automated test suite. No formal manual test plan.

Over time, someone on the team may have asked, “Why is there no safety net?” Perhaps it was the newest team member wondering why it was so hard to get started on the project. Or maybe it was one of the more junior team members who discovered a blog post about Test Driven Development. Or, maybe it was a tech lead who keeps hearing about DevOps from friends on other projects.

Regardless of who asks the question, the answer is always the same; “We don’t have time to stop and build a safety net. We have to hurry up and get to the other side.” The team is feeling so much pressure to get their next release out the door, they feel they don’t have the time to slow down and build some safety into their process.

I find that less technical team members rarely understand why the team wants to slow down for a little bit. They don’t effectively understand the risks that the team is trying to address. So, they pressure the team to just go back to doing things the way they were doing them. My hope is that this metaphor can help those who are trying to avert disaster while also helping explain how reasonable team members could work for so long without a net to catch their inevitable fall.

Do you have any similar metaphors that help you explain this situation? Have you heard anyone else use a good one? Please share them in the comments and let’s keep the conversation going.