Fog Creek Software
Discussion Board




Why are managers clueless buffoons?

I've seen this pattern enough in my professional travels to conclude that its the norm, not an exception: a middle manager who:

1. Every smart programmer that works for or near him thinks he is a clueless buffoon who just wastes people's time and slows things down.
2. Most of his management peers and superiors (who are also perceived as buffoon's by the smart programmers who work for them) think he's a great manager.

Why is this?  Is there anyway to slap the dumb out of these people?

Ugnonimous
Monday, March 29, 2004

None whatsoever

A manager
Monday, March 29, 2004

Reminds me of one of my favourite jokes:

Q. Why are organisations like a tree full of monkeys?

A. Because those at the top look down and see smiling faces whilst those at the bottom look up and see a*s holes.

John Topley (www.johntopley.com)
Monday, March 29, 2004

Middle management people are in kind of a strange position many times.

For example, a company I do contract work for from time to time has 6 system/network administrators. The guy who is set to manage them (friend of mine) has no where near the knowlege and experience they have when it comes to building and maintaining networks.
What my friend has is experience in buying equipment, making scheduls and plans and drawing up budgets.

From my perspective, these are two different, but jut as important functions. Yet one of these functions is usually placed higher than the other in the hierarchy, and there is no really good reason for it. In fact, it might make more sense to reverse the relationship.

I think a great many middle managment people knows this and are thus insecure and basicly resort to being a-holes as a means of protecting their territory.

Like the wizard of Oz. "Look at the big a-hole, not the little man behind the curtain pulling the levers."

Eric Debois
Monday, March 29, 2004

Middle Management is a *tough* job. Been there. Done that.  Though in a different industry. You've got to keep two completely different sets of people happy. And, yes, you are paid to do just that.

Line staff (coders/developers/programmers, in this case) are a demanding lot. They want more resources, more freedom, more pay, lesser questioning, lesser working hours and lesser work vis-a-vis the Management. Management (Directors, Boards, VPs, Presidents) want to lesser resources, lesser freedom, lesser pay, more justifications, more hours and of course a lot more work vis-a-vis the line staff.

It stinks. Ergo, ****holes.

And the fact that there are that many companies of that many scales employing that many people doing that many different kind of work goes to show that ****holes have their functions and pretty vital ones.

A manager
Monday, March 29, 2004

Managers are not universally clueless buffoons and I would guess that on a manager blog/discussion site one might ask, "Why are programmers arrogant do nothings"?

I think that basically everyone who reaches adulthood without going insane has set up some mechanisms in his head whereby he rationalizes all inputs such that nothing is ever really his fault.  In a organization there is always someone else who is doing a worse job and making it impossible for you to do yours.  From the manager's point of view it is probably amazing that given all the work he does to make your life easier, you still bitch and moan and produce buggy code later than he thinks you should.

Add to this the fact that everyone who lasts in a workplace does has gone through a process of natural selection.  For middle managers the selective pressure has nothing to do with doing a better job for the company.  It has to do with looking good to superiors and getting more and more workers under him.

Also, my experience is that most everyone is lazy, self-centered and borderline incompetent, most people agree to this idea on some level and most people fail to see that it applies to themselves as well.  See first point.

name withheld out of cowardice
Monday, March 29, 2004

Managers are uneducated.  We all spend our undergrad years learning hard things.  Do you think business types are saddled with physics, chemistry, math, along with all of our CS stuff?  No.  They're partying.  But then again, they're preparing for what really matters in management.  When it comes down to it, what's really important for managers is being tall, having good hair, and golf - and if you don't admit this, you're blind or stupid.

888

anon
Monday, March 29, 2004

Software is pretty unique because it's one of the few fields where non-experts are managers. That's why there is rightly so much condemnation of management in software.

That's why the anecdote about the sys admins rings true too. You could extend it to project managers, who often fill a role like co-ordinator, rather than manager. They rely on a "technical lead" to answer all their questions and, really, should be on lower pay and standing than the developers.


Monday, March 29, 2004

Could someone who has more that just S/W experience under his/her belt please back me up. Please!

A manager
Monday, March 29, 2004

Okay.  I've worked at two tiny startups.  I was technical lead, or software architect, or whatever you want to call it, and there was no need for an idiot manager.  At the two IT shops I've worked for, managers were clueless.  Ego was everything.  They had no idea about anything software related, even though they came up through the ranks.  They were huge impediments to success because they had to "design" everything.  They were tall, however, and they all played golf together and, at the last place, they all went to the same church.  Hmmm...

If you have a good development staff, there is absolutely no need for middle-level management.  They will only impede progress.

anon
Monday, March 29, 2004

<quote author="anon">
If you have a good development staff, there is absolutely no need for middle-level management.  They will only impede progress.
</quote>
Small correction.

<quote>
If you have a good development staff, there is absolutely no need for middle-level MANAGERS.  They will only impede progress
</quote>

The function remains valid. The function_aries_ may be redundant.

A manager
Monday, March 29, 2004

I'm not sure they're all that bad. I've had jobs ranging from ditch digger to programmer. I've worked on assembly lines and drove truck for a few years. In most cases, the worst managers were those promoted from the line so they knew that they knew everything, even though processes and/or technology had changed since the last time they actually performed the task in question. With few exceptions, my best managers were those who knew they knew nothing about the task I was to perform and were therefore dependent on my advice and expertise.

Ron Porter
Monday, March 29, 2004

Hi Amanager,

Among other things, I believe some posters are trying to make the following two points.

1) Many project managers don't have the qualifications for the position they hold. That is, while most PMs have prior management experience they have no formal or informal training in IT project management. Some project managers used to be resturant managers, others used to work in a different department of the company such as accounts payable, blah, blah, blah.....

2) General management techniques enforced by most corporations are nearly always wildly inappropriate and self-defeating when used on technical staff. As obvious as that might sound to most technical workers, companies continue to teach a command and control approach to coerce their technical staff into certain behaviors. What is usually an effective technique for dealing with salespeople or other kinds of office staff is nearly always a disaster when applied to technologists.

One Programmer's Opinion
Monday, March 29, 2004

You'd think that with MIcrosoft being generally accepted as a reasonably successful software company you'd see morecompanies adopting its mamagement practises.

Stephen Jones
Monday, March 29, 2004

"What is usually an effective technique for dealing with salespeople or other kinds of office staff is nearly always a disaster when applied to technologists."

LOL!

You don't think *every* group of specialists thinks they're "special" and "that doesn't work with us"?

Check your DNA, dude - if you're human, you can and should be led, and the processes are the same.

Some basic tenets of leadership; feel free to tell me which don't apply to you:
- Trust your people
- Know your people
- Be firm but fair
- Don't give ambiguous directions
- Be accountable for your people's actions to your superiors
- Praise in public; rebuke in private
- Give constant, consistent feedback
- Lead by example

Those are just a few. General concepts that apply to herding cats, whatever species those cats may be. ;)

Now if we're talking about managers who don't understand those concepts, well, that's going to piss everyone off whether they're in sales, on a production line, or a programmer.

Philo

Philo
Monday, March 29, 2004

Fair enough. But that is not the same as "Almost all middle managers are clueless buffoons". It's like saying "All VB coders are incompetant script kiddies" and I understand the FG develops in VB.

Any organisation needs managment. Or else we would all be ISVs with no one to vend to. It is upto to each individual, be he a coder or a waiter or a supervisor or a tech. lead or a PM, to understand his role and execute it appropriately.

There is no point in claiming "I suffer incompetent bufoons for a living", when the same thing is said of one when one _becomes_ the aforesaid bufoon, as has been pointed out by a previous poster. To avoid that it is essential that one understands the function of management and not get stuck with individual personalities. An no understanding can come about if one already has a fixed notion of the relevent designations.

KayJay
Monday, March 29, 2004

The above was in response to "One Programmer" and oops! I blew my cover!

KayJay
Monday, March 29, 2004

To those complaining about the low quality of managers--please give management a try, then report back to us on the brilliant job you did and the secrets of your success.

