Are Your Lights On?
What is the real problem? Whose problem is it? Who has the power to fix it? and how do you motivate that person to fix the problem?
I am a big fan of Gerry Weinberg. His Secrets of Consulting is a great book. It is witty and insightful. This book is also very witty and insightful. It doesn't quite rise to the level of Secret's of Consulting yet it is still worth reading.
One of the biggest challenges of consulting and software engineering in general, is clearly defining the problem you are trying to solve and who exactly you are trying to solve it for. The answers to those questions are not always obvious. Daklu (Dave Snyder) on the Lava forums used to have a tagline:
The Power of Aligning Power and Pain
One of the lessons I took out of the book came up several times in some of my recent podcast interviews, such as these: Llewllyn Falco, Niko Naredi. It is the idea of shared pain or aligning pain and power. Often what happens is that someone in a position of power makes a decision that causes those of us at the bottom of the power ladder some pain. Generally, those of us feeling the pain don't have the power to change the decision. We can complain about our pain all we want yet to the person in power someone else's pain is hardly a good motivator. The real trick is to make that decision-maker share your pain. Then they are more likely to address it by rethinking or amending their decision.
The book gives a good example of this. The dean of some college decided to cut down on the number of parking spaces and raise prices for parking passes. The students protested and nothing happened. Then one student had a brilliant idea. The students all got together and took turns parking in the dean's parking spot. It didn't take long before the dean relented and created more parking spots and made the pricing more affordable.
How to share pain in a software engineering context?
Figuring out how to share the pain in software engineering can be challenging. A good place to look to is the DevOps movement, since that is what it is founded on. Pre DevOps, you would have separate developers and operations groups. The developers wrote the code. The operations group managed the production environment. They each caused each other pain. The devs would inevitably have some bugs in their code and the ops people would be the ones getting the call when things didn't work. The ops people would upgrade dependencies on a whim - because there is a newer version and it is more secure to be running the latest version - and it would break something in the code and the devs would have to spend time chasing down the problem. It resulted in a lot of finger-pointing and the problems never really got resolved. Once DevOps made the same people responsible for both Dev and Ops, then the finger-pointing went away and the problems got solved because the people feeling the pain were now also responsible for fixing the problem.
