We'll see | Matt Zimmerman

We spent the entire fourth day processing the previous day’s simulation.  There were many valuable discussions and insights, of which these are only a few. Several members of the class had volunteered to act as observers, rather than participate in the simulation, and they presented their observations to the others.

When discussing their choice of a leader, the group was tense and talked little, until the candidates left the room.  It’s difficult to openly debate the merits of a near-stranger when they’re standing next to you.  I would be interested to hear from other participants about what this part of the process was like, since I was outside of the room.  With the other candidates, I discussed how the group had responded to us, mused about what the simulation might be like, and possible ways in which the group could be organized.  One of the other candidates had a clear idea of what the structure should be, while I felt strongly that it would be better to learn at least something about how the simulation would work before making that decision.  This illustrated for me a difference in leadership style which I notice in my work as well, and which I suspect is correlated with personality type (though I didn’t check that in this case).

For the second time during the week, I learned something about responding to mistakes (the first time was when I was standing nearest to a house of cards when it collapsed).  This time, when someone inadvertently broke one of the (previously unknown) rules of the simulation, causing the entire team to be penalized, I was the one to deliver the news.  The first question I was asked was: “Who was it?”  Perhaps it was merely a natural request for more information, but it immediately created the impression of blame.  It was irrelevant who had made the mistake; what we needed to do was respond to the problem which was created.  I had seen this pattern many times in my work, but the artificial parameters of the simulation illustrated it beautifully.

There were many opportunities to study systemic problems in the simulation, as information and work product queued up in different ways, and feedback loops evolved to enable the group to respond. .  It was surprisingly challenging to identify the root causes of blockage, despite the simplifications of the simulation, and this is so much more difficult in real-world organizations.  It’s nearly impossible to do it well when one is involved in the work of the moment, as it requires some distance and objectivity.

In one part of the simulation, a small group had organized to work on a particular task.  Without the benefit of prior knowledge about the nature and volume of the work, the space chosen for this was very small, and not at all appropriate either for the materials or the people involved.  This situation persisted for far too long, as no one recognized the situation until much later.  This highlighted for me the importance of regular checkpoints (such as retrospectives), to get perspective on how a team is working and make appropriate changes based on experience.

I expect that every non-trivial organization struggles with communication, and I’m always looking for new ways to improve the flow of information.  I had a striking insight in this area thanks to one of Jerry’s aphorisms: Trust is a substitute for communication.  When you have a strong, trust-based relationship with someone, you don’t require as much communication with them, for two reasons: your communication becomes more efficient (more information in less time), and you don’t require as much information of each other (because you can trust that they are doing the right thing on their own).  Because of this, it’s possible to improve “communication” in an organization by working at the level of emotional relationships rather than information flow.  Based on this, I have reinterpreted some reports of “communication was poor” or “more communication is needed” to mean “the relationship needs work to build trust”.

We also discussed the use of a “zero-level solution” in problem solving.  This is Jerry’s term for establishing a simple, baseline solution to a problem before exploring more complex alternatives.  For example, if the problem is that a program runs more slowly than it should, buying a faster computer might be a zero-level solution.  With that fallback position in mind, a team can then generate and explore other ideas which might be more effective.  I’ve used this technique before, but studying it at PSL gave me a chance to reflect on why it works.  First, it supports incremental development of a solution, with all of the attendant benefits familiar to Agile practitioners.  Second, it provides for fast evaluation of new ideas: if it’s no better than the baseline, throw it out immediately.  Third, and most powerful, is the motivational effect: knowing that there is at least one solution in hand gives the group confidence and safety to explore alternatives.