A systems language for business
On the first morning of the week-long class, I overheard a discussion between two or three of the participants during a break. They were talking about some issue they faced at work; one person said (let me paraphrase), "ABC," and the other said, "XYZ." The first repeated "ABC," and the second repeated, "XYZ."
You've probably heard these discussions before; you may even have participated in them. Both parties were stating their positions in what they saw as a clear and convincing manner. Neither either saw the need or had a way to try to link the two statements together so they could make progress deciding which was more useful to them, and so they kept talking past each other. It continued until the end of the break; there was no natural resolution. It was polite, it was friendly, and it wasn't very productive. I've heard those discussions many times in my career.
The system dynamics course was fun and intense: three full days of work learning system dynamics and working example problems, intermingled with two homework days in which they worked together as teams to solve some fairly difficult problems using simulation and without my help except by email. It must have been successful, too; while I had hoped to get the opportunity to come back and help their organization address specific problems using system dynamics, they felt comfortable enough afterwards to do it themselves.
I enjoyed working with that group for a number of reasons. One thing particularly caught my attention. In a break on the last day, two or three people, perhaps the same group, again started a discussion about a problem they faced at work. This time, instead of stating and restating their positions without a way to achieve resolution, the first person said, "DEF" (different problem this time) and then drew a stock and flow diagram that helped make that position clearer. The second person said, "UVW" and drew a stock and flow diagram to clarify that view. Then they started talking productively, using those models, about how their world really worked, about specific questions they had about each model, and about what they might need to change in one person's or the other's view to align more closely with reality and to be more useful for their work. While they didn't (yet) agree on answers, they gave every sign that they understood and appreciated each other's thinking and that they could converge on a common answer that was good for the organization, not necessarily one that agreed with their originial position.
Four and a half days of serious thinking on their part had taken them from being a normal workgroup to being one that could express ideas clearly, advocate for them effectively, and engage in serious dialog on ways to test their ideas and come to a resolution about how to proceed. While they didn't create a simulation model in that 15-minute break, they gave every sign they could likely have done so, given a bit more time.
Moreover, I think they had learned how to peer into each others' now rather explicit mental models to find the crux of problems or differences, which should let them focus their simulations on the essence, the core, of the situation and not the entire problem.
I was proud of them. In four and a half days, they had learned and decided to use what Barry Richmond called "operational thinking." I'm not sure they would have done that without the experience of learning to model and of seeing what their simulations could bring.
Do you see people saying "ABC" and "XYZ" in your organization? Do you wish your people had a better language for wrestling with tough problems? What techniques do you use?
While I like Barry's article quite a bit, I do have one point I'd like to take issue with. I'll save that for tomorrow.