Over a million developers have joined DZone.

The Trickle Down Effect of Management

Learn about self-organizing teams and how different management styles can affect every single employee the company, in some ways you might not expect.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

This is an important article. This is the ninth blog post in my mini-series on management and it is the post all the others have been building up to. Let me recap some key points:

  • When creating software, there is coding work, testing work, requirements work, and some unavoidable management work.
  • Removing managers may remove some work (because managers make work for other managers) but there is still a residual amount of management work to do.
  • Management itself is a skill and requires intuition.
  • It takes an engineer to manage engineering. People without experience doing software development are going to struggle.
  • Management decisions can make a big difference.
  • All who are called “Manager” are not managers — some are specialists.
  • There are many non-commissioned managers (NCO managers) — those who manage without the title of “Manager." Frequently, these people manage with minimal or little management.
  • Management work may be done by specific people, commissioned, or non-commissioned managers. It may also be shared among team members.

I’ve deliberately avoided discussion of self-organizing or self-managing teams because these subjects deserve posts to themselves. Here are my key points.

  • When decisions need to be taken, they are best taken close to the point where they are needed.
  • When decisions are needed, those who are staring directly at the decision are often the ones with the most knowledge about what is needed.
  • Taking decisions at the point the decision is needed also makes for a rapid decision.
  • It may make sense to get a second opinion, to talk through a decision with another person or in a team, and if the decision affects several people, it probably makes sense to consult with them.

One way to address these points is to use a self-managing/self-organizing team and there are reasons why you might want to do that. But that is not the only organization structure for satisfying these needs. The underlying principle is:

Devolve authority, pushing authority downwards. Decentralize decision making

Whether you devolve a team as a whole, as in the self-organizing/self-managing model, or to individuals, perhaps to NCOs, the aim is to move the decision closer to the work.

Note: I’m avoiding the word 'empowerment.' See my: Stop empowering people - End disempowerment! post from last year.

Either way you do it, if you push authority down something else happens:

More people engage in management work

Yes, suddenly coders, testers, and analysts, who do not think of themselves as managers, now need to make management decisions. Even if this is done in the setting of a self-managing/self-organizing team, management decisions are still being made. Indeed, if the whole team makes the decision the whole team is engaging in a little bit of management.

Everyone on the team starts to take on management attributes.

More importantly, more people need management skills. The whole team needs some management skills and the intuition that makes a good manager a good manager.

Think about this for a moment.

Do team members want to go to meetings about management issues?

Do you C++ programmers want to engage in management?

If your Java programmers are now engaging in management, where do they learn their management skills?

If your Testers are making management decisions, how do they develop their intuition?

If you accept that management work is a skill set in its own right and you believe that more people should be involved in managing, then you have to ask: how are these people going to learn management skills?

Then there is another side to this…

Talk to any manager about what they actually do, not what they would think they should do, or what they like to be doing, but what they actually spend their days doing. You will hear them say things like:

  • “I’m constantly fire fighting.”
  • “I’ve got tons of e-mail to answer.”
  • “My phone is ringing all the time.”
  • “I never get to do strategy.”
  • “I never get time to think or plan.”

One of the characteristics of management work is that it is inherently interrupt driven. (If you don’t believe me go read Henry Mintzberg’s Simply Managing book.)

By involving programmers, testers, analysts, etc. in management, we are also opening these people up to interruptions. People will interrupt…potentially any team member!

Now if you are a programmer, tester, analysts or what-not, please ask yourself: Do I want to be interrupted? Am I willing to take the downside of management?

I’ve known plenty of programmers who would definitely answer “No!”

(There is a twist here. Mintzberg also suggests that managers choose to be interrupted. Which could imply that teams could choose not to inflict interruptions on team members but that is not entirely in the team’s control. What Mintzberg doesn’t say is how many of the interruptions would be avoidable. Do managers choose to be managers because they are interrupt driven in nature? But we digress.)

Lean folk will spot that there is a question of variance analysis here: Management work has a greater variance than programming or testing and therefore needs to operate on a different cadence. The queues are different. From a lean point of view, it makes sense to separate these two types of work because they have different variance and cadence.

Now here is a question.

If management requires skills and intuition (both of which need to be built in a person) and if doing management results in an interrupt driven work pattern, then is management better while...

a) Centralized in a few people who can be trained in the skills, who develop their intuition and who are tasked to handle interruptions, thereby leaving the majority of the team to focus on technical skills and un-interupted work (hopefully achieving flow)

b) Dispersed with everyone having some management skills (at the cost of technical skills) and some interruptions (at the cost of flow)

c) Other, please specify

For me the answer is (a) but…

If management is centralized it then becomes a question of how centralized? Over-centralization results in the model we see all too often, with decisions delayed and taken by people with too little knowledge. The result is depressing and demotivating for those at the code-face. 

But if management is organized as a hierarchy of managers, then they make work for one another and some decisions end up traversing the hierarchy. So answer (a) is not perfect. This might be another example of dis-economies of scale

Which brings me back to non-commissioned managers: I would like to see more people with more management skills embedded closer to the work and working co-operatively within a team. An impure self-organizing model if you like.

Any which way, there is no perfect answer. It is about balancing forces.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

management,agile management

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}