Does DevOps Make Sense for Large Organisations? By Kris Saxton

DevOps is a new organisational model which attempts to better connect workers with the users of their products and services by foregoing the traditional grouping of people by function for a grouping by product or service.

Anyone who has worked in a ‘tiger team’ or some other kind of task force, where people are drawn from different parts of an organisation to achieve a specific goal, knows what DevOps is.  Unlike these temporary teams, DevOps seeks to make that reorganisation permanent.

This article sets the DevOps movement in a broad historical context of competing organisational models, highlights some of the strengths, perceived weaknesses and trade-offs which a CIO must weigh up when deciding whether a DevOps approach makes sense for them (spoiler alert: it depends on what you mean by efficient).

First, let’s give DevOps some historical context.

Any conversation about modern organisational models has a natural starting point with Henry Ford.  Sure, we can go further back, to the East India Company or even the Knights Templar, but it was in 1920s America that Henry Ford, with his idea of an assembly line fed by highly specialised workers, that gave us the structure of the modern global corporation.

Although it is Ford and his assembly line that is most remembered, it was actually his right-hand man, Alfred Sloan, who has had more of an impact on how we organise ourselves at work today.

To support Ford’s growing industrial empire, Sloan organised the motor company into nested layers of workers, grouped by functional specialism and joined by management reporting.  This grouping enabled Ford to scale to become the first modern global corporation and it is in this shadow of siloed specialisation that we still work today.

DevOps seeks to unpick some of the negative consequences of siloed organisations, but the idea that this structure may be problematic and distance people from the core purpose of the organisations in which they work is not new.

Matrix Management

Matrix Management, introduced in the 1970s was an attempt to better connect workers to the underlying purpose of the organisations in which they work by creating a management layer oriented to a business area or product line and overlaying this onto the existing management structure, the one focused on their functional specialism.

Though the goal was both noble and very similar to DevOps (a closer connection with the customer) staff subject to it complain of confusion and frustration from unclear priorities and competing agendas between the two management layers.  Despite a bad reputation, Matrix Management (much like ITIL and Psychoanalysis) is alive and well, with practitioners producing revised guides and blaming failures on poor implementation.  For my part I have never worked under a Matrix Management structure, but Automation Logic does work with very large organisations who do, and I’ve never heard anyone speak well of it.  I see Matrix Management as a flawed attempt to reach the same goal as DevOps.  It is flawed for two reasons, firstly it is a bureaucratic response to the problem which focuses on the ‘matrix’ (i.e. the structure and process) rather than the people subject to it.  Second, it is additive, and if the bureaucracy is a substitute for competence (and it is) when did adding more bureaucracy ever improve anything?

Enter DevOps

Fast forward another 50 years and DevOps is the latest attempt at reorganising ourselves in the name of better customer alignment.

At its heart, DevOps is very simple: DevOps is an organisational model where people operate in teams arranged around a product or service instead of a function or specialism.

Born into the same revolutionary family, DevOps is often confused and conflated with its siblings Agile and Digital Transformation, so let’s take a moment to define and disambiguate:

The goal of DevOps is to get a valuable change delivered to a user more quickly and DevOps does this by gathering all the key stakeholders within a “value chain” (generally a software product or service) and organising them into a single team.  This team then has the singular goal of getting the most valuable change delivered into the hands of its users as quickly and safely as possible.

This makes DevOps an enabler of Digital Transformation (where the valuable change is a new software product or feature), although just “doing DevOps” doesn’t make you “Digital”.  Also, because DevOps seeks to increase speed by breaking down functional silos and their related processes, it borrows heavily from Agile which seeks to prioritise “individuals and interactions over processes and tools” and “working software over comprehensive documentation”.

This is also a good point to compare DevOps to Matrix Management, both have similar goals but DevOps’s Agile roots make it subtractive in nature; DevOps seeks to strip away bureaucracy and rely instead on trust, competence and face to face communication.

Where it gets interesting is when we compare DevOps to Ford/Sloan’s functional silos (let’s leave Matrix Management here and never speak of it again) as both profess to have efficiency at their heart, and they can’t both be right can they?

Well, like all good engineers know, in order to call something efficient, you first have to know what you are optimising for.  DevOps and Ford/Sloan are both efficient but DevOps optimises for speed of delivery whereas Ford/Sloan only cares about resource efficiency (cost in other words).

Conclusion

DevOps presents a conundrum for the CIO in that it compels her to move to a potentially less resource efficient organisational model in the name of speed and agility.

She must ask hard questions of herself about which of these two competing goals (Note that reducing cost AND enabling digital transformation are consistently cited as in the top three concerns of CIOs) is more important.

If its reducing cost, then a focus on reducing hosting costs through public cloud adoption and increased efficiency through task automation may deliver the best bang for her buck.

If it’s speed, then DevOps is the way to go.  There is, however, a compelling alternative narrative, one that could allow her to have her cake and eat it?

What if DevOps produces some unexpected costs efficiencies through a simplification of process and a reduction in bureaucracy?

I’ll cover this in a future article.  Stay tuned.