ManagementSpeak: He has been given opportunities to excel in a number of different roles in the organization.
Translation: It's time to fire his worthless posterior.
This week's anonymous contributor excels in the art of mumbo jumbo translation.
You always test. The only question is whether you test before or after you put your software into production.
No, this column isn't about Windows Vista. Mathematicians haven't invented numbers small enough to describe the chance of my having anything original to say about it.
This column is about mistakes, and what to do when they happen.
Last week's column is a good example. It presented a formula for calculating the average span of control in a company: If a company has n management layers, the span of control is the nth root of the number of employees.
Close, but no cigar. Chris Miller was kind enough to explain that I should have analyzed the matter more closely.
Had I done so I would have recognized that it isn't quite that simple. For any number of layers (L) and span of control (S), the number of employees is actually (N) = S^0 + S^1+ ... + S^(L-1). (If you're really good you can turn this into the more compact formula: N = (S^(L+1)-1)/(S-1).)
There might be a way to solve this for S but I haven't found it. Instead, you can plug the formula into Excel and twiddle with values for S until the number of employees comes out right. The span of control for 5,000 employees with three, four and five management layers is about 16.75, 8.14 and 5.27 respectively (the numbers I published last week were 17.10, 8.41 and 5.49).
Does this matter? It depends. Had I described my results as a first-order approximation (see "The art of approximation," Keep the Joint Running, January 15, 2007) then it wouldn't matter a bit. Since I presented my results as being exact, though ...
Which brings up the question: What if I reported to you, and I'd made a mistake like this in some business analysis you'd asked me to prepare? It isn't difficult to enumerate your possible responses:
The problem with coaching as it's usually practiced is that it's undirected and unspecific. The manager explains the importance of being more careful, expresses confidence in the employee's ability to do better, and ends the discussion convinced that positive outcomes will follow.
Usually, they won't, because why would they? Nothing has changed.
That's the upside. The downside: Most will hide their future mistakes from view, turn down difficult assignments or any whose results can be evaluated objectively, and energetically rationalize any mistakes you detect from here on in, arguing that they aren't mistakes after all. They aren't bugs, that is -- they're features.
You'll get the desired results without the undesirable side effects if you content yourself with communicating. Explain the gap between the work product as the employee delivered it and your expectations.
Unless, that is, you think your employees come to work every day planning to mess things up. If you do, hold yourself accountable for hiring such losers.
Set high standards, publicly compliment employees who meet them, and inform employees, privately and professionally, when they fail to do so. Usually, that's all you have to do -- no punishment needed.
I'll get the math right this time, because it's pretty simple. If one server is down, on the average, 0.1% of the time, then a cluster of two servers will be down only 0.0001% of the time (0.1% squared). That's a lot cheaper and easier than trying to get one server to achieve the equivalent level of reliability.
Humans make mistakes, especially when engaged in creative efforts. Two humans are less likely to both miss the same mistake than just one -- it's why professional publications use proofreaders and fact-checkers.
The employees in your organization are going to make mistakes. They are, after all, human beings and we humans are prone to imperfection.
The question is how you handle them when they happen.
Bob Lewis is president of IT Catalysts, Inc.
Copyright 2007, IS Survivor Publishing, all rights reserved.
No comments:
Post a Comment