My personal view is NO.

It needs DevOps for sure, but not DevOps managers.

There is a simple explanation and a more well defined, elaborate explanation to this question though.

The simple explanation first. A Manager's role needs to be associated with some outcome. A Project Manager - is responsible for the outcome of successful project, a Business Manager - is responsible for the outcome of a growing and profitable business, a Service Manager - is responsible for delivering improved service, etc. Devops is not an outcome. It's a means to an end - that end being continuous delivery.

Does this mean I am okay with a Continuous Delivery Manager instead of a DevOps Manager? Technically yes. If continuous delivery is the only desired outcome. Typically it is not. The desired outcome is the predictable and 'on demand' delivery of new functionalities from applications and systems without compromising their architectural integrity and stability. So I would prefer a Product / System / Application Manager rather than a Continuous Delivery Manager. But any of these instead of a Devops Manager for sure.

In fact, DevOps is pushing us towards a state where we need to ultimately collapse the role of a Project Manager and an Ops Manager into one role - a Product Manager. This manager is responsible for the continuous development and delivery of this product - a cradle to grave ownership opposed to the temporary project ownership and intermittent ops ownership. That's a true Devops state - there is no handover - all belongs to the same team. In fact, a more evolved role is that of a Service Manager who is responsible not just for service delivery but all the product delivery which enables that service.

So, a DevOps Manager is a no no. Assuming that its responsibility would be to facilitate collaboration between Dev and Ops, in my view it will end up complicating the situation further.

Let me elaborate.

We start with the basics. What does a manager do?

As per Drucker (from the book Essential Drucker) 'knowledge, especially advanced knowledge, is always specialized. By itself, it produces nothing. Yet a modern business, and not only the largest ones, may employ up to ten thousand highly knowledgeable people who represent up to sixty different knowledge areas. They all work together in a joint venture. None would be effective without the managed enterprise'

My simple definition of a manager is one who integrates the expertise of multiple experts to provide an outcome which those individual experts could not have achieved alone.

Can't the experts do this on their own? They can but if the team is too large and there are too many different experts involved, the coordination and communication overhead can be very large too. This is when we need somebody - somebody who is not an expert in any particular area but knows enough about all to decide which experts need to talk, what communication need to be passed among them and somehow orchestrate these different streams of work towards a common goal.

Integration and orchestration is the key function which the Manager plays.

Should the manager be an expert himself? Only if that helps him to better appreciate the challenges of the experts which then enables him to be a more effective integrator. That is the reason why managers evolve into that role from being an expert. But unfortunately for many of them that evolution is more hierarchical rather than functional. They still keep relying on their 'expertise' skills rather than develop new 'integration' and 'orchestration' skills.

However, in trying to integrate and orchestrate does the Manager sometimes infringe upon the creative freedom of the experts? Does he stop trusting their judgment? Does he sometimes forget who the expert is and muddles the demarcation? Does he start assuming absolute control over the expert 'resources' and expects strict adherence? Does he shield the big picture from the team and expects them to focus on their piece of the puzzle? More often than not, the unfortunate answer is yes.

If you read Agile literature, you'll realize that the reason Agile in general and Scrum in particular promotes the role of a Scrum "Master' rather than a Manager is because the latter often oversteps his authority and mandate. The effect on the experts is disastrous. They feel 'controlled' with no motivation left to appreciate the overall objective of the venture they're part of and confine themselves just to do what they're asked to do. This is the beginning of the 'silo' mentality - the very mentality Devops is supposed to eliminate.

If you look deeper to understand the silo between Dev and Ops, you'll observe that the silo gets deeper as you go lower in the hierarchy - it's not so deep at the Dev and Ops management layer.

So, the point is that IT Management need to look themselves in the mirror and assess the degree to which they have contributed to this chasm between Dev and Ops. They need to step back from their command and control approach to a far more 'watch from a distance and protect' approach. They need to empower the 'experts', allow them to mingle, interact and collaborate, show them the big picture, assert confidence in them to solve the big problems and create a win-win platform.

There is a brilliant book called 'Management 3.0' written by Jurgen Appelo which delves into this subject deeper. A must read for all IT Managers and everybody else who is working towards this grand vision of perfect collaboration - as epitomized by Devops.

Coming back to our original question then. Do we need Devops Managers? Absolutely not.

Do we need IT Managers at all? Of course, yes. Managers, who can lead, empower and motivate, not the ones who only manage.

• Craig Ferguson Answers the Most Important Question in the Network Television Premiere of "Craig Ferguson: Does This Need To Be Said?" Debuting Saturday, October 15 at 10:00 P.M. ET/PT on COMEDY CENTRAL®
• Developing a New “Service-Centric IT Value Chain”
• Research and Markets: Saving Cash: RFID - What does it bring to the table?