DevOps: What’s in it for managers?

DevOps, we hear, is all about empowering teams: Cross-functional teams of engineers, testers, operations, security people. They get to be augmented, more capable, and more successful. They can manage their time, work out what needs to happen, and agree on project goals.

So, what’s in it for managers? The answer is simple. If your organization works on a model where managers are incentivized to build large teams, set specific short-term targets, micro-manage their resources, and just keep accruing larger and larger budgets, then the adoption of DevOps will be an overwhelmingly negative experience for them. They will fight against it, refuse to assign their team members to DevOps projects, and, when pushed into doing so, will attempt to stop them from participating fully in the DevOps process and generally find ways to be obstructive.

DevOps and a classic command-and-control management structure do not mix.

Why is there such a poor alignment between this style of management and DevOps? Surely there is a place for managers in this brave new world? The answer to that last plea is, of course, yes, but in order to understand what that place is, let’s address the mismatch.

[ Want more advice from your DevOps peers? Read DevOps lessons learned: What I wish I knew sooner. ]

A big change: Fluid assignments

First, look at what DevOps is trying to achieve. DevOps, though somewhat distinct from the agile movement, shares many precepts with it, and can be thought of as an extension or further building on top of agile. Certainly, most DevOps practitioners would describe themselves as agile practitioners, even if they do not follow pure agile methodologies. The basic idea behind DevOps is that “if you build it, you run it”, but that is somewhat simplistic. As a statement, it implies that your software engineers now manage your entire test infrastructure and operational deployment - and it ignores other important parts of the DevOps cycle, such as design, as do many definitions of DevOps.

A better description might be that all the various parts of the cycle employ agile methods and that all members of the team are engaged in all parts of the cycle, albeit to varying degrees.

The most obvious impact that this has on managers is that their direct reports can no longer have carefully defined and prescribed assignments for particular phases of a project.

With no “design” phase, “development” phase, “testing” phase, and the rest - or, more accurately, with there being multiple iterations one after the other - the way in which direct reports are assigned needs to change. Teams need to form around the project, and there is likely to be a significantly stronger center of gravity around that project than around the manager to whom each person reports.

The good news

There is good news, however. For those managers who are interested in building their reports’ capabilities and skills, coaching those for whom new ways of working can be difficult, and liaising with other teams and departments when difficulties arise, DevOps offers many possibilities.

Rather than thinking of your team, there is an opportunity to think of your team.

Up until this point in the article, I’ve talked about reports, rather than team members: this is intentional. Although it is, of course, possible to build a team from a set of reports in a classic non-agile, non-DevOps world - and the best managers do - in order to make a reporting structure anything more than just that, reporting, there’s a need to build a shared sense of purpose.

That may be around a functional or geographic grouping, or some other structure. In any case, using the reporting structure to provide opportunities to share experiences will not only develop your reports - your team members - but also work to spread good practices between the projects in which they are deployed.

There are other opportunities for manager involvement as well. Actual involvement in DevOps projects as a team member may be possible; there is a place for managers to use their experience and expertise of the organization to work with other departments and functions to smooth over problems that arise in their team members’ projects. You may also recognize what issues are on the horizon before they arise and intervene to free up logjams, improving the odds that projects will succeed.

This shift in thinking cannot happen if executive management just signals that DevOps is “now the way to go” without acknowledging the many cultural changes that it requires, managerial style being a top one.

Managers must be encouraged to move from a culture where they are rewarded for growing and maintaining a large set of reports to one where they are measured and remunerated when they develop their team into one where the members are expected to move, and mobility in and out of the team is seen as a positive…specifically, where people move in and out of various reporting structures, with their first loyalty not to the manager, but to the projects and the organization. This is a big change, but it is one which will eventually lead to a happier, more productive and more valued team, and one which will lead to better, more effective, and more valued managers.

[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]