For many, redesigning the operating model is table stakes for a successful DevOps transformation. But have you ever wondered why? Popular wisdom will have you believe that the main reason for operating model redesign are to…
“Improve collaboration between business and IT”
“Realign metrics”
“Take full advantage of the new tools”
“And even jump start culture change”
While these are all good reasons, frankly they miss the point. Experience suggests there is a more practical reason – match ownership with desired output.
What do we mean by that? Well first, lets look at how the current model works.
There a no real owners in IT
DevOps is about optimizing the flow of work across the Software Delivery Lifecycle. But who owns this end to end flow – idea conception to release? Who owns the cycle time? And who it responsible for improving it?
The short answer is everyone. Business, architects, and engineers own the planning phase. Developers own development and testing. Operators own releases. The PMO owns the project plan. And the business owns the funding.
And yes in theory all of these groups are supposed to get along. Unfortunately it rarely happens. Incentives and metrics force them to optimize their silos but not the overall flow. the current operating model encourages tribal siloed mentality. It’s the reason why finger pointing is elevated to an art form and “CYA” is your ticket to getting promoted.
One can argue that the CIO does own it all. But, in my humble opinion, CIOs have to tend to hundreds (if not thousands) of applications. Making it impossible for them to play an active role on a daily basis.
Which brings me back to my earlier point…having too many owners is just as good as having no owners. Rectifying this misalignment is the main reason why so many CIOs choose to change the operating model. Even when it may seem risky at the onset.
In fact many have found that fixing the ownership problem actually accelerates the DevOps transformation.
If you want to make dramatic progress create a single owner for each application
There are lots of names for this type of operating model. Some call it a product model, others call is squads, IBM calls it cell. But the essence is the same – for every application, create a single owner, that manages a cross functional team, has end to end authority, and is measured on business outputs.
This owner is responsible for the entire delivery lifecycle. They manage both the inputs (resources, process, tools, infrastructure etc.) and the outputs (business impact, features, time to market, quality, productivity etc.).
This does four things. First, managers that are the most familiar with the application and its users can now finally optimize the inputs in order to maximize the outputs. Second, by pushing authority to the front lines, you create a sense of true ownership. Pride (or shame) are powerful motivators for quality.
Third, by decoupling the teams you get rid of bureaucracy, give rise to friendly competition, and localize the risks. And fourth, the reason why most CIOs go through with the change despite the risks, it provides you with a one throat to choke.
You can, of course, continue to implement DevOps in the current operating model. But it’s almost impossible to overcome the operating model inertia. A move to a product model can actually accelerate your transformation. The model serves as a catalyst for the organization move past the “old way” of working in silos and create “new ways” of working with the flow.
Create your one throat to choke and see how quickly things change.
