Command-and-Control in organizations seeking agility

Jul 01

Command-and-Control in organizations seeking agility

In playing the roles of Agile Coach, Developer and Engineer throughout the years, I have come to appreciate the importance of power balance whenever two or more people are interacting. Power is most clearly visible when expressed loudly by mangers who use their position in a hierarchy to get their way, regardless of what others think, say or prefer; in this sense, managers are “powering over” the voices of the people under them 1.

What is Command-and-Control?

Command-and-Control is the systematic implicit or explicit support of power-over tactics present in an organization.

In the context of software development, “Command-and-Control” refers to the tendency of managers/leaders to tell people what to do, using their title or position in the organizational hierarchy to demand action; the unspoken, yet implied message is that there’s some form of punishment assumed if compliance is not forthcoming (e.g. Threat of no raise, no advancement, reassignment or firing). While Command-and-Control might be a good way to run the military, it isn’t necessarily a good way to develop software because knowledge workers2have lots of options in today’s market.

The Agile movement, inspired by the Agile Manifesto values and principles suggests a more effective way of developing software:

  • By valuing “Individuals and interactions over processes and tools.”
  • And valuing “Customer collaboration over contract negotiation.”
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Why doesn’t Command-and-Control work in Agile teams?

Command-and-Control doesn’t work in Agile teams because smart people prefer having the autonomy to make choices on how to do their jobs and how much to take on. Because developers are educated, and often have multiple degrees and certifications, it they’re not happy, they find other jobs. Command-and-Control can work for a short time, but is generally not sustainable because developers burn-out trying to meet their bosses unrealistic goals3.

The real cost is the loss of trust, shared responsibility and collaboration within the teams — the potential for innovation and long-term business value is exchanged for the short-term deliverables.

What are some symptoms of Command-and-Control?

  • developers are not working at a sustainable pace — I.e. lots of overtime, lots of sick time, some burn out, and high turnover
  • people are scared to be honest; there are lots of “us vs. them”
  • there’s a lack of trust, openness and transparency; in extreme cases teams hide the truth from various stakeholders
  • there is a lot of process waste (meetings or activities that have no business value, such as excessive documentation, weekly PowerPoint slide creation, etc)
  • there is more than one project manager in a project
  • there’s lots of debate regarding the sizes of features/user stories outside of the development team
  • the anti-pattern of comparing team velocities is prevalent
  • in extreme cases, bosses of various flavors yell at underlings to get things done their way
  • traditional hierarchical titles are given priority over Agile roles
  • technical debt shows up early in the life of the product, as teams are pressured to take on more work than their real capacity can support 4.

How to grow out of Command-and-Control?

“We cannot solve our problems with the same thinking we used when we created them.” — Albert Einstein

As Einstein’s quote suggests, you can’t force someone to change out of Command-and-Control through the use of Command-and-Control because you end up getting more of the same Command-and-Control. While training can be promoted by higher-ups, real change must come through personal growth because it represents a paradigm change. While it helps to have leaders model the collaborative behavior they’d like to see, organizational culture changes through the collective decisions of individuals to change.

Evolving a culturally inherited paradigm can’t be done simply by issuing orders, thinking about it, by reading a book, getting Agile certified or going to a workshop. Shifting out of the paradigm of Command-and-Control into “Power-With” collaboration requires lots of individual personal commitments to developing self-awareness, and getting lots of help from others who have traveled the road before (e.g. Getting the help of coaches, trainers, therapists, mentors, recovery groups, etc).

I’m a firm believer in a plurality of paths toward solutions, as evolution is about experimenting and collectively learning. The empathy journaling process of my previous post, along with training in Nonviolent Communication has supported my journey into the “Power-With” collaborative paradigm5.  I’m curious to hear about other effective strategies for change. Would you be willing to post them here?

Leave a Reply

Your email address will not be published. Required fields are marked *

Pin It on Pinterest

Share This