Welcome!

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

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
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DevOpsSUMMIT at CloudEXPO, to be held June 25-26, 2019 at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real results. Among the proven benefits, DevOps is correlated with 20% faster time-to-market, 22% improvement in quality, and 18% reduction in dev and ops costs, according to research firm Vanson-Bourne. It is changing the way IT works, how businesses interact with customers, and how organizations are buying, building, and delivering software.
The benefits of automated cloud deployments for speed, reliability and security are undeniable. The cornerstone of this approach, immutable deployment, promotes the idea of continuously rolling safe, stable images instead of trying to keep up with managing a fixed pool of virtual or physical machines. In this talk, we'll explore the immutable infrastructure pattern and how to use continuous deployment and continuous integration (CI/CD) process to build and manage server images for any platform. Then we'll show how automate deploying these images quickly and reliability with open DevOps tools like Terraform and Digital Rebar. Not only is this approach fast, it's also more secure and robust for operators. If you are running infrastructure, this talk will change how you think about your job in profound ways.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.