One of the most effective things I’ve done with my teams so far is urging them to simply try things out. Late last year, we heard many variations on trendy phrases like “celebrate your failures”, and I sent a Happy New Year message to my teams reflecting on the great sanity behind the fashion. I suggested that celebrating failures is not about reveling in the failure itself, but about encouraging learning and daring. The former comes from reflecting on the vast amount of data that a failure generates, but we already knew about that from the inspect-and-adapt loops built in to Agile frameworks. What I find really exciting about the notion of celebrating failure comes one step earlier: if it’s okay to fail, then that means it’s okay to try things. Even crazy things.
There is too much pressure in a business environment to be sure that you’re right. We spend inordinate amounts of time trying to predict the future of proposed initiatives based on supposedly rigorous but frequently inaccurate cost-benefit analyses. Weighing the pros and cons of a proposal is perfectly rational, but taken too far, it creates an environment hostile to new ideas. This is especially true at a fine-grained level, where the ROI on time spent debating the future success of an idea is minimal.
So, I sent that email. No one responded. Email is a terrible way to spread ideas. But later, usually in retros, I called attention to the idea. I used the metaphor of a scientific experiment. “You see a problem,” I told the team, “and you have a hypothesis that taking a certain action will at least partially solve that problem. Taking that action is testing your hypothesis, and to test it, you need some level of control in your environment and some sort of measuring stick. How will you evaluate whether the hypothesis was correct? How do you avoid muddying results by, for example, failing to really embrace this approach across the team?”
This metaphor landed well with the teams. They have shown hints of defining actions and measurements more crisply. They are more likely to give proposed actions their all, rather than half-trying and thereby undermining the experiments. They are trying things they are not completely sure will work. It also undid a strange, surprising knot in which the teams repeatedly tied themselves. In one example, the team wanted to implement a procedure to solve a near-term problem, but worried that it would become overhead in the long-term. They really got stuck there. It truly wasn’t occurring to them that the very tool they were using to put the procedure in place (the retro) could be used to remove the procedure once its value was gone. This idea of intentionally temporary changes was a big insight for me.
I’ve since discussed this with fellow coaches, and we’ve nearly all had the same experience: get your teams to stop worrying and start trying stuff, and magic happens.