DevOps Culture Anti-pattern: Centralized Decision Making

“It is better to ask for forgiveness than permission.” A statement like that is pervasive in an organization that follows a decentralized command and control structure. As organizations become more complex, it is nearly impossible for any single person to fully capture detailed information in making decisions. Yet, many companies still try to run significant decision making authority through single threaded resources.

The complexity of organizations that grown beyond a certain threshold cannot be managed in the same manner as a startup or small business. In the great words of Lean Enterprise:

First, there is no privileged perspective from which the system as a whole can be understood-not even the CEO’s office. Second, nobody can hope to understand more than a small part of the whole, depending on the information and context available to them.

By forcing decisions to be run through single resources, teams create an artificial choke point for the flow of work that limits growth and leads to mistakes. Even if some strategy is set with an upper management or leadership role, the “how to implement” of tactical decisions should be pushed as close as possible to the day to day work that is occurring. For organizations facing the challenge centralized decision making, these type of issues can crop up:

  • All cross functional work must be run by “someone’s manager” before engaging.
  • Arbitrary reprimands can occur when non-managers act on their own accord without consulting management on decision making.
  • Supervisors and managers are viewed as ruling by an “iron fist” and fear abounds.
  • Senior level contributors may “hoard” information in order to force management to rely solely on their expertise.

There can often be fear of ones job in an environment like this. When decision making power is removed, the feedback cycle required for one to advance their career and skills is limited. To combat this problem requires an increase in trust in people.

I have dealt with this decision making scenario from both a doer and decider perspective. I have found most success when I have proven that my knowledge about a problem and process and the information I have available to me shows that my team is well positioned to respond to a situation. Whether we have a monitor alert, a client request, or other team request, I ensure my team has the information they need to not have to call someone just to ask what to do. I trust the judgement of those around me to decide on the best course of action.

And in the situations where someone does not want to give up the control of that particular deicing function, it has required wresting away the control by creating documented decision trees with specific inputs and outputs that can be shared with a wider audience. I have had to sit down with someone for a couple of days to extract all the details that went into deciding how to respond to a particular client issue and charted out all sources of information used to determine next steps. It was an effort to ease the burden of deciding power and lower the stress one person felt in having to deal with the many phone calls and emails associated with a problem.

If someone is stagnant in their career, often times it is a symptom of work that cannot be shared because they hold all the keys. Being handed new, more interesting responsibilities is impossible if your plate is full of other, older ones. Some tasks, including the decision making around those tasks, have to be handed off in order for growth to occur.

See more of the DevOps Culture Anti-patterns here: