The Organizational Death Spiral
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.
The Story : Shifting Priorities
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.
The Reality : Context Switching
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 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.
The Problem : Unstable Delivery and Unstable Priorities
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,
The Solution : Iron Will
To stop the madness, the right people need to get into a room and declare “we are only doing the single most important and 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 recognize you have to get off the crazy wheel of shifting priorities and context switching that is impacting poor priorities, in turn impacting poor delivery.
What about you? Have you noticed that priorities and delivery BOTH impact each other?
Comments (4)
Anonymous Coward
So … you mean to say that if you’re spreading yourself too thin you’re going to fail, eventually?
There’s a nice book, also published online, by the nice ppl at 37signals, simply called “Getting Real” – easy read. The book says, among other things, that when you’re short on resources you should deliver half a product, not a half-assed product. Seems to me advice int he same direction …
Anonymous, thanks for the comment. I love the “Getting Real” book. Very interesting points on when to scale and not to scale an operation.
Anthony Green
“Conway’s Law, which tells us for our vertically aligned business and technical capabilities to be truly successful we must also re-structure our organisation so that our development teams are vertically aligned with singular responsibility for specific business capabilities.”
– Steve Smith
http://www.alwaysagileconsulting.com/application-pattern-vertical-divide-and-conquer/
Santosh pawar
For the iron will the leaders really need to know the ground realities and have solid metrics monitoring them. The middle management is made responsible for failing projects and left insecure which makes them them to show a green picture till its too late. This causes the spiraling effect go at a higher rate under cover.