Cognitive Dissonance
Monday, March 29, 2004

Re:

- Trust your people
- Know your people
- Be firm but fair
- Don't give ambiguous directions
- Be accountable for your people's actions to your superiors
- Praise in public; rebuke in private
- Give constant, consistent feedback
- Lead by example

Interesting (to me, anyway) how much of this applies to raising kids, as well...

Grumpy Old-Timer
Monday, March 29, 2004

Anyone can screw up a relationship, its an easy and immature thing to do. It takes effort and investment to make it work. Sounds like you are too lazy to give your manager the information that they need to do their job properly. Their job is not the same as yours. They don't descend from the brow of Zeus knowing-all.

Woodentongue
Monday, March 29, 2004

I worked in two companies with the only Really Good
Manager I've ever worked with.  He's now a CEO of a
startup - I'd happily work with him again, but don't since
his startup is in a completely different field.

His best skills were in acting as a firewall between
"Senior Management" and the engineering staff.  The
engineers only had to worry about engineering, and
didn't have to worry about budgets, planning, schedule
negotiations, scope planning for the next release, etc.
He also had lots of "street cred" as an engineer himself.

x
Monday, March 29, 2004

>> "
- Trust your people
- Know your people
- Be firm but fair
- Don't give ambiguous directions
- Be accountable for your people's actions to your superiors
- Praise in public; rebuke in private
- Give constant, consistent feedback
- Lead by example"

This would surely be swell if there existed managers who followed these principles.  But there aren't.  The only criteria form management are being tall, having good hair, and playing golf.  That's it. 

From what I hear, it seems like Microsoft has institutionalized good management, but in the typical Fortune 500 IT shop, it's an old boy's club - and that's that.

anon
Monday, March 29, 2004

Agreed about the buffoons.

Management doesn't always have a single clue about the situation in the trenches.

And there seems to be a mechanism in the organization to make it dangerous to an underling to point out the deficencies.  Thus bad situations fester and the manager is oblivious.

workerbee
Monday, March 29, 2004

The way around doing all that awful "leadership" stuff and still succeeding is to have charisma, be political, and surround yourself with good people.

However, I think that only works in the short term.

Philo

Philo
Monday, March 29, 2004

In support of "manager" - developers are lousy planners - that's why - ALL software development schedules are ALWAYS wrong - all software releases are delayed and over extended because the Developers have no clue of when they will finish what they think they can finish.

Credit to "GOOD" managers who manage to "herd these cats" and try to give some workable schedule and keep them from drifting into "artisitic" pursuits.

KS
Monday, March 29, 2004

Every smart programmer thinks everyone else
is an idiot. See megalomania. Middle managers
are just in their target zone.

son of parnas
Monday, March 29, 2004

Trust and respect goes both ways. If you don't trust your manager and respect his/her wishes, what expectation do you have that they will treat you fairly?

You have to give the manager information in a way that they can understand. Not all managers are buffoons, though I have to admit I've worked for some.

pdq
Monday, March 29, 2004

I think management is a no win situation.  It is nonetheless necessary.  *Someone* must takes ownership for the final decision, because even very smart people will come to disagree at some point.  While I agree that as an organization gets bigger, projects get more and more obfuscated by the meddling of management, keep in mind that without these organizations and *clueless buffoons*, most programmers would drown in their own eccentricities and disorganization.  As fun as it is to whine about how you could do things so much better without these buffoons always screwing everything up, the truth is that if you could really do it better... why the hell are you still working for buffoons?

The reason: because you lack the motivation, or time management skills, or ability to handle clients, or ability to balance budgets and resources, or various combinations of those attributes.  If you CAN do it better, maybe you SHOULD do it better and go get your own freedom and happiness.

The things that make programmers great (similar to the things that make artists great), having minds that just think differently than the average person, are the same things that often prevent them from really being to do the necessary things that managers do.  The exceptions are there, but very rare.

Slicky
Monday, March 29, 2004

Parmas,

You have just solidified my opinion of myself as a smart programmer.  Thanks!

