Drowning in bureacracy
A cautionary tale of what too many managers and too few IT staffers can look like
Follow @ifw_otrBack in the early '90s, I was a programmer/analyst with a privately owned travel management company. The IT department was small back then with the employees doing a variety of tasks (a director, a manager, a network admin, an ops person, and three programmer/analysts -- no DBA, no project managers, no business analysts, etc.). We were small enough to have our staff meetings in the director's office.
One of the programmer's work was largely involved with the end-of-month process. Between preparing for EOM, running it, and then cleaning up afterward, this task occupied most of his time. We were running nearly everything in dBase for DOS back then, including the EOM process, and had no dedicated PCs on which to run EOM. So for one week each month, 15 or so user desktop PCs around the office would be used to run the various EOM scripts and procedures every evening. Because the EOM process wasn't entirely seamless, it often involved someone coming into the office in the middle of the night to fix something. All the programmers were on rotation so the EOM processes would be covered through the night.
[ Got amazing IT tales, real-life experiences, lessons learned the hard way, or war stories from the trenches? Submit it to InfoWorld's Off the Record blog. If we publish your story, we'll send you a $50 American Express gift card. | Join or start an IT conversation in InfoWorld's Adventures in IT discussion area ]
When the director left for greener pastures and the EOM programmer soon followed, the new director decided it would be smarter to hire managers rather than programmers, so he hired two new managers -- one of whom was to replace the programmer who was in charge of the EOM process. He hired a contract programmer to help out with the redistribution of the programmer's duties, but not with EOM. We couldn't understand what the new director was thinking when he hired a manager to fill the role of running a very non-turnkey, in-the-weeds process like EOM. We figured that one of the other two dBase programmers would be pulled away from their regular duties from time to time to train the new manager on the EOM process and that he'd soon figure out that we needed another programmer on the staff. My view is that the new director was one of those folks who takes a very management-centric approach to accomplishing goals: if something doesn't work, then throw more bureaucracy at it.
