Don’t reorganize – Deorganize!
Organizations tend to do this every now and again: Reorganize the structure to suit a new strategy, a change in the management team, try out a new hierarchy model, and so on.
In this post I lay out some alternatives, and end with a practical first step.
One of the pitfalls of reorganizations is that they provoke a huge amount of anxiety and resentment: people’s direct and indirect managers change, their role description changes, their promotional path becomes unclear.
I would like to suggest a different approach. Instead of a reorganization, gradually deorganize. Shed away redundant structure, and replace them with loose structures. Allow your organization to grow in response to real market needs, and not according to a decision that was made a couple of years earlier based on data that may have been momentarily correct, but have become irrelevant for today’s reality.
Sounds impossible? Actually, you see such structures every day of your life. When you see ants collecting food for winter, when you see schools of fish swimming together, when you watch migrating birds practicing towards their long flights and when they embark on their fantastic and inspiring far-away journeys.
Waders in flight Roebuck Bay. Photo by Mdk572, Source: Wikipedia http://en.wikipedia.org/wiki/Bird_migration
These structures are not decided upon – they emerge according to changing needs of the group. Even ants have changing realities: when their nest is being attacked or flooded, as well as when they prosper and have food in abundance to accumulate for rough times.
In our business life we like to think that we can create strategies that can predict our organizations’ growth and needs for upcoming years. The truth is as far from this as can be. A good strategy is one that enables the organization to continually change in reaction to its present reality.
There are several keys to enable such strategies. There must be more, and I will share the ones I can think of now:
- Build the organization around stable, self-organized, self-maintained teams. Birds breed, old birds perish, and the survival of the individuals depends on the continuity of the flock.
- Build teams around the teams to manage their boundaries, and not manage their people. There is no chimp or seagull in command – and yet there order emerges; the role of the leaders is to protect the boundaries, not to order individuals what to do next.
- Create mechanisms to identify dependencies and dissolve them to increase their self-organization and self-maintenance. Survival of the fittest is not the strongest in physical strength; rather the ones most fit to endure change – guide your teams to the changing reality.
- Reduce integration effects among teams by modularity of the teams’ products. Species that depend on a small variety of foods find it harder to survive. Unless…
- Sometimes dependencies are inevitable, if only for a transient period. Encourage such teams to develop mutual relationships that will lead to win-win conditions. Symbiotic creatures benefit from each others’ strengths, and protect one another from their weaknesses.
- Like ants, continually prepare for rainy days. Education, refactoring, learning, are among the activities that will enable such teams to survive rough times
- Encourage diversity within and among teams. Diversity may manifest itself in members’ credentials (developers, testers, writers, …), seniority and experience, idiosyncrasies, gender, and more. A beehive with only queens or workers will not survive.
If you are a leader in your organization, and you want to learn how to respond faster, how to enable your teams to surpass even their own predictions, start by learning what makes your organization rigid in its current form.
Dan North, the originator of BDD and Deliberate Discovery, will be holding this one day workshop at the Agile Practitioners 2013 conference.
As Prof. Deming so elegantly put it: “Learning is not compulsory. Neither is survival”.
Becoming agile 
Execlent post! I love your writing.
Thank you, Shirly!
A truly lovely post to start the new year. Immediately twittered 🙂
Thank you much, Tobias
I hope upcoming posts will be as good
Ilan
This post really got my attention, as it maps well to the lessons we have learnt in our agile journey. We currently have around 30 teams across four locations working approximately as you describe above.
Some of the challenges we’re now facing include how to handle bigger projects/features that span multiple teams, how to spread learning across teams, and how to get consistency on the few things that are needed (eg. some consistency on use of production environment, consistent UX “feel”)
I look forward to your future posts, and please feel free to get in touch as I’d be interested in chatting further.
@Geoff,
I’m glad that the post hit a chord – shifting to this kind of structure requires courage, more so in large enterprises where are are so used to traditional management styles.
As for projects spanning multiple teams: In the same token as this post, I say: “Don’t Scale Agile – Descale Agile!”. That is, the fantasy is that we will enforce a common architecture or common look and feel that it will defuse into the teams – but this does not happen.
Instead, I am suggesting to put more trust in the teams, and to let inter- and intra-team forums develop these standards. This is no trivial task, because teams need to evolve into it, and managers need to evolve out of former structures.
You can read more about it in Henrik Kniberg’s Spotify case study here: http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
Indecently, I also use the term Guilds, as per this article, to foster a community of professionals (developers, testers, architects, and so on) at the clients I work with. The term Tribe refers to stability of the organisation.
Let me know if you find Henrik’s article handy. In second thought, let Henrik know first, and me afterwards.
Your article provoked interesting thought. I had not previously considered the organization of bird migration as a good source for business organizational and planning management. But there is sense in this comparison.
The animals tend to repeat similar patterns with the change being their adaptation to weather and other outside forces rather than inner turmoil. It implies a near-mental telepathy ability! Although, this is part of their instinctual nature.
Many companies give lip service to this style of leadership. After working in a large corporation, it would appear that this sort of adaptation must be taught, rather than implied.
Your steps give a great starting point toward educating this process! Thank you!
Regarding your comment about provoking anxiety in employees (para. 3), I agree but wonder whether there is any good way to challenge change without creating feelings of chaos among employees?
Hi Kat,
Thank you for the comment. At the time of writing this post (2013) I was fascinated by the resemblance of groups of animals to the natural organization of people. Also with the unproductive architecture of modern human organizations.
Regarding steps to reduce anxiety: since the emergence of theories (and practice) on identifying anxiety in groups in the 1940’s there is work also on the ways to overcome it. Notably, Viktor Flankl’s work (“Man Search for Meaning, 1959).
However, much of both fields of knowledge was little practiced.
On the personal and interpersonal front, in the last 2-3 decades there is wealth of theory and practical knowledge on “Positive Psychology”.
Three of the practical concepts I keep returning to are:
– Mindset, by Carol Dweck
– Grit, by Angela Duckworth
– Switch, by Dan and Chip Heath
The idea is, in addition to identifying the problems (that is, not ignoring them) focus on what works, and what can be changed.
There is also a lot of empirical work on how the brain operates, and how a better physical setting – office design, walking and moving around, contributes to better state of mind to be in a positive attitude.
A similar history happens on the organizational architecture front.
In the 1940’s Eric Trist and Ken Bamforth illustrated an organizational architecture that promotes self organization and a matching style of leadership, based on their research of the Elsecar Colliery in Yorkshire (UK).
In recent decades there are more practical frameworks to take this theory into practice. But practice and enacting it are two different things.
In software development, the Large Scale Scrum (LeSS) framework lays a set of principles and practices to design an organizational architecture that promotes self organization, socio-technical teams, servant leadership and such.
Not many choose this path.
But those that do experience a growing sense of ownership and continuous improvement.
Indeed, LeSS is not the only framework to practice Socio-Technical Systems.
However, we are so indoctrinated by the Tayloristic principles of the 19th century (heck, but the overly rationalistic philosophy of Socrates and Plato!) that most organizations do not take the Road LeSS Travelled, and that’s a real shame.
You may find more references to a wealth of knowledge in this field in the Useful Resources for Scrum Masters here:
http://practical-agile.com/resources-menu/useful-resources-collections/195-recommended-reading-for-scrummasters