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.

10 comments
ernestm
ernestm

Each of these examples is just an example of a boneheaded staff-level decision. If all these people were just staff level, they'd still be decisionmakers in their technical fields, and they'd be doing the exact same thing. Architects still define standards, network engineers still define how many Internet connections are needed, etc. In that case, you'd want the boss to be somewhat technically involved, right, so he could call BS on them? And not totally hands-off? These are very, very weak examples to use for talking about micromanaging. Just because someone in a management position can be a bonehead isn't relevant; so can people in staff postitions - in fact, these examples are clearly of people who came up through the staff and weren't the dreaded "manager by trade" people. What really are you complaining about here - what's the heart of it? Micromanagement means "managers becoming too involved with technical details." That's not the case here - I'd expect a network manager to be involved with something as high level as how many Net connections you have ($) or an architect manager with a "single language" standard. I think what you're really complaining about here is these individuals' a) retardedness and b) unwillingness to take everyone else's input/opinions into account when making these decisions. That's an issue with the dictatorial style of decisionmaking, not micromanagement. Management and leadership is a discipline just like being a programmer or network engineer is; when we discuss it we should use correct and specific terms. This article, frankly, comes across very like the spiel of the "VB Sharp dot NET" guy.

barryh
barryh

I have experienced a lot of micromanagement but I dont see the relavence of what is being presented here. If you have the feeling of being a baloon on a string, constantly bobbing around from the tuging and jerking on the stiring you're being micromanaged. They talk about project management but are constantly overriding the schedule with their own tasks etc. In reality this is 100% reactiuonary mode and will doom any organizatoin to a miserable existence.

tuomo
tuomo

I love this but really would need more than one short post to comment - too many "funny" aspects. So I pick one "system architect". It perfectly shows todays problem - an architect picking up a language is as a building architect saying that only Black&Decker tools can be used to build this high rise? See the problem? Well - maybe to go to others too, analysts don't analyze today - when was the last time you did see an analysis? Programmers - unfortunately if they want to keep their jobs, give up to managers wishes instead of real things, too many network engineers and admins know the GUI's but have no idea how the corporate network is supposed to work for business. And, of course, all want to "micromanage" their own turf. Hurt your feelings? Don't take it too hard, it's actually the way business works today.

CG IT
CG IT

Back in the 80s, I worked for an aerospace defense contractor right out of college. Really a cool experience. An engineer who worked on the Apollo program, a friend of mine, talked about a German study done during WWII. There was a chart with 4 boxes with stupid, brilliant lazy and industrious in each one. He went on to say the Germans used this criteria to evaluate people working in the factories. The Germans figured out the most dangerous type to have. Stupid and industrious. People who haven't a clue as to what they are doing and spend all their time doing it. The best of course are the Brilliant and Industrious but what the Germans found out was the Brillant often looked lazy. Always out walking around with their hands behind their back deep in thought. Probably why they were brilliant. Sounds like your experiences were with the stupid and industrious kind that did things for personal benefit.

paulmah
paulmah

When I wrote the article, I labeled the various sections as a tongue-in-cheek way of portraying the boss who micromanages on areas he/she have no real business looking into. I regret that it has caused a fair amount of confusion however. The sections are now labelled "When the boss tries to be...". Hope it is clearer now. Thanks for the feedback. Regards, Paul Mah.

harrylal
harrylal

I agree that management is a discipline that which has forethought and planning at its heart, and generally requireses delegation and follow through to be effective, but I am not seeing any of this in these cases. You state these were staff level decisions (perhaps we have a different idea of staff), but it seems to me every single one of the "bonehead" decisions was made by an ill informed and undiciplined manager (someone in charge of making some decisions) attempting to assert authority and becoming too involved in the technical details (the last part was taken from your definition of micromanagement). In my way of thinking, dictator and micromanager are terms that are easily interchangeable in the provided examples. How these managers came up through the ranks and their level of competence (or lack thereof) perhaps explains part of the problem, but the bottom line is they didn't guide the direction or delegate the task, they decided how it should be done in specific detail.

yonman
yonman

I'm not a fan of the term "blog" nor the presumption that a blog need not be a coherent presentation of thought. Your free form thinking, presented as an article has only served to confuse me. Wait...what was your point again?

don.gulledge
don.gulledge

I think your dead on. But, one thing you didn't say that IT is made up so much today of non-techical people than technical.

ernestm
ernestm

As your response indicates. There's a bullion things a good manager is supposed to do - delegate, plan, lead, etc. It's convenient to just glom all their failures together and put one term like "micromanagement" on it but it's not correct - and more importantly, it's not helpful in getting at the heart of the problem. A couple things. One, most of the decisions in this post were high level enough a manager would probably correctly be involved to some degree. This isn't the 1950's days of totally nontechnical "managers by trade" playing golf while the technical staff do all the thinking. I know some people out there are stuck still working for 1950's type companies, but most aren't. In our shop, we would expect that decisions like major architectural standards, high level network mapping decisions with major cost implications, etc. would be vetted by front line management and not *totally* left to a random staffer to decide. So in these cases, the managers don't appear to be out of their proper technical depth (with the exception that being retarded would normally disqualify them.) So in my opinion, the managers in a lot of these cases aren't micromanaging. They're just not delegating. Micromanaging involves closely observing and controlling the work of your subordinates. Failure to delegate is a separate issue. (Though in the modern world, managers are often expected to deliver some technical stuff - especially architecture and planning - themselves; only the worst firms have enough spare manpower that once you get promoted to manager it's off to the links.)

ernestm
ernestm

blog: like an editorial column, but without the benefit of planning or editing.

Editor's Picks