I’m particularly happy that I finally used the Cynefin framework by David Snowden for two reasons. First, it helped me and my colleague to make the right decision when we were in doubt. Second, until now I haven’t seen anybody using the framework besides Mr. Snowden. The speakers and bloggers talk and write about the framework itself, but I haven’t heard a single story about how to use it the framework in real life. Maybe because it is so simple that it doesn’t require any specification.
Anyway, back to the first reason. I was in a heated discussion with a colleague because he wanted to solve an issue in his own way, and as usual I wanted to solve it in my way. After a while he stopped the discussion and proposed to visit the Harvard Business Review article I had referred him to a while back (at that time, we were referring to David Snowden’s A Leader’s Framework for Decision Making article from 2007 as the Harward Business Review article). And that was the first good idea we had during that discussion.
We had a hard time figuring out how to integrate the design work into our workflow. As I mentioned before, we wanted to solve the problem differently, but none of our solutions looked good enough to start with. So we took the leadership table from the framework (see below) and tried to provide examples to each cell in the Nature column (in the original HBR article the column is called the context’s characteristics):
(Note: the copyright of the image above belongs to David Snowden, and the original version can be found here: http://cognitive-edge.com/blog/entry/5802/cynefin-revised-leadership-table/)
As it turned out we weren’t in the complicated domain as we originally assumed (at the time we had never used the words complicated and complex, but we were trying to solve a problem that looked predictable and that falls into the complicated domain). We were in the complex domain: the relationship between cause and effect was messily coherent and our samples showed contradictional results (how a design is created, and how the developers get the design). When I look back and think about this particular discussion it is clear why we were unable to tackle our issue: we were using the sense-analyse-respond routine of the complicated domain and there was no way that we could sense this problem properly because it was so nondeterministic.
So, we stopped sensing and tried to figure out how to probe (in the complex domain the suggested routine is probe-sense-respond) our workflow and designed a couple of safe to fail experiments to learn more about how the design is actually created in our workflow. As far as I remember, we created two or three experiments.
I have to add that we haven’t completely solved our design issue for two reasons. First, although we managed to move our problem from the complex domain to the complicated one, and now we know what to expect from design, but we still have to understand creative processes, and learn how to integrate artists (designers) into an engineering organisation. Second, I’m not 100 percent sure that we have to solve this issue right now. It is in the right domain for us, and I have doubts that the next domain, the simple domain is the right place for creative work.
comments powered by Disqus