Bob Lewis
Columnist

Problem employee or lack of processes?

analysis
Aug 4, 20053 mins

Dear Bob ... I have read you column for a while now and normally your advice is right on. But I think your advice to About to Bolt missed the core of the problem. The problem is that About to Bolt is not is not managing his business. Where is the quality assurance activity? Where is the gate keeper of production? Where is the change control process? These kinds of processes are used to keep bright people from pl

Dear Bob …

I have read you column for a while now and normally your advice is right on. But I think your advice to About to Bolt missed the core of the problem.

The problem is that About to Bolt is not is not managing his business. Where is the quality assurance activity? Where is the gate keeper of production? Where is the change control process? These kinds of processes are used to keep bright people from playing Rambo in production. That is how we keep them in line and keep them from becoming sloppy.

I have seen more than one development department start putting out quality code real fast once a documented and enforced quality assurance and production promotion process was put in place and enforced. Yes, there will be wailing and gnashing of teeth, but once everyone knows and becomes familiar with the process, it works. Such things as peer reviews, management sign off, customer review and sign off, reviewed test results are just a few ideas that I have seen work. I am confident that if this manager gets rid of this employee someone else will come along to fill his ‘Rambo’ shoes — they always do. I think he wants to be able to just trust his staff will be professional and thorough. He cannot do this — that is not Managing.

Now as for this employee not paying attention to the warning signs of disaster, maybe if About to Bolt were to give him a small project and responsibility to develop an way to monitor and report on the various system warning signs for his environment — holding him accountable if any of the foreseeable and preventable problems he is supposed to be monitoring arise, this fellow will become much more attentive and proactive.

Push the accountability and responsibility down to where it belongs. There is no reason, for instance, that this employee cannot be required to gather CPU usage, or memory, or file system capacity/availability, or any other metric and report weekly on his findings and predictions. “Tell me when we will reach 80% capacity on the file systems on all of our servers.” And so forth.

– Process Guy

Dear Process Guy …

I’m not going to argue with your recommendations, because in many environments I’d be recommending the exact same things, whether or not they had cowboy programmers wandering around. The reason they didn’t form part of my response to About to Bolt was two-fold.

First of all, I don’t know if he’s running a 3 person shop or a 300 person shop. The extent to which you institute formal software quality assurance, change control, and related processes has a lot to do with size: The bigger you are, the more formality is required; the smaller you are, the more formality chokes off your only advantage: Agility.

The second reason is a bit of personal philosophy – with the wrong people even the best processes will fail; with the right people even the worst processes can succeed. The underlying question, in my mind, isn’t the state of process definition and enforcement. It’s whether the manager has established clear expectations for the employee and whether the employee is living up to them.

– Bob