Thursday, May 22, 2014

Stop bashing managers!

Recently I‘ve heard people say things like: „If we only could get rid of all managers, life would be good.“ Or „A truly agile organization does not have any managers.“ While I agree that many organizations do need a different kind of management, I deeply disagree with the notion of getting rid of all managers. Here’re some reasons why.

It’s insulting
At the Lean Software and Systems Conference 2012 (before being renamed to Lean Kanban North America) I saw a great Lightning Talk which startet with the following, made-up, pie chart (and as you know, I like made-up charts):




What the chart basically says is that in reality we have very much managers, like it or not. And my experience is: Most of the managers are good people. If they do what we consider bad management, it is mostly due to strange policies and bonus systems that were in place and influenced their behavior.
If we say that we need to get rid of management, we will most likely insult all these people – no matter if we intend to do so or not. They will hear things like: „These guys think that I have done a bad job in the last 10 years.“ I don’t thing this is the way to go if we want to change the world of work.

Setting missions and aligning teams
Although I consider myself a pacifist, I am a big fan of the concept of Auftragstaktik and its implications for business. If you haven’t done already, I really recommend reading the book The Art of Action by StephenBungay. You can also find a free interview with him here.
We like autonomous teams that figure out how to accomplish their mission for themselves. They experiment their way forward through unknown territory and they will figure out how to do it. But where do the missions come from? And how do we make sure the missions of our different teams are aligned with each other? Sure, in theory the teams could set their own missions and coordinate them with other teams. My experience just tells me that this is very hard (if not impossible) for teams to do.

Managing interactions  and (re-)designing the system
According to Russell Ackoff, „The performance of a system is never the sum of the performances of its parts. It’s the product of their interactions.“ If we agree with Ackoff’s statement (and I’ve seen a lot of evidence for this at different occasions) then someone has to manage the interactions of our system’s parts. In the Agile world teams are probably the most important parts of an organization. Who is responsible for managing how the teams interact with each other? Again, theoretically it could be the teams themselves. In practice I doubt that this will work very well (and I will argue why in the section about local optimization).
Another aspect that’s relevant when talking about Ackoff and Systems Thinking is the design and re-design of our system. As far as I can tell, Ackoff was not convinced that continuous improvement is always the best solution. My friend Markus Andrezak likes this quote by Ackoff very much: „To be ahead of the competition you need o leapfrog them.“ What is true for product development is also true for our processes. Ackoff’s examples of how to improve organizations contain a lot of major re-designs. Deming argues in a similar way: Because it’s the system that causes the biggest part of the performance (Hi, PawelJ I think Deming talks not only about variability here, but also about performance!), and not the individuals, we need to change the system if we want real improvement. According to Deming, this is exactly what (good) managers are there for.

Recognizing local optimization 
Agile teams are supposed to work on accomplishing their mission with a laser-focus, and thereby with great speed. That’s one of the main reasons why we set them in place. But this focus comes with a price: local optimization. The Don of Lean (Don Reinertsen) argues that we will most likely see local optimization when the benefits and the costs of an action occur at different places in the system (see this great talk by Don for deeper insights). This fits my observations with autonomous teams: They tend to sub-optimize the whole in order to optimize their team’s outcomes. Nothing to complain about here. We cannot expect teams to focus on their missions and take care of the whole company at the same time. And, again, it’s exactly what Systems Thinking tells us (you can probably tell by this post that I’ve been reading a lot of Ackoff’s stuff recently:-): „If you optimize the parts, you will sub-optimize the whole.“ If I get this right, one conclusion of this is that someone needs to have a bird’s eye view on the system to recognize when local optimization is about to happen. Yes, I do think the big picture is important (although it has become a kind of a bad word).

Russell Ackoff - read his books!


Changing the team setup
Teams are capable of doing remarkable things. I’ve seen teams that were considered to be the worst performers in the company improve dramatically and perform really well after some of their boundaries were changed. At the same time it’s true that sometimes teams are highly dysfunctional and that they won’t change without external influence. As a last resort, taking people out of the team, adding new people to an existing team, or even abolishing a team completely can be the right thing to do. Teams have a very hard time doing this without external help. In many cases they will not even realize that there is a dysfunction or, when they do, they won’t talk about it to anyone.

Conclusion
First of all we should not offend all the people with management titles out there.
Further more I’ve argued that we need people who are not part of our autonomous teams. They need a good standing in the organization and mus have a good understanding of our systems. They are responsible for managing the team’s interactions, re-designing the system and observing and acting upon local optimization. And sometimes they need to change the setup of a team. For me, that’s exactly what a good manager does. So let’s stop bashing managers and start working on establishing another understanding of management!

2 comments:

  1. Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.

    ReplyDelete
  2. It is interesting to read all .Having served many many companies for 40years, I agree with Deming.when a company in chaos,like sickness, if you go to a small doctor,he prescribe medicine for less expenses. If it is specialist , it cost more. If you super specialist hospital, they treat till your pocket empty. Sickness might be minor headache on lack of sleep. If he taken rest and slept, it would have cured. The anexiety and greed block mind to think. Management experts suggest many ideas from Japan and China. They failed as Deming said. Why? Cultural differences and genetic functions.Mangolian races are slow,submissive and dull headed who want instructions at every steps to act and as micro management to dependent to boss. Is it workable for independent thinking workers? Do research?

    ReplyDelete

Yes wie Kanban Yes wie Kanban