MacSqueeb
Monday, March 29, 2004

My direct manager is a middle manager, and he is useless.  He knows nothing about what I do, and cannot fathom scheduling my projects since he knows nothing about what I do.

He is no buffer from senior management because he is a wimp and just says 'yes'.  His attitude is 'delays are normal', and that schedules are always just estimates and can be changed and re-arranged whenever necessaryu by whoever needs to.

Needless to say,  I manage myself.  My manager is a rubber stamp.

Sassy
Monday, March 29, 2004

What I do as a manager (in order of priority):

#1 Keep The Developers Coding

When senior management has some time-wasting one-man project, I work on it myself.  That way my developers can keep doing what they're doing without interference.

When a customer calls with some complicated problem that would waste countless man-hours to debug, I talk to the customer.  I only bother the developer if it's a real bug that needs to be fixed, and only after I have isolated where the problem is.

I take care of all the random boring tasks that need to be done, so that the developers can keep working.

#2 Keep everyone pointed in the right direction

If you leave a developer to his own devices totally unmanaged, he starts working on various "science projects" that waste time, and distract from the final goal (a working, shipable project).

I make sure that what the developers are working on is actually what we need to get out the door.

#3 Double-Check Everyone's Work

I spot-check everyone's code regularly to make sure that everything is structured and organized.  If I can pull open a source file at random and figure out what it's supposed to do without too much head-scratching, then the code was put together properly.  I also to a more complete inspection when it's ready for release.

I try to compile and install the Release Candidate and make sure there are no errors or warnings.  I play around with the software, make sure it works as I expect it to.  I don't do a complete test of every use case (that's what the testers are for).  I just give it a once-over to make sure nothing's missing.

I proofread the manuals.  I make sure all the documentation for ISO9001 is in order.

#4 Get the developers whatever they need

If we're out of pens, or dry-erase markers, I make sure the purchasing guys know.  If the printer is out of paper, I change it.  If a developer needs a particular piece of software, I make sure he gets it.

If we're using a particular tool that's a pain in the ass to work with, I look for a replacement (including calling vendors and evaluating trial copies).

#5 Make Sure the Rules are Still Useful

We have some formal Software Development Guidlines.  Eveything we write should follow them.  I make sure the guidelines don't get outdated.  I make sure they're actually useful and worth following.

#6 Evaluate Employees

Make sure the people who deserve raises get them.

#7 Interview Candidates

Myron A. Semack
Monday, March 29, 2004

Psychologically, people tend to notice flaws more in people who control important aspects of their lives.  This is why you can get along with and enjoy horribly messed up people; their negatives can become positives.  But imagine that person being your boss or someone critical to your project's success...

BTW, I hope no one casts me as a "manager apologist"; this is just an observation, not an explanation.  I have my own private thoughts about management, but no idea if my experiences apply to anyone else's.

Tayssir John Gabbour
Monday, March 29, 2004

Myron - you are setting a gold standard for managers. I wish there were more like you!

Mister Modem
Monday, March 29, 2004

Myron,

Where do you work? ... just so i know where to apply :)

Is the CV holding up?
Monday, March 29, 2004

Philo,

Software people *are* special, because many software
projects are disguised Research&Development projects.

R&D is fundamentally different from production work,
like making hamburgers, laying bricks or stacking shelves,
which are routine and mechanistic rather than being
creative and unpredictable.

R&D type work is unusual, elite work with different
constraints than the normal jobs that bosses are taught
how to deal with in MBA school.

Bosses should not be treating their elite workers the
same way they treat burger flippers. Otherwise, (unless
there is a recession) the best Rocket Scientists leave and
form their own companies, abandoning their employers to
their fates.

See Juno, Fog Creek.

Ali
Monday, March 29, 2004

KS, you've bought the whole story, haven't you?

> developers are lousy planners - that's why - ALL software development schedules are ALWAYS wrong - all software releases are delayed and over extended because the Developers have no clue of when they will finish what they think they can finish.

