One of the most unfortunate business practices I’ve seen is management’s failure to consult geeks before committing to deadlines. I’ve experienced this personally (“We’re moving in two months and need all new technology! We haven’t signed any contracts or bought any hardware! Have fun!”), and have inflicted various forms of it on my geeks (“We had a flood in the server room. We have to be up and running yesterday.”). In any form, however, it’s sub-optimal at best.
Failure to consult geeks before making hard deadline commitments to clients, however, is one of the more horrifying forms of scheduling nightmares. While this obviously happens more often in software companies, any company with a geek-driven client-facing product or service has probably run into this problem.
As much as I’d like to portray geeks as the poor, unfortunate victims of this hideous management practice, I cannot. To some extent, geeks (and their direct leaders) bring this on themselves. How? Well, how many times have you had or heard this conversation:
Geek Leader: We need to do [project]. By when can you get it done?
Geek: That depends.
GL: On what?
G: Well, I’d have to investigate to find out.
GL: Can you give me anything? Ballpark? Something? I need to tell the client by today so that we can get the contract signed.
G: Uh, I guess it could take anywhere from three weeks to three months.
GL: @#$%^&*()!!!
The geek has undoubtedly given the geek leader accurate responses. Unfortunately, the responses are completely useless to the geek leader. And the contract has to be signed, because the business needs the money. The geek leader will probably make something up based on previous projects and have the client sign off on it. The geek leader will then inform the geek, who will be absolutely flabbergasted at the miracle that she must pull off–doesn’t the geek leader understand ANYthing???
The very nature of geek products and services prevent accurate estimates of time. However, the geek and geek leader might have a little more luck by following these steps in trying to form a deadline:
- Compare the project with previous similar projects.
- Identify the macroscopic ways in which this project is different from said previous projects.
- Take the time for the previous projects and add or subtract time based on estimates for those differences.
- Inflate the time to allow for at least one disaster.
- Negotiate with the client from there.
Will it be perfect? Of course not. Will it lead to better estimates and fewer necessary miracles? Probably. This process can be initiated by either the geek or the geek leader. It might take a little time, but will lead to happier geeks (and clients–after all, you’ll probably blow fewer deadlines!).
Leading Geeks 