Communication as Structure

Most management experts nowadays agree that the management practice of command & control is not appropriate for organizations were the employees are knowledge workers that need significant cognitive skills and a creative spirit to do their jobs.  I wholeheartedly agree with them.  We know about different styles of management that foster creativity and productive cognitive work.  Unfortunately, this new type of management is not yet very widespread and I believe we need to find out why this is so and what we can do to change it.

Of course, I am not the first one to come to this conclusion.  Check out the Stoos Network for people, blogs and discussions about changing the way of command & control management to an agile leadership.

One of my thoughts on how to start breaking command & control is to start describing organizational structures no longer in hierarchical Org-Charts.  Every organization of more than 10 people feels the need to create an Org-Chart.  And we all know how an Org-Chart usually looks like:

Looking at this picture, it seems inevitable that the CEO will command his managers and they will do the same to the people in their organizational branch.  That's what the boss does, right?  And that what the lines from top to bottom imply, right? We even call the upper level nodes line managers.

I am not sure if we can abandon this idea completely, as one of the top management thinkers of our time, Peter Drucker, might imply when he says "The modern organization cannot be an organization of 'boss' and 'subordinate', it must be organized as a team of 'associates'."  But I sure am convinced that the hierarchical boss - subordinate structure is not the best way to describe how an organization should be structured!

So what is a better way, then?  Communication methinks.  Knowledge workers must be able to easily communicate with each other to exchange ideas and experiences and knowledge and information and emotions and and and...  So, when an organization or a system of individuals needs structure, it will hopefully align along communication channels so that the individuals that are in need of close and frequent communication will join together in an organizational unit.

Note that I have intentionally not spoken about creating an organizational structure, because I think ideally the structure will develop or grow with much self-organization involved.  The agile leader helps an organization to grow the required structure to enable the best possible communication.  See also Management 3.0 (the book and / or the course) to learn how to grow structure.  In many cases the structural growth will be a mixture of design and evolution.  Which sounds a bit like an entirely different discussion about what to teach in biology class in some states in the US…  I have a very clear opinion on this as well, but I will save it for another blog at another time.

In the end, you will need to visualize the organization’s structure, whether it grew or was intentionally created by someone.  Put the people that (need to) communicate intensively into a cluster:

 

Such a cluster is often called a team.  There is, however, more to a team than close communication.  So be careful to make sure that your clusters also have a common goal and the willingness to help each other to reach that goal if you want them to be a team.

The lines between the people are communication paths.  I suggest to leave them out of the picture and to imply that all members of a cluster will have sufficient paths to most of the other members so that information can flow easily between all members.  The picture will be a lot easier on the eyes.

Examples of such clusters in software development organizations are teams of developers or a scrum team (developers with scrum master and product owner) but also a team of product owners that work on a joint product backlog.  So, no matter if the members of such a cluster have the same line manager or not, do put them into the same cluster in your organizational picture.

If one member of a cluster has a communication path to a member of another cluster then they are linked by a bridge.  Bridges are particularly important when they connect distant clusters, making them near.

A sample subset of a development organization could then look like this:

These teams look like they can self-organize and are allowed to do so.  No manager to be seen (yet).

Of course, this is a first example.  We need to make it possible for the teams to also have bridges to one-another so that communication is not moving through the Product Owners.  And what about the managers?  I believe they are still needed.  So where are they in such a picture?

The answers to these questions need more space and time than this blog post allows.  You’ll just have to wait for the next installment.