Welcome!

@DevOpsSummit Authors: Liz McMillan, Yeshim Deniz, Zakia Bouachraoui, Pat Romanski, Elizabeth White

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Article

DevOps Managers? | @DevOpsSummit #DevOps #IoT #ContinuousIntegration

Managers need to move beyond managing

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.

More Stories By Sujoy Sen

Sujoy is a TOGAF Certified Enterprise Architect, a Certified Six Sigma Black Belt and Manager of Organizational Excellence from American Society for Quality, a PMP, a CISA, an Agile Coach, a Devops Evangelist and lately, a Digital enthusiast. With over 20 years of professional experience now, he has led multiple consulting engagements with Fortune 500 customers across the globe. He has a Masters Degree in Quality Management and a Bachelors in Electrical Engineering. He is based out of New Jersey.

@DevOpsSummit Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might slip up with the wrong focus, how to manage change and risk in all three areas, what is possible and what is not, where to start, and especially how new structures, processes, and technologies can help drive a new DevOps culture.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regulatory scrutiny and increasing consumer lack of trust in technology in general.