Self-organization is sometimes called the ‘secret-sauce’ of successful teams. Think of it as a cook: If the curry sauce is bad, it can ruin the entire meal. So it’s the core of a good curry meal. At the same time, self-organization is in my opinion one of the most misunderstood concepts. Why? Because the term ‘self-organization’ suggests that teams achieve results somehow, just do what and how they want, with no governance around it. In fact, the opposite is true. Look for example at Scrum, which embodies self-organization as a key principle, however requires following strict (minimal) processes around it and a clear vision on top (what do you want to achieve?). Self-Organization is promoted more and more as a base principle of modern management and agile practice. It’s a counter-movement of the 90ies Command and Control Style. Or is it just a bad excuse of management for the chaos by pushing away responsibility? Good self-organization is one of the most challenging things to achieve on a team level and requires a high level of discipline and personal maturity. Of course, we are as individuals all self-organized up to a certain point – in terms of how we accomplish our goals. Last but not least this depends on our capabilities. But that’s not the essence of self-organization. Having self-organized teams is about fostering an environment of highly motivated individuals and continuous improvement in a fast changing world, achieving a common vision. In a nutshell it includes:
Building the right environment
Having the right team composition is key; ideally this should be self-motivated employees, who seek to accept greater responsibility. They pull work for themselves and don’t wait for their leader to assign work to them. This ensures a greater sense of ownership and commitment. Self-organization is a driver for motivation. Never underestimate this: Motivation and the resulting morale are multipliers for performance. This is where great things start. Self-organizing teams must always be cross-functional, as this speeds up decision making. However, self-organization does not work with ‘Type X’ people (in contrast to Generation/Type ‘Y’), who are actually not looking for such a kind of environment. This is also why it worked well so far in pure IT Ops environments. In case you are not familiar with Theory X and Y, read here.
Inspect – Adapt: Empirical process control
Self-organized teams decide on their own what the best way/process is to achieve their goals. Nobody assigns them work from outside (no command-control from outside), they figure it out by themselves what work needs to be done to achieve the overall goal. And they are aware, that it is an illusion to have a perfect process from the beginning. So they just start with something lean and simple to achieve the goals – and they start early. Self-organized teams stick to the initial process and after a defined period of time the process is reviewed (Inspect). What went well and what didn’t? What are the improvements? The team is the expert to answer these questions and based on that, the process will be adapted. These steps are done over and over again and build the base for continuous improvement and appropriate reaction of outside changes.
Self-organized teams often require coaching from outside, especially at the beginning of their path. But this is different from traditional leadership, the traditional command & control style does not work. The coach should embody rather a “servant leadership” style.
Putting it into practice
So how it is put into practice? To a certain extend it is like biking: you finally understand it once you really experienced it. But luckily there are methods out there, which give us some good advices: For example Lean & Kanban (out of the manufacturing world) or Scrum (out of Software Engineering). Being in this area for a while, I personally prefer practicing Scrum: It promotes self-organization as described above. Coaching of the team is ensured through the Scrum Master role. Continual process inspection and adaption by the self-organized team happens through various meetings such as the daily scrum, the backlog grooming or the retrospect sprint meeting. And: If you think this is a Software-Engineering thing, consider this. You can use it anywhere. But again, once you practice it and assuming you are a Type Y person, you will immediately understand it and like it. Being a self-organized team is no only about an intellectual understanding on how to do agile projects – it’s also a body language and a way to move through the world.
As I write this blog on itil.org, there is one question left: What is the relevance of self-organized teams for IT Service Management? I think it is very much relevant and brings in a new way of developing and implementing an ITSM system including it’s processes. A way that is finally also accepted by the people who work with it and turns them into highly motivated and performing teams. I leave it up to you to think this part to the end.