View Source: JustifyingChanges

Note: This page has been locked and cannot be edited.
!!! 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.

This idea can also be extended to electronic communication.  One way to do this is to get everyone into a shared IRC channel.  If done properly this can serve as a 'virtual watercooler'.  Management support of this idea is critical.  At the same time, you don't want too many managers in the channel watching things too closely.  That's like having your boss looking over your shoulder all day long.  However, the managers should support this idea and encourage their employees to use it.  It might be appropriate to have one channel where managers are active, and one where they aren't.  That way workers know that if they want to vent a little they can jump over to the other channel to do so, out of sight of management.  The only risk here is that you could end up with all the Devs in one channel, and all the Ops in another.  The other issue with this is that Ops requires a lot more communication than Dev, which can lead to just the sysadmins on irc and nobody else.

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.

-----

CategoryGeekStuff

CategoryDevops

CategoryBlog
View Source: JustifyingChanges

Main Categories

Search

Toolbox

RecentChanges

Favorite Categories

Views
