Drowning in bureacracy

A cautionary tale of what too many managers and too few IT staffers can look like

Back 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.

The two dBase programmers were familiar with the programming behind EOM, and all three of us were fairly familiar with the process, but only the recently departed programmer had ever managed the entire EOM process from beginning to end. So now here was a manager sitting at the desk of the former EOM programmer -- and he had absolutely no idea what to do. (I assume he tried the two dBase programmers first for help, but they didn't have time. I didn't have time either, but I have a harder time saying no). He came to me and asked me to handle EOM. Now, at the time I was not a dBase programmer. I was an Automator and Paradox PAL coder. Despite that, I started getting deeper into dBase and took over much of the EOM process, including scheduling the programmer rotation (shouldn't the new manager have been able to at least do that, especially if he'd been hired specifically to take EOM on, as our director said?).

During this time, two of the other programmers left, so that left the programmer/analyst staff consisting of two people: A contractor and me. Occasionally, when someone needed to look at the code written by one of the recently departed programmers, the contractor and I would be called into a conference room with management and handed a printout of dBase code, and right then and there expected to just look at the code and tell them what it was supposed to do and why wasn't it doing that correctly.

To say the least, the mismanagement and scattered priorities made life interesting during this time. It did get better for awhile, then worse again, and later hit bottom -- but that's another story. Later, the staff increased in size and additional developers were hired. Eventually we were acquired by a larger company.

I guess even a small company can drown in bureaucracy.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies