Do you really have a problem?

In the last post I talked about change capital, a way to think about how many changes you can confidently make and which changes they should be. However, once you've decided where to make your change investments you need to think about how to implement the change.

Most changes are triggered by a perceived problem. However you need to keep in mind that not everyone thinks there is a problem worth solving - they may be quite happy with the current situation, see a different problem, or agree that there is a problem but not think it's worth solving. So your first step is to articulate the problem that you are trying to solve, and then form a consensus around the problem description.

If you're anything like me articulating the problem, even just to yourself, is a very useful exercise. It takes an intuitive understanding and transforms it into something a little more rigorous. It forces you to consider your terminology, establish some consistency, and gives you a chance to check your reasoning. Including quantification of the problem, answering how much this is costing you, can also be very enlightening - sometimes problems are very annoying, but don't actually cost you very much. If that's the case you might want to put more effort into quantifying the annoyance - does that have an economic cost as well? I frequently find that articulating and quantifying the problem forces me to acknowledge that there isn't a significant problem - at least no one worth investing my precious change capital on.

Even after you've convinced yourself that you've got a problem, you need to remember that not everyone else sees the same problem. Some people will probably agree with you, some people will see the same problem but won't think it's worth fixing (especially compared to other problems), and some people won't see any problem at all. And maybe they're right! Maybe there are benefits to the current situation that you haven't seen. Perhaps the benefits accrue to other people, so it's worth bearing the apparent pain. Maybe there's something else that makes the situation fine in a larger context. Software developers frequently believe that their employer should be focussed on optimising software development, but that's often not the most important thing at a corporate level. Maybe it's more important to leverage other staff, even it's detrimental to software development. Try to see things from other people's perspective. You'll know you're doing a reasonable job of this when you can paraphrase their position, echo it back to them, and see them nodding their heads.

It's really only when you get to this point - where you understand the other person's position well enough to describe it accurately to them, and you still believe that there's a problem, that you can start to move towards a solution.