id="info"

Collaboration

When a micromanaging boss is just plain wrong

A micromanager is bad enough, but his behavior can be even more infuriating when the technical merits of his demands make no sense and could even hurt on a strategic level.

All of us have encountered micromanagers. It doesn't matter how far up the corporate ladder you are. Your boss — and it could be the general manager, the director, or even the majority shareholder — could come barging into a technical evaluation or discussion and outline in excruciating detail on how things ought to be done.

This behavior is generally infuriating because, more than likely, the technical merits of their demands make no sense and could even hurt on a strategic level.

I've met my share of micromanagers. In this blog, I will describe them.

When the boss tries to be the network engineer

Despite a few attempts at enlightenment from the staff, the network engineer insisted on having two separate Internet connections - one for the corporate network, and another one just for the Web and e-mail servers. The primary reasoning for this setup was that it would be more secure since hackers wouldn't know the Internet "address" of the company. To be doubly certain, he had us register a random domain consisting of lots of numbers for the corporate network. And yes, both Internet links ran off static IPs.

Technically, this configuration is not optimal since the second link runs Microsoft Exchange for 30 heavy e-mail users as well as the company's Web site - with just a puny 256kbps uplink. We also ended up paying more for two links when we already have a fully DMZ-capable firewall that is not utilized.

When  the boss tries to be the system architect

In the course of preliminary discussions, the system architect picked an arbitrary programming language and opted for it to be the de facto language in all future programming projects. The basis of the selection - no idea, but it can't be in relation to the current languages deployed since the system architect doesn't know what they are. The only other clue is that the system architect kept saying "VB Sharp dot Net."

Sensing an opportunity, I made a snap decision and volunteered that what he really meant to say was "C Sharp dot NET." So C#.NET it became. Well, at least it's not COBOL.

When the boss tries to be the programmer

Once, the software team encountered a bizarre situation in a software app. The problem was that the figures from two reports generated by the same system did not tally. On closer examination, we realized that one of the reports only took values that were initially input into consideration, but ignored subsequent corrections modifications.

I presented the findings. Our team suspected the problem was a case of shenanigans by the previous programmer, or an inexplicable programming bug. The programmer quickly pulled me to one side, and told me that this was a "secret feature" that the previous programmer was specifically instructed to include.

The idea here is that any data-entry clerk who keeps making corrections is inefficient and therefore not wanted by the company. Because the supervisor will have to manually correct all erroneous entries from the correct report, it won't be long before the annoyed supervisor will have the inept staff removed. Beatific hands-free management, wouldn't you say?

Did I mention that we were manually editing the database every other day for months - at the behest of the newly hired supervisor, before we managed to figure out this bug feature?

When the boss tries to be the system analyst

When it comes to figuring out the flow of business processes, the system analyst is second to none. He already has in his head all data and functional flow down to the most minute detail, so why bother interviewing the users? Nope, his attitude was, let me tell you how things are done. Who are the mere users to argue anyway?

That logic help until one month later when the drawing board has to be cleared and the entire analyst stage redone because the system analyst had used outdated information or was just plain wrong on how things were done. Any resulting system built on the initial design would have been unusable.

Conclusion

In my next post, I'll write with some suggestions on what to do when management meddles. In the meantime, what anecdotes do you have of when the boss is just plain wrong?

About

Paul Mah is a writer and blogger who lives in Singapore, where he has worked for a number of years in various capacities within the IT industry. Paul enjoys tinkering with tech gadgets, smartphones, and networking devices.

Editor's Picks