It's the system, st*pid
Heard in the course of doing the interviews at the start of an engagement:
-
The ops folks just make up things to do, they don’t want to help the developers - a senior developer (my personal favorite)
-
My product is the most important product for the business and the ops people are lazy and always working on the wrong things - a development manager
Working with portfolio companies over the years, you can imagine I’ve heard a number of comments like these. This is especially common when there have been a number of add-ons. I tend to work with the ops teams because they are such a high leverage part of the organization, and as such, they are also usually the ones who are blamed when developers are not happy.
In each case I’ve been able to assure these folks that while a good story, after meeting with those blamed, it was most certainly not the case. The truth is, it’s the system that creates these perceptions, not laziness or avoidance of work.
I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this:
- 94% belongs to the system (responsibility of management)
- 6% special
-W. Edwards Deming
-
In the first case, the ops folks were assigned to support multiple products, without any direction from management as to priorities. This resulted in a situation that no matter what they prioritized, they were 100% guaranteed to lose, because everyone else would be upset.
-
In the second case, the ops engineers were instructed to prioritize putting out fires, not helping development teams. They were certainly busy, but not in a way that was meaningful to the dev teams they were supporting.
The solution is often to heed the words of Deming. The engineers themselves cannot change the system and create the “improvement”, that is the responsibility of management. The engineers can never meaningfully move that needle. In these cases, and cases like these, management has to change the dynamics of the system so the developers feel supported. Sometimes that means changing priorities, sometimes that means shifting resources, sometimes that means moving integrations faster or retiring marginal products, sometimes that means reorganizing the entire system so engineers are able to focus instead of being pulled to and fro.
I see this often with portfolio add-ons. Years later, they are still operating as distinct entities. I often have “crucial conversations” with management about bringing the whole company into the same system, limiting the number of options. Laying the blame at the feet of individual engineers is pointless, they cannot change the system to affect the outputs. When management buys in, and the engineers get on board, amazing change happens.