Only one IT team can prevail
Upper management declared they didn't care who came up with a fix, they just wanted it done. But John believed that if his team solved the problem first with an even better workaround -- a magic bullet that would be cheaper than the other team's solution -- his career would get a boost. There had also been rumors that whichever team did not solve the problem would see layoffs and reduction in budget.
Sadly, as I talked with John, I realized that he did not understand the technology he was managing. He understood the people and seemed to have an excellent grasp on the principles of accounting. But the fundamental principles of system design had never been part of his education, and he never took the time and trouble to learn them from his subordinates. My observations were confirmed when I spoke with John's staff.
"Maybe you can get through to him," one member of the Cobol team confided in me. "There isn't a way to overcome the physical limitations of the system like he's been pushing us to do. We've done what workarounds can be done, as far as anyone on the team has been able to imagine. What do you think? Have we missed something?"
I reviewed the patches and design changes the local Cobol team had made. Their work seemed smart to me and thorough. But looking at the system and its problems, it was obvious that more workarounds were not the answer -- despite what John thought. The local team could start working on their own solution to overhaul the system, but John didn't like that idea. And besides, time was running out.
Around the water coolers, I was confidentially briefed on what they'd heard of the potential capabilities of the new system planned by their adversary two time zones away, which was fairly far advanced by that point. Unless they bungled the execution of the plan, it seemed that it would succeed.
End of the road for workarounds
I couldn't verify what the other team was doing, of course, but could make observations and recommendations regarding the local team's options. I wrote a lengthy report on the situation and what I thought could and could not be done about it. My VP and I met, went through the findings with a fine-toothed comb, and both agreed that yet another workaround was not the answer. Buying or a building a new system was the best thing that could be done at that point, which John did not want to do.
The final meeting with John did not go well. He concluded that I was an inept bumbler who had let him down. Per the instructions from my VP, I didn't argue with him -- and left as soon as possible after delivering the bad news.
It's interesting that the more things change technically, political power struggles remain the same as they ever were. I don't know what happened with this whole mess. I did feel for the local Cobol team that had the ability to devise their own solution, but were stopped by a boss who couldn't think beyond one way of doing things. I was glad to get back to tech problems because in many ways, they're less complicated.
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to firstname.lastname@example.org. If we publish it, you'll receive a $50 American Express gift cheque.
This story, "You can't spell 'office politics' without 'IT'," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.