The reason schedules are always wrong and releases delayed is that DUMB people create and impose those schedules without a clue as to the activity they're trying to manage. Those dumb people are your typical manager and Project Manager (certified.)

See, the big problem is that companies think it's management that's required, when it's actually *software* management that's required.

Must be a Manager
Monday, March 29, 2004

OK Myron, so you're not a baffoon (although you're an unfortunate misspelling away from being a moron).  But let me contrast you with one particularly egregious baffoon manager I have in mind:


1a. When some senior management has some time-wasting one-man project, baffoon calls a meeting of all the senior developers to discuss the architecture of it.  Then assigns use case analysis to one guy, UML diags to another, then after its all done, gets the DBA involved who gives a reason why it can't be implemented on the current schema and why the schema can't change for another 6 months.

1b. When a customer calls with some complicated problem, baffoon is the last person to know.  First the salesguy (account manager, whatever the heck he's calling himself today) comes roaring into the developer pit like he's got fire ants in his pants, grabs the first developer he sees and chews his ear off until he gets a committment from the guy to fix before he leaves that day even it means pulling an all-nighter. 

1c. Baffoon is oblivious to random boring tasks to be done, luckily though we had a developer who created a niche for himself doing nothing but random boring tasks (plus SCM).  I think that's masochistic, but we all loved the guy for it.  Maybe it seemed like a step up from his previous work at a defense contractor.

2a. Rather than keeping everyone pointed in one direction, baffoon lets everyone pull in their own direction.  For every feature, he'd schedule a meeting.  The "Software Architect" would propose some grand RUP inspired object model with tons of objects, and levels, and packages and methods, that would take an army to decipher let alone code.  The "Performance Guru" would propose one giant function with single letter variable names and all the data stored in LDAP.  The rest of the developers would find excuses to leave the meeting, go back to the development pit, and usually have a reasonable solution designed and coded by the time the meeting officially broke up.

3a. Baffoon never looked at the code, except printouts at formal "code reviews" which occurred often enough to be annoying, but not often enough to have an positive effect on the code base.  He didn't have CVS or a compiler on his machine, so this limited his ability to check code.

3b. Baffoon never inspected the product neither, a fact confirmed on numerous occassions by the NetOps guy who would have to go fix his computer everytime he put a window on his second screen at home, but then couldn't get to it at the office because he only had one screen and his video drivers weren't smart enough to move windows that were completely off-screen.  Baffoon never had the product installed on his machine.  The only time he saw it was at demos.

3c. Baffoon never proofread manuals.  I verified this by embedding things like "Hey Alex, are you actually reading this piece of crapulence?" in the third or fourth paragraph in his copy of everything I ever wrote.  Never heard from him once.

4. If we ever needed anything, he encouraged us to prepare a document explaining the need, and comparing, contrasting and pricing several tool alternatives to solve it.  Then once that was prepared, baffoon would dutifully remove any identifiers that indicated it was prepared by anyone other than himself and pass it along to upper management.  I found this out when I meant to cc the CTO a copy of one such proposal, forgot on my initial email, so did it in a second email.  Since baffoon didn't know that CTO already had a copy of my report, he simply replaced my name with his and submitted it to CTO. 

Most proposals were denied for being to expensive.  The others were denied because they used an open-source tool which, being open-source is (in his view) "unsupported".

5. As for rules, the only rule baffoon ever was involved in was creating a "core hours" rule that said we had to be in the office from 9:30 to 5. 

6. He evaluated employees!  So we got one of the positive side.  Then he would explain how times were tough and there was a pay freeze in place.

7. He selected candidates to interview.  He gave them the prelim interview (the one HR would do in a normal company) then a developer teched them.  The candidates he brought in were stumps.  The only gems we got were from people who were already known by developers already on staff.  If there was a bad resume in a pile, he could find it without fail.

YES, he really was THAT BAD!

Maybe its cause he was short and bald?  If only he had good hair.

Ugnonimous
Monday, March 29, 2004

Philo, your spiel on this subject is typical of those without serious development background. It incorporates the cherished management ideals that results can be obtained just by using the right "encouragement" and "incentives."

This can work with sales, but not with development, where six months C++ development really does require six months. That's the difference.

Must be a Manager
Monday, March 29, 2004

Forgot to mention:

Baffoon would measure his productivity by the number of hours each day he spent in meetings.

Ugnonimous
Monday, March 29, 2004

Excepting maybe research scientists and mathematicians,  compared to every smart programmer, nearly everyone else *is* an idiot.  Why else would business schools be so full?

Han Este
Tuesday, March 30, 2004

Ugnonimous:

Beautiful women often tell me that they have trouble finding genuine partners. Why ? Because men hit on them for fun, because it's macho, they wolf whistle, they fantasise. But when the woman is interested what happens. They all run away terrified. They think they aren't up to it, or that they will need to commit or deliver in some other way. What happens then ? They usually gather round and start to bitch about the woman. "Great norks, but a ballbreaker". Management is the same. Lots of people have theories, lots of people can "do it better" but when the crunch comes, most people haven't got the balls. This is why managers and husbands of gorgeous women are often middle aged balding smug guys who happen to have the guts to deliver.

Woodentongue
Tuesday, March 30, 2004

If developers tech the candidates, why are they stumps ?

btw

I agree that Your example is an idiot. If he takes credit for your work, there can be no redemption. So, why haven't you hauled him down ? Are you worried that people will think you are a buffoon too ?

Woodentongue
Tuesday, March 30, 2004

My "middle manager" is a great person. He's totally brutal about his opinions, which at first scares people but when you get used to it it starts to feel very good, because you always know that he says what he thinks and you don't have to waste time thinking about what might be going on behind closed doors.

He also puts up with my personality amazingly well, and I do consider myself quite childish at times. For example, I can waste half my day loitering around the city (it's a beautiful sunny spring day - who'd want to sit inside banging some stupid code?), and have beer with friends and go to a guitar shop and jam away while I should be working, because he knows that sometimes I am bored on weekends and do a lot of work. He seems to see the big picture very well, and I really really enjoy the freedom it gives me. You'd have to pay me a whole lot more than what I make now, to leave this place.

Oh, and he lets me borrow his Mercedes C270 sometimes - woo hoo, that's a pretty neat car!

A very lucky programmer
Tuesday, March 30, 2004

At one meeting I attended, my manager once got in a heated argument with his manager as to whether we had "spent five weeks doing nothing" or "spent three weeks with nothing to show for it, after team B had spent two weeks producing no tangible results either because they did nothing or because they also had nothing to show for their effort".

Technically, this was defending his team to senior management, but it wasn't the most vigorous defense that I've heard...  very precise though, and he didn't give an inch.

Gustavo W.
Tuesday, March 30, 2004

> My "middle manager" is a great person... Oh, and he lets me borrow his Mercedes C270 sometimes

If he was really a great person, he would pay you enough so you could buy your own Mercdes C270, you idiot.


Tuesday, March 30, 2004

anybody who generalizes about managers or progrmammers is a clueless buffoon.

Excepting people who generalizie aobut people who generalize about managers and programmers of course :)

Stephen Jones
Tuesday, March 30, 2004

"If he was really a great person, he would pay you enough so you could buy your own Mercdes C270, you idiot. "

LOL ;-)    Good catch! But to be honest, I wouldn't want to own a mercedes, it's too "middle manager" like for my taste.

A Porsche, maybe.... Hmm, I think I have to ask for a raise!

A very lucky programmer
Thursday, April 01, 2004

What medium-sized (20,000 to 200,000 lines of code) projects need is a project secretary, one who calls meetings, takes notes, updates trivial documents, and collects data for reporting.

Now, MANAGING the development requires a software professional who can understand how to cut the right features at the right point in time, can delegate the proper tasks to the right people, mitigate risks with a focus on the product at hand, and understand how the requirements are magically transformed into working pieces of code. Such a manager has a deep understanding of the people, the processes, and the technology.

Why aren't there any of those about?

Spork
Monday, April 05, 2004

*  Recent Topics

*  Fog Creek Home