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).
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!
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.
ReplyDeleteIt 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