JustifyingChanges
Note: You are viewing an old revision of this page. View the current version.
Metrics as a Weapon?
Here's something I've learned from attending lots of meetings in a large company: you can always shut things down by requesting more information.
This isn't unique to large companies, it's just more obvious in that setting. Say you are in a meeting where someone is outlining a great way to change a process. If you don't like the idea, just say, "Sounds interesting! Can you supply more metrics?" The presenter has no choice but to retire from the field, mumbling about how they will come back next week with a more detailed analysis of the current situation and how it could be improved.
I've been guilty of this technique many times myself - in fact I'm sure all of you have done it. We humans naturally fear change. No matter how horrible and unpleasant the current set up, it has the advantage of being a known quantity. Why take a risk that the suggested improvement ends up being more unpleasant? Even if the new process is significantly better than the old process in the long run, everyone still needs to be retrained to understanding. Wait, that sounds like extra work!
This problem is actually worse now that everyone knows the word metrics. Don't get me wrong, we definitely need to measure what we do. I'm a huge fan of collecting and interpreting data. You can't make a decision without first understanding what is really going on. The problem is that everyone has a general idea that this process now exists. From there it's a short logical leap to, "something new? NEED MOAR NUMBERS!"
If two separate teams (the developers and the operations folks for example) have to come to an agreement on how to make a change, that requires a meeting. The developers want change and the sysadmins don't. Thus I know going in to that sort of meeting that I can always find some point to pick apart based on a lack of data. That gives me a lever to use to try to derail the change.
Keep in mind that this needs more testing is really the same as saying we need more metrics. Consider also that asking someone else to do more testing or to gather more data can be an oblique way of calling them (or their team) incompetent. You're telling them that they forgot to do something, or that you don't trust them. It's no wonder cross-team meetings can be so tricky to navigate!
The good news is that there are ways to control this problem. First of all, stop having so many formal meetings. The best way to do that is to facilitate informal information transfer, based on mutual respect. One way to improve that is to seat the developers and the sysadmins together. Don't put all the developers in one cube farm and the operations folks in another.
Another way to guard against the use of metrics as a weapon is to develop a formal process early on, and stick to that process. Give people a clear checkpoint mechanism so they know when they can ask for information and when they should be working to meet deadlines. Just don't fall into the trap of crafting a more and more complex process to accommodate all possible scenarios. That's a subject for an entirely separate post.
Finally, and most importantly, foster an environment of trust. This is the hardest thing to do, but absolutely critical. Trust is built on mutual respect. Respect is built on understanding. If you don't understand what a person does, it's hard to respect them, and that means you don't trust their work. Then you have a 'syncup meeting' and someone asks for more metrics, and everything goes straight downhill.
I'm not saying that I have any magic way to cure this problem of knee-jerk requests for more data. I fully realize it's a symptom of something else - a lack of communication and trust. I encourage all of you to think about these issues the next time you are tempted to ask for more data in a meeting. Do you or do you not trust the people you work with? If you don't trust them, why not? Can trust be built? The answer is YES, but you have to start by analyzing your own motivations.
