Editor's Note: The chapter, "Kill the Restructure" is included in Epic Failures in DevSecOps, Volume 2, which is available for free download.
We see too many enterprises assuming one of the first steps of DevOps is a reorganization. DevOps isn’t about org structures. -- Dr. Cherry Vu
Interview with Dr. Cherry Vu and Rob England, with host Justin Miller.
Excerpt from the Chapter 9, "Kill the Restructure" from the book Epic Failures in DevSecOps.
Work is a complex system. It’s an organic soup of attitudes, beliefs, behaviors, mood, vision, personalities... There are no crisp inputs and outputs, just energy and activity in a network. You don’t know how to change it. Nobody knows, no matter how much you pay them. Stop pretending that anybody knows what an optimal organizational structure is until they’ve tried it. It is a patronizing, even arrogant, fallacy that anyone can know what a better structure is in advance. It’s the nature of complexity. We can only experiment in increments. Structure must be emergent, not imposed.
Similarly, culture is an emergent property of the complex work system. It is an output not an input. Change the attitudes and behaviors, then that becomes culture. Culture doesn’t come in a tube to be inserted. What’s more, we managers/ consultants can’t change culture. The community has to change itself, and want to do so. We can only change the conditions under our control and see what effect that has, then see what culture emerges. And that effect is unpredictable. Again, nobody knows. You have to suck it and see. Hence small steps.
For Example
Look at DevOps as an example. The point of DevOps is to span silos, not to change one set of silos into different ones. Changing from North/South slices into East/ West slices are still slices. We see too many enterprises assuming one of the first steps of DevOps is a reorganization. DevOps isn’t about org structures. You can organize into functional technology silos with virtual product teams, or into product teams with virtual technology functions and guilds. Either way it is a matrix.
Most legacy enterprises are organized into functional teams. Although the current preference is for a product team instead and there is an argument that a team should stay together over the long term, the reality is that the size of the team will grow and shrink over time as the volume of change in the product varies. Therefore only a core will be constant anyway — the teams need to be fluid. So there is no downside to them being virtual teams taken from functional groups.
Moreover, the future is product teams brought together from multiple departments, not sourced exclusively from IT — someone from marketing, product design, digital design, shadow IT teams, third party suppliers, vendors. All the more reason for them to be virtual.
Your internal IT technical teams may want to regroup as providers of platforms, automation, tools, security etc, but there is no need to rush into that either until you understand exactly how it will work in your enterprise.
Get the DevOps working first, then a reorg may be an optimization. When DevOps makes your people realize they need to restructure, then it is time. Pull not push.
Read the full chapter when you download the book.
