Everything we do is subject to error
If you have been following what I have been writing recently you will be aware that I have been reading Mary Catherine Bateson’s book, Peripheral Visions. I’ve also been thinking a lot about the practical ways we can proceed when we can’t predict with any certainty what lies ahead or when the landscape around us that sets the context for our work, is uncertain and changing rapidly. This extended quote from the book pretty well sums it up for me.
We are engaged today in a rapidly improvised mortal dance with our planet, in which we have to work out ways of protecting the natural environment without full information – without, for instance, certainty even of the degree or significance of global warming. All behaviour has potential impact. It is not possible to sit on the sidelines, saying, I can’t dance. Our dealings with the planet have always included actions taken before the results could be predicted, and this is unlikely to change, in spite of the achievements of science. Rather than assume everything could be mapped out beforehand, we might be do better to develop rapid and fluid styles of midcourse correction. Little that we do is without risk, but not all risk is culpable. Assuming that all risks should be controlled in advance may lead us into danger rather than the reverse. Everything we do is subject to error.
What I’m noticing quite a lot though is a sort of paralysis as people wait for “leaders” to tell them what to do. As well, many managers, and policy makers still seem to be trying to map things out in detail beforehand and eliminate the risks. When they can’t do this with confidence they often freeze – feeling as if they cannot act, because the risk of moving forward is too great.
The development of a practices that allow for, and indeed facilitate “rapid and fluid midcourse correction” seem to me to be not just a good idea but absolutely essential if we are to tackle some of our bigger challenges.
But what might this kind of practice look like?
Here is one idea. Last night I watched NCIS with my kids. (My apologies to those who aren’t regular viewers!) As part of the quirky character development in the show Tony (not usually the “boss”) was put in charge of the case. When they got stuck or things got tough he called a “campfire”. Everyone wheeled their chairs into the middle of the office and they figured out what to do next.
This reminded me of something I read recently about agile processes in software development call the “scrum”. It goes something like this. A team (the originators of this process recommend 7 plus or minus 2 people as particularly workable) is formed to tackle a particular development task or project. Each month the team meets in a “scrum” and decides what work it can achieve in the next “sprint” (30 calendar days). A “daily scrum” takes place in which the team members do what the developers call “synchronisation and status exchange”. Otherwise the team is left to self-organise. Here is how they describe what usually happens
… as the team realises it has the full responsibility to do whatever it deems necessary, a sense of liberation and empowerment (that usually trite phrase) occurs. The team start talking, drawing designs on whiteboards, figuring out what work needs to be done. People start defining what work they’ll do, and what help they need to do it. Some people ask to do work that they’ve always wanted to learn, signing on for additional work to offset their learning curve. The team collectively simmers, brainstorms and works to meet its commtments.
Here’s the bit that struck me as intensely practical. The daily scrums are designed to last no longer than fifteen minutes. In that time everyone answers three questions:
- 1. What have you done since the last daily scrum?
- 2. What will you do between now and the next daily scrum?
- 3. What’s getting in the way of you doing your work?
As a way of reflecting on this you might like to pay attention, over the next month or so, to how long goes by before your team considers these questions. You could also test what happens if you inject those questions, or ones like them into your conversations at more frequent intervals.