How many IT people does it take to produce an application? Actually, let me rephrase that. How many IT people does it take to produce an application effectively and efficiently? For many organizations, the answer to the second question is less than the answer to the first because the traditional IT hierarchy includes layers of middle-manager decision makers that weigh everything down.
One of the things that DevOps helps companies accomplish is to eliminate unnecessary bureaucratic obstacles so the people trying to get things done can just do what they know how to do. The traditional IT model reminds me a little of putting a police officer in the middle of an intersection to direct traffic when there are already stoplights or stop signs present. Every licensed driver already knows the proper protocols and procedures for driving collaboratively and sharing the road so that everyone gets safely through the intersection. The police officer just disrupts an otherwise smooth process, and wastes resources that could be put to better use elsewhere—like maybe pulling over that car going 75mph in a 45mph zone, but I digress.
For some reason, it is a fairly normal, natural evolution for a business to add layers of middle-management decision makers as it grows. Sometimes those roles are a function of wanting to promote people when there is really nowhere to promote them to, and the role makes sense at the time. In fact, the initial creation of many such roles is actually intended to help the business operate more efficiently. An upper manager starts to get too much on his plate, and delegates power to intermediaries so that decisions can be made at a lower level, and the upper manager’s lack of availability doesn’t become a roadblock to progress.
Over time, though, middle managers become a cancer on the organization. The need for the role typically fades away, and you’re left with people in unnecessary roles going out of their way to justify their own existence by asserting themselves and making sure everything goes through them. When big companies like Microsoft or General Motors decide to pare down the company, middle managers are generally first on the chopping block because nobody can even explain why they’re there in the first place.
That’s where DevOps comes in. By its very nature, DevOps enables teams to function more autonomously and take responsibility for their own work. It accomplishes the same goal that originally justified creating middle-manager roles—it moves decision-making power to a lower level so that scarce upper managers don’t become obstacles for productivity. DevOps does it by bringing decision-making power down to the trenches where those involved understand what they’re doing and why they’re doing it, though, rather than adding an extra layer of red tape that ultimately ends up adding, rather than removing obstacles.
Like drivers approaching an intersection, the people doing the actual work have a firm grasp on what’s supposed to happen. They understand how things work, and what needs to happen to get things done. The traditional middle-manager hierarchy is like the unnecessary police officer “directing” traffic, while a DevOps approach treats the drivers like sentient adults, and assumes they all know what a stop sign or a green light mean without being told.
In the end, it may add to our employment challenges. The US is already experiencing a shift away from manufacturing jobs as a result of technology and automation making workers obsolete. If we also decide collectively that middle managers are obsolete, we end up with more people without a job. That is unfortunate, and it is a problem that will need to be solved, but businesses can’t solve it by creating unnecessary roles just to give people something to do.
For younger organizations that have embraced DevOps concepts since inception, DevOps should help prevent the cancer of middle managers. If teams and individuals are given responsibility for themselves, there is no need to create an additional babysitter role to police them. For established organizations that already have middle managers, eliminating those roles creates a natural vacuum where DevOps concepts can flourish if allowed.
Regardless of how organizations get there, the result of embracing DevOps is that the middle-man is removed from the equation so development occurs more effectively, and more efficiently with fewer people.
This is so obvious … and so incorrect.
“Every licensed driver already knows the proper protocols and procedures for driving collaboratively and sharing the road so that everyone gets safely through the intersection.”
Actually, no. This is just along the recent common lines of there is to be no training for employees and no entry positions allowed. Sure, that just annoys the employees, but there is more reason this is silly. Have you ever heard of standards? Apparently you don’t like them. Only middle management can promote them and yes, they are important. The problem with your ideals is the shortsightedness. No, you don’t need middle managers… until you do. They are the long term employees that know what is going on and how to handle the unexpected. They smooth things over when a shock to the company comes like loss of a critical system or employee. They provide continuity. Someone has to take responsibility. Who do you want it to be… Oh, stake holders. Yah right, they never did before they were called stake holders and still usually don’t. Another thing middle management can do (and I have seen this repeatedly) is when upper management makes a mistake (and they do), it is only the middle managers that can compensate. I know of one company I deal with right now that made structural changes right before there was unexpected regulatory change. Now they need to undo the structural changes, but the moral is so low that recovery is difficult and they got rid of the expertise they need. There is no one that retained the knowledge.
The lesson of this article is the typical shortsighted philosophy that might provide short term success, but will risk long term pain or complete failure. No, Middle Managers are an unneeded pain, until you need them.
@Mike I have yet to see a middle-manager that is actually useful in any of the companies I have worked at. They are usually clueless about the actual work going on, they always lower the morale of the employees below them and they provide zero continuity in case an important employee leaves. If by “responsibility” you mean only speaking in grand words, my grandmother can do that too. It is always a handful expert employees that carry the whole burden. Here’s your typical middle-manager and don’t expect anything more from them: http://www.geekherocomic.com/2008/08/25/bob-the-manager/
I think you’re wrong but you got sort-of close. DevOps doesn’t eliminate middle management like magic. “Ooh, you have devops, so you don’t need middle management”. You have missed why middle management exists and how devops can reduce but not eliminate middle management. Middle Managers exist because the business expands. That’s why all managers exist. As the business expands, you need a manager to manage a group, not a big group, 4-5, more perhaps, depending on the specifics. Each middle manager does the same, he manages 4 or 5 lower level managers. Repeat until you get to the president who manages 4 or 5 VPs.
DevOps, theoretically allows you to reduce the number of front-line staff doing the work. That’s what reduces the number of managers. If 5 people with DevOps can do what 25 people can do without DevOps, then theoretically, you’ve cut 5 managers out.
However, unless your company is technology only and the company breathes IT and doesn’t do retail or customer support or manufacturing or anything else, you’re only going to cut managers out of one department. Which is generally good, but the world is not in any danger of needing to find new employment for millions of middle managers because every company embraced and succeeded at devops.