The Organizational Death Spiral
The Organizational Death Spiral
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
I’ve seen a pattern at a number of companies recently. It’s a pattern that demonstrates the danger of doing too many things at once. I call it the organizational death spiral.
Let’s say we have several product delivery teams in our organization, and that senior leadership have identified a handful of strategic initiatives that that are our next immediate priorities. Furthermore, let’s also assume that the estimates for each project add up to where we should be able to get them all done during the next quarter. Then we go upon our merry way building new products and services, just as management asked us to.
However, we know that challenges happen. For example, most companies simply are not organized into purely independent teams that can churn out products all by themselves. There’s almost always some kind of dependency on another team for those design specs, or some technical team for that fancy component, or some compliance team for full end-to-end behavior. Inevitably, this means at least a few teams have to shift their local priorities around on a regular basis in order to get anything done.
The problem is that juggling too many things at once decreases our focus, and slows down productivity. This is phenomenon is called “context switching”. There’s a ton of literature out there about how it slows down delivery, and makes us less predictable on delivering on deadlines.
As a result, product leaders are frustrated. We miss a date, which means we miss a market window, which means that project X is no longer worth the investment. So, leaders do what any mature leader should do: they kill the project, and replace it with project Y. It makes perfect strategic sense.
However, as soon as we make that change, we suffer more context switching and more delays in getting work done. Delivery teams become even more fragmented and even more frustrated (“Those executives keep changing their minds. They’re not committed to the long term and are only interested in the latest shiny object”).
After more project delays and slipped delivery dates, management decides “If we can’t get any one thing done on time, then we should work on everything at once.” Which leads to more fragmentation and context switching, which leads to poorer delivery.
…and it goes on…and on…and on.
Delivery organizations often assume that its all the product leadership’s fault for having shifting priorities. Meanwhile, leaders assume it’s all the fault of engineering, or IT, or service delivery for not organizing the work properly to get things done. The heart of the problem is that both organizations are interdependent. Specifically,
To stop the madness, the right people need to get into a room and declare “we doing only the single most important, top-most critical item right now. Then, with whatever extra capacity we have, we are going to repair our delivery organizations to handle more.”
It takes courage at multiple levels in the organization to do this. It requires that admission that we have a problem, and the iron will to do whatever it takes to fix the underlying disconnect between expectations and delivery against those expectations. Maybe you need to reallocate skillsets into different teams. Maybe you need to invest in fixing a quality problem. Maybe you need to implement a disciplined portfolio management competency.
But whatever medicine you take, the first step is to reconize you have to get off the crazy wheel of poor delivery impacting poor priorities, in turn impacting poor delivery.
What about you? Have you noticed that priorities and delivery BOTH impact each other?
Published at DZone with permission of Mike Cottmeyer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.