Manage by Technology? Bad Idea – PropertyCasualty360

Consider this real world scenario. Acme Inc. is converting a monolithic COBOL mainframe application to J2EE and Oracle. There are massive blocks of COBOL that need to be rewritten. The development strategy includes an on-shoring element. A number of contract employees are brought on board for the duration of the project. The programmers for hire are paid hourly and are expected to work 40-hour weeks with any overtime sanctioned by management.

Bob (a development manager) notices that some of the coders seem to be spending a lot of time getting coffee or going to the restroom. Some of them even appear to be daydreaming or doodling. Bob decides that in order to increase efficiency he is going to change the way they are paid.

Instead of punching in at the time clock like the other hourly employees they will be paid when they log onto to their workstations. The workstations will be modified to force a log out during any period of inactivity after one minute. At the end of each shift the workstation logs will be off-loaded and the log-in/log-out activity will be translated into key clock punches. Up to two five-minute “breaks” will be allowed for each developer per shift. So now Bob has solved the productivity problems he observed. Right?

Wrong. What Bob has done is use technology to try and do what he as a manager should be doing—and created a lot of unhappy developers in the process. I don’t know about you but I don’t like disgruntled developers working on my code. Managing people is an art and a skill. Managing developers is even harder.

It would make sense for Bob to create a report comparing keyboard time versus clock time and use that to help make management decisions. There are always going to be employees who work the system—clocking in, walking around, chatting whatever. Those employees are management opportunities. A good manager will either make that employee understand how to manage their time better or terminate them. Using a chain gang mentality by paying for an active keyboard is silly and counter-productive.

Additionally when Bob imposed the new pay rules on the project developers he created a new class of employee. There are many other types of hourly employees at Acme and their time is still recorded at the clock. Different rules for different employees in the same general class (exempt) are foolish.

Managing Developers

I used to manage teams of developers. They were all highly-skilled salaried employees. They weren’t perfect employees. During periods without impending deadlines they tended to goof off a bit. But during major projects I could always count on the team to deliver on time, on budget, quality code. The firm I was working for at that time had salaried employees swipe cards when entering or leaving the property. The purpose was ostensibly to properly secure the building but the reality was that HR would spend hours scanning the badge scan logs. And I was always being called on the carpet. Mr. Rolich, are you aware that Bill didn’t clock in at all yesterday, and that Jane never clocked out for lunch? Furthermore Jane was observed in the parking lot so I know she left the building.

Well, I knew that Bill had worked around the clock the day before finishing up a tricky bit of code so I told him to stay home, and I really didn’t care that Jane “piggybacked” on someone else’s badge swipe. I was managing my staff the way I knew would work. HR wanted me to manage by the clock. Managing by the clock would have meant missing deadlines. HR could never understand that because they had no deliverables.

Everyone who has spent a significant amount of time writing code knows that you can’t just sit down at keyboard and start banging out quality code. The employee that Bob observed “doodling” could very well have been white-boarding a solution – but Bob never bothered to check. A good developer probably spends at least twice the time planning his solution than he does writing code.