Whose problem?

This post takes me back to my earlier theme of developers as change agents, which had a holiday while I was thinking about the EAT workshop. In my earlier posts, I talked about different people perceiving a problem differently, but there's a particular aspect of this that deserves more attention - even if we all see a problem, who's problem is it? To mangle a Mel Brooks quote, "My problem is a tragedy, but yours is a comedy".

The best way I can describe this is to talk about a real life situation. It's not a once off situation, so I don't have to reveal any secrets or worry about offending individuals. This sort of thing happens all the time. It happens when management is unhappy about development for some reason, but are a little vague about the exact problem. "We have to do better!" echoes around the table in closed door meetings around the board table. Perhaps it's the sales folk speaking loudest, "We're not meeting customer expectations" they say. This message gets passed down the hierarchy; "Make it better" is the refrain.

There are a few layers involved, but eventually the message trickles down to the developers on the front line. Their team leader gets the message clearly (sort of), "Job number one is to make the development process better", and heads off to do so. She has a meeting with the team to tell them that she wants them to do better, but they're quite happy with the way they develop software at the moment, thank you very much. They feel they have a pretty good idea of what needs to be done, defect rates are manageable, hours are pretty good, they get to solve some cool technical problems, and they've each got some nifty noise cancelling headphones. The message falls on deaf ears. As time goes by, each of the team leader's initiatives fall by the wayside, and management sees no change at all.

What's happened? Two things that I can see - the people who needed to live the change didn't actually have a problem. They were quite content, thank you very much. The message "management has a problem, you need to suffer some discomfort" doesn't really resonate very well. Although most of use help our neighbours to some extent, our selfish genes respond most fiercely when they're directly threatened, not just indirectly. So one of management's responsibilities (and I use 'management' in a very broad sense) is to make sure that people are motivated to solve personal problems. The simplest way is to translate problems into actual threats - "do this or you're fired", but it only works in the short term and not very well even then. Regardless, as a colleague many years ago said in reference to our startup CEO "I'm not working my ass off to make him rich". He would have worked his ass off to make himself rich though!

The second thing is that even after we all agree a problems exists and we all need to act, we still need to agree on how we'll measure progress. We need a metric, even if it's a very approximate one. Once we have a metric we can be involved in selecting as well as implementing change strategies, because we can try them out and see what worked, possibly in near-real time. Without that, we're reduced to following change implementation orders - not only is this less than fun, it doesn't give everyone the chance to suggest changes, and as well all know, all of us is smarter than any one of us! It's also helpful to have other metrics in place so we have a chance to measure unintended consequences of our changes.

So if you want some other folks to change their behaviour, make it personal and make it measurable. Encourage them to feel your pain, and help you to assuage it, rather than sitting pack entertained by the comedy of your suffering.