No one would fire this guy. This was several years ago when I had a colleague who just couldn’t get fired, no matter the dot.com implosion, no matter how ornery he got. I still remember it to this day and I still laugh out loud about it.
Market forces were cleansing the dot.com bloat and workers, specialists, good people, bad people were getting laid off by the bucket full. But this one, somehow, was un-fireable! He would even boast about how he would not follow process and would sometimes get a tad rough with the customer over the phone. I saw him grow this persona over time, so that as business overall got worse, the more crotchety he got. His philosophy? “Fire me now so I can get it over with and move on.” Somehow the body count kept climbing, but he kept standing.
As you’re guessing, he did have something unusual about him that made his managers want to keep him. I don’t think even he understood at first what was happening. As time progressed however, I noticed something interesting. He actually got better, much better, at his job. He lost his anxiety, really got down to business with the customer, and kept his head when everyone else was losing theirs.
Keep in mind, because of the dot.com bust, the customers themselves calling in were imploding at the same time – and they were under tremendous stress and panic. He started acting like the proverbial doctor who didn’t hesitate to verbally slap a hysterical customer into calming down so he could start operating. That’s what made him good. Processes were breaking down both internally and externally (i.e. no longer lined up to the business reality), so he took charge of each and every interaction and did rescue many a customer and many an account for their managers – simply because he was no longer afraid of the axe.
Last time I talked to him, he was still trying to get fired…but I don’t believe him anymore…he’s gotten way too friendly again J
I use a little Text Replacement utility to bring consistency to project naming, file naming, correspondence, and date and version control. I started using it when I worked the tech support line years ago to bring consistency and speed to documenting problems and resolutions. It provides personal structure on how to ask or provide information.
I typically type ## as the trigger for the utility to start the text replacement, though you can set the triggers to be what you want.
Examples:
# #fcon – “As a follow-up to our conference call, “
# #zn gives me “(No Action Needed From You)”
# #+d = [inserts tomorrow’s date]
The utility I’ve used for a long time is by Shortkeys.com
Black-Boxes, Cog-Wheels, Inside & Outside Circles, and PROCESS CYCLE TIME.
I’ve been training myself to think in terms of “process-cycle time” instead of “work-effort hours”.
Say I know for a fact that a particular database coding task really only takes about 1 to 2 hours to accomplish on average in the hands of a dedicated technician. So do I use the 2 hours estimate in my plans? No. While it is true that the actual work time has meaning to the technician doing the task, it has very little project management use. It’s because the 2 hours of actual task is not the real turn-around time to get the job done.
What I want to really know is how long does it take for the request to go into the black-box of the programming team and then come back out of that same black-box all cooked and ready for consumption.
Sometimes I don’t want to even know the details, but here’s what I would suspect is happening inside the black-box and cog-wheels of that fictional team:
Code work request gets submitted (e.g. 2 minutes)
sits waiting (e.g. 1 business day),
gets reviewed (e.g. 5 minutes of scanning by an expert),
sits waiting some more (e.g. 1 business day),
gets approved (e.g. 1 minute),
gets scheduled (e.g. 10 minutes),
sits waiting some more (e.g. 2 days)
actually gets coded (e.g. 2 hours),
then gets submitted, reviewed, corrected, and then finally accepted and proclaimed as task done.
In that case the turn-around time I’m looking at is about 5 to 7 business days. That’s the time information that’s relevant to making plans and setting expectations with the customer.
(Incidentally, you might have noticed that doubling or tripling the speed of the coder would actually have little effect on the cycle-time – the gains could only be obtained in that department by improving its internal process.)
