The Cynefin Framework
More or less one year ago a friend of mine told me about a theoretical model that aids decision making. At first I was very skeptical. But the more I studied Cynefin the more intrigued I became. I think that describing this model here is a waste of time – there is at least a dozen of presentations available in the Internet, at the end I link a few.
Anyway, for those not wanting to make the effort – Cynefin is a complexity model postulating that beside ordered systems (where agents’ behaviour is predictable) and chaotic systems (where the behaviour is random) there is another very distinct domain – Cynefin names it “complexity”. In such systems the agents are lightly constrained and they not only interact with each other – they also influence the system itself. Therefore – any given action made at two different moments may bring a completely different result. Cynefin postulates that when facing this kind of a system we should follow probe – sense – respond pattern – it is impossible to predict the results of our actions, so instead we should focus on probing the system (experimenting) and sense about how the system reacts.
Dave Snowden (father of Cynefin) postulates that systems involving humans are often complex. And one great example of a complex human system is an organization. Therefore, decisions made when managing a company should follow probe – sense – respond pattern described above. With this in mind I started to retrospect all the ideas we implemented in TouK during last years. Surprisingly to me – I found a lot of resemblance. Having came to this conclusion I started to analyse further actions using this framework.
The presentation I gave at Lean Agile Scotland 2012 wasn’t about Cynefin itself. It was about a few things we tried out in TouK. The Cynefin model was used as a common denominator of all of them as well as an inspiration for some.
Management on all levels
Before I present what was supposed to be the actual content of the talk, one thing needs to be mentioned: the philosophy of running TouK can be described with the title of the talk by one of LAScot’s speakers – Florian Eisenberg. We are a company with as flat a structure as one can imagine. Despite that (or maybe rather because of it) decisions tend to get stuck – the bottleneck is the central decision organ. Therefore, since a long time a lot of stuff has been done to let those decisions be made as “close to the battlefield” as possible. This way decisions tend to be made quicker with as much of context details in mind as possible.
Probably the primary goal of all the stuff I talked about at LAScot12, that are described below, was to make “management on all levels” (one can call it “self-management”) possible. This basically included aligning the whole company with a common goal and giving the people the knowledge, skills and data so that correct decisions could be made.
One of the first things Cynefin mentions about managing in a complex domain is the need for boundaries. It is boundaries that allow behaviour patterns to emerge. On the other hand the thing we started to notice when TouK grew was that it became harder and harder to share the spirit of the company, something that was very obvious to everyone in the early days, even though probably no one was ever aware of it and it would be hard to describe it precisely.
Our take on those boundaries will not be unfamiliar to those accustomed to doing agile transformations. We used an approach widely adopted in business and probably in many cases abused – we agreed on the companies core values. It took some time for this agreement to forge, but in general the process resembled what agile teams sometimes do when they form – we discussed what is important to us and tried to find common parts. One important thing about this discussion was that it was done not only by the owners of the company but also a few key employees were invited. (Note: yes, I am aware that Dave Snowden advocates against naming core values believing that it kills diversity.)
We did this to communicate which types of day to day behaviour are aligned with the founding concept of the company and which are not. An example of how this works – some time later on one of the teams suggested that quality of the product they were working on is lower than they expected. This team came with a recommendation – let’s create a QA division, hire some testers and they will make the quality improve. I am not trying to discuss pros and cons of this idea – what is important is that having QA team is not something we believe in. And that’s because one of our core values is based on the concept of generalizing specialists. And we understand this idea in this way: it is us, software developers, who are responsible for the quality of our products. Thus we will not mandate decisions that let this responsibility to be shifted to others.
Having had defined the boundaries, in which we allow our team to work, the thing we were missing on a large, strategic scale was guiding everybody to go more or less in the same direction. And to make it happen we had to first agree on the direction, then communicate it and finally – get as many people as possible motivated to go with us.
One way to do it, and the way we chose, is called Big Hairy Audacious Goal, also known as BHAG – something big, something making a difference. And most importantly – as we wanted it to motivate others – this one had to motivate ourselves. There’s been lots of discussing on this topic but we finally came to an agreement that if it has to be one thing – we want to become recognizable, as a company. And we phrased it in a very strong way – we decided we aim at becoming the most recognizable Polish ITC company. Not (necessarily) the largest one, not (necessarily) having the largest income or profit – yet the most recognizable.
Do we believe it is possible? Yes – right now Poland is not renown for its ITC companies at all… Do we believe it will be easy? Definitely not – but if it was it wouldn’t be a challenge…
There’s one more thing to mention here – and I strongly believe this also is true for most development projects. There’s a lot of confusion about whether the most important goal of any company is to make money. And I really dream about times when we are done with this superstition. Making money is not motivating. Making money is not making a difference. Of course, making enough money is required, but this goal itself is not making us wake up in the morning every day with an urge to act.
The Cynefin framework really emphasises one thing about managing problems in the complex domain. It says extensive planning is useless as no one can predict how the system will react. The correct attitude basing on probe – sense – respond paradigm is to start where you are and launch experiments. If an experiment works and brings positive reaction – amplify it. If the results are negative – try something else.
As we believe in this idea we didn’t try to come up with any 10-year plan of reaching our BHAG. What we did instead is that we tried to evaluate where we are and tried to make a first step in the direction we set.
Having this in mind, very quickly we started to realize that thinking in terms of just our BHAG is very dangerous. A company is much too complex to consider it in just one dimension. Inspired by management technique called Balanced Scorecard we decided we have to act in many different areas in the same time. And as we believe the company is a whole, those areas influence each other and overlap. Thus, there are no divisions in TouK – instead we look at our company from six perspectives.
It all starts with the Survival – the perspective of investors and stock owners. If we go bust it really doesn’t matter how much good we wanted to do. We cannot survive if we don’t manage the Relations – both with our current and future customers. Being a service company – our relations are founded on the quality of the service we provide – hence we must focus on our Fitness. In the same time – we cannot provide value to our customers if we forget about the Evolution – staying on top of newest technologies, tools and techniques. None of those will be possible if it is a responsibility of few. To involve everybody we need not to forget about working on the Culture. And finally – one of the things that differentiate our industry from so many others is the fact that we can build on the work and experience of others – therefore we also want to give something back and focus on our Contribution.
These six perspectives constitute the way we think about our short term tactics. We selected six first steps we want to make – one in each perspective. This turned out to be a great way of communicating the strategy, so that everybody knows what to expect.
Many people during their professional career witness projects that aim at organization restructuring. These projects usually use a lot of resources and personally I believe they rarely provide expected value. As we grew we started to consider that we need some kind of structure but very quickly decided we don’t want to be involved in such a project. We agreed to begin with assessing the situation, thinking that after that task we might be able to decide where we want to go.
After some research and looking for a simpler approach we decided we will adopt RAPID decision making model. It basically recommends how to describe and communicate the way any decision is being made. For a given decision five roles should be defined. To some extent – two most involved are: Recommend – these people are responsible for coming up with suggestions and Decide – a person in this role must choose between the recommendations. Important, though often inactive, is Agree role – these people can disagree with a recommendation (i.e. due to legal or financial reasons) – and it is the responsibility of a person holding the D to find a consensus between Rs and As. “I” stands for Input – a group of people that might have valuable information, but who are not directly responsible to get involved in the process. Eventually, it always comes to Performing the actions – great if it is clear who’s responsibility this is.
One thing is worth noting – finding a single decision responsibility prevents a lot of confusion – we agreed that there’s only a couple of decisions that will require a group to decide collectively. In the same time – this model encourages discussions.
The idea we were after when implementing this framework is rooted deeply in Cynefin and was already mentioned. Don’t prepare complex plans – just start where you are at the moment and evolve with small experiments. We tried to follow this pattern – first we catalogued the most important decisions that were being made. Then we described how we were making those decisions at that time – thinking in terms of specific people, not job titles. Only after that we looked for patterns – it doesn’t seem unwise if similar decisions involve the same people. Having done that – we started to evolve our RAPID matrix.
The F Team
As I said earlier – successful management on all levels is only possible when the whole organization is granted access to data and has an ability to understand this data. And no matter what people say, in most companies decision making process is often driven by financial consequences (unfortunately only few can forget about it). TouK is no different. At some moment it became obvious that if we want others to make correct decisions people must know and understand how money flows through this organization.
To make it happen we started something we called The F Team. We invited people that were already responsible for teams & projects (we call them project leaders). And we shared almost every detail of the company financial situation. We also explained a lot about how it all works. This is not rocket science (after all, everybody is responsible for his own private monthly budget) but I guess that as soon as people start to be responsible for more than just private income something changes (similarly to national budget…). We presented what happens if we delay projects or not hit deadlines. We presented how team staffing influences the outcome of projects. And how projects sum up and make the result of a company.
Most importantly – this is a step towards a situation where everybody in the company understand how their work does influence whole organization.
This whole concept was inspired by Open-book Management. It is an idea coming from Jack Stack from SRC Holding in USA.
Another idea that was described by Jack Stack that we wanted to adopt is called The Great Game of Business. We use it to address our weaknesses.
At the beginning of 2012 we were trying to agree on what is our greatest problem we want to solve. We agreed that, having in mind our BHAG and strategy, we want to focus on two things. The first one is gaining international recognition. Second – it is an acquisition of new customers. Inspired by the Great Game of Business we decided to create a game around these two areas.
The rules are pretty simple – in both areas we listed activities that earn points (i.e. for recognition – when someone presents at a conference – he scores; if it is an international conference – he scores double). It is a cooperative game – we play against the environment (PvE for those familiar with computer games). At the end of the year – if we get enough points – we win. And this is an extremely important aspect of this idea – it is not yet another way of individual performance measurement – we play as a team – we either all win or all lose.
Where is a proper game there must be a prize. And personally I do believe that this type of a financial reward is the only type of financial rewarding that doesn’t undermine motivation and – in the long run – performance. There is lots of materials on this topic, with (probably) the most recognized example of Daniel Pink’s book “Drive” and a few talks that are available in the Internet (or found in references at the end of this text).
Last experiment I talked about during the conference was the way we dealt with salaries. Deciding how much an employee should earn is not an easy task, especially if you aim at being fair. Many companies are dealing with this making salary matrices, career paths and stuff like that. I believe this is an attitude from the border of simple and complicated domains in Cynefin model. And also such “salary systems” are easy to hack by smart people (like software developers). The other extreme is a system where one central agent is making all the decisions. This is how we handled salaries for years. And it doesn’t scale.
Our idea was (again) pretty simple – and (I believe) rooted in the agile way of estimating backlog items. We decided we will allow only a few specific amounts – with large differences (30-50%) between those amounts. Negotiations will not be possible – the only way to get a rise is to be “promoted” to the category with a higher amount assigned. And every employee was assigned to a category corresponding to their current salary and competence level. That was just the beginning…
The most important thing we wanted to do was to make those categories public. And, even though I am sure this is not true everywhere in the world, in Poland salaries are a taboo.
The part that was, strongly and directly, inspired by probe – sense – act paradigm was how we rolled this out. Cynefin places a lot of emphasis on designing safe-to-fail experiments (instead of organizations safe of failure). We rephrased it and planned the roll-out in a safe-to-stop way. We were really unsure what the reception will be and we were aware that we are operating a living organism.
Our plan consisted of small steps (as small that we could possibly think of). After we forged the initial concept we invited a small group of employees for a discussion. They were selected with one key thing in mind – they are respected and can influence opinions. This is something I would blindly recommend to anybody trying to change an organization – find people that can influence others (they are rarely top level guys) and buy them in or at least ensure they won’t be against you. If you fail with this – forget about changing anything.
Having discussed the topic with this group we invited everybody. As having discussions in any large group is impossible we asked for feedback by email. Not surprisingly – there was a lot of doubts. Therefore, we implemented a simple script for our internal wiki that allowed everybody to vote – and when voting “Yes, I agree to make my category public” one was given access to the information about others who already agreed. And that is my another blind recommendation for people trying to convince others to something new – do not force, let them make this decision. Educate, so that a correct decision will be made, but still – let them make it.
Anyway, we ended up in a place we more or less wanted to be at the beginning. One of the effects of this experiment is that we managed to create a self-balancing organism. Right now, in many cases it is the voice of the people that drives the process of giving a rise.
The details of how this idea looks like, how it was implemented and what we got out of it deserve a blog post on their own.
Applying this stuff to project management
Not everybody out there is facing a possibility to change the direction in which their company is going. Nonetheless, I believe most of the ideas presented above can be used in some form in projects – at the project management level or at the leadership level. But, as this post got already too large – this will be a topic to be discussed later on.
Do not try to manage developers. I tried and got burnt. By managing I mean all the stuff encapsulated by slightly overused term “micromanagement”. Developers (and I strongly believe most if not all of this applies to other kind of knowledge workers these days) are smart. And smart people hate being micromanaged.
What you should do instead is let them manage themselves. This won’t be possible without creating an environment in which self managing is possible. And by creating such environment I mean giving proper knowledge, sharing the required data, empowering to make decisions and most importantly – helping along the way.
I tried to give a few examples of the basic ideas that I found in Cynefin model and in what it advises about managing complex systems. To sum it up – start where you are, do experiments and sense the reaction of the system. Design your experiments so that they are safe to fail and if they don’t work – recover and experiment some more.
Final note to the smart guys :-)
I am aware that this post will be read by a few folks I work with every day. And probably few of them will use information here against me :-) . But despite that, I believe the general results of the experiments described above will constitute culture that will attract great people who in turn will make a great work environment. In my opinion these experiments have already started to pay off.
The slides from Lean Agile Scotland are available on Slideshare – click here.
Resources & follow ups
I strongly recommend checking this stuff out…
Fred George’s presentation on Leaner Programmer Anarchy at QCon London 2011
Cognitive Edge’s YouTube profile with David Snowden explaining basics of Cynefin along with the Cynefin story on organizing birthday party for teenagers
Dave Snowden’s talks at ALE2011 and XP2012
RAPID decision model
HBR article “Who has the D?: How Clear Decision Roles Enhance Organizational Performance” by Paul Rogers & Marcia Blenko
Daniel Pink “Drive: The Surprising Truth About What Motivates Us”
Daniel Pink’s TED talk on “Drive”
Steve Keil’s TED talk on “A play manifesto”
Open book management
Jack Stack “The Great Game of Business”
Jack Stack “A Stake in the Outcome”
All photos used are licensed under Creative Commons License.
Post and rail in snow
Amsterdam Central Station
High Trestle Trail Bridge
Die, Stormtrooper, Die