Fog Creek Software
Discussion Board




Dealing w/ Ignorant Software Managers

As professional software engineer, we all are constantly studying software engineering. We study new technologies and practices all the time. I get extremely frustrated dealing with managers who just seem to be plodding along resting on their past experience to guide them in their managment work.

I've read several books and articles on software project management, including much of the Microsoft Best Practices series, Extreme Programming Explained, and everything Joel has written. I know I've only scratched the surface but that's not the point.

The point is there are TONS of good ideas backed up by scientific research and broad anecdotal evidence which have been around for a decade or two or more! These ideas SHOULD be conventional wisdom by now but they're not -- because many software managers do absolutely nothing to make themselves better managers.

I make suggestion after suggestion but they are typically only lukewarmly received. It actually gets pretty tiring constantly trying to train my managers on software management! :)

What do you folks think of those statements and what can we as engineers do to improve the situation?

David Mooney
Wednesday, September 04, 2002

I gave up trying to fight bad mgmt.  Find an firm with competent managers.  It makes your entire work experience night vs. day.  Seriously.  I can now spot bad mgmt from a mile away.  Working for bad mgmt is one of the worst situations you can be in b/c the side effects manifests itself in dozens of ways, including:  death march hours, poor recognition of quality work, dissatisfied users, demoralized team, poorly planned projects, TONs of wasted effort, medicore results, etc etc etc. 

Or, become a consultant.  Suddenly, many of those thing instantly become pluses!

Bella
Wednesday, September 04, 2002

Just wait until you are a manager - you will get tired of all these young inexperienced kids coming to you with the latest hoo-hah that is the same junk you've been seeing for 20 years with a different bow on the package.

Seriously, though - change involves risk.  Managers don't like risk, and for a good reason.  Doing everything "the old way" may not be exciting or even optimal, but at least you know what the results will tend to look like at the end of the day, instead of sheepishly admitting that you hadn't seen all the blind corners you ended up running into.

There are two sides to this coin, my friend.

Bob

Robert Anderson
Wednesday, September 04, 2002

I agree with Bella, I became a consultant. I get frustrated too, but my hourly rate has a frustration cost built in to it, and if its too frustrating, I can also just change my mind and go with the management decisions while the cash registers just keep ticking over.

Tony
Wednesday, September 04, 2002

Bob,

I don't think managers are considering these techniques and then dismissing them as too risky. I think they are just too clueless to care or even recognize there is a problem that is solvable. I think you have to realize that there is a problem before you want to work on a solution. And most of the time, they don't realize there is a problem...or sum it up to, "well, that's software". Or they just don't care enough or are too stubborn to change anything. It should be the manager learning something and then applying it to his team. But we never get that "manager learned something new and he wants to try it". Ever.

Managers don't seem to want to improve or change or get better. Because why? Because change requires extra effort? Several of the managers I've worked with work their ass off, putting in tons of hours. The I don't think they're afraid of effort.

I just don't get why managers won't try to improve their management skills.

Bella and Tony,
I also want to take becoming a consultant off the table. It is a reasonable way to solve the problem personally, but it doesn't answer the question as to why managers behave this way.

David Mooney
Wednesday, September 04, 2002

"But we never get that "manager learned something new and he wants to try it". Ever."

One way to deal with it (unfortunately not appropriate to every situation) is to just do it anyway. If it works, your manager can't complain very much. If it doesn't work, then perhaps they were right.

"Managers don't seem to want to improve or change or get better. Because why? Because change requires extra effort? Several of the managers I've worked with work their ass off, putting in tons of hours. The I don't think they're afraid of effort."

No, they're certainly not afraid of effort. But they might be afraid of change itself. Peopleware has an amusing little poem at some point, something along the lines of "People hate change / And that's because people hate change.  / I want to be very clear on this, people hate change. / They really, really do".

Why is this? Well, new stuff can be scary. Also, if your subordinates are using things you don't understand, that severly undermines your managerial power to make decisions. And if you change a process and everything works much better, that implies that the old process was inefficient, which implies that all along the managers haven't been doing their job very well.

"I just don't get why managers won't try to improve their management skills."

Fear. Fear of being seen to be still learning. Fear of losing authority.

Also, fear of the sheer amount of work involved in changing. It really does take a lot of effort to change how things "are done around here".

Adrian Gilby
Thursday, September 05, 2002

"The point is there are TONS of good ideas backed up by scientific research and broad anecdotal evidence which have been around for a decade or two or more! These ideas SHOULD be conventional wisdom by now but they're not -- because many software managers do absolutely nothing to make themselves better managers."

You are probably right David, give us one or two ideas in this category which illustrate your point.

Cheers,

Tony
Thursday, September 05, 2002

Well, I would at least get the manager a copy of PeopleWare. That would help a lot....

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

Albert D. Kallal
Thursday, September 05, 2002

"TONS of good ideas backed up by scientific research and broad anecdotal evidence"

I would take a lot of that with a big grain of salt. Most of these works, even the stuff you mentioned, contradict each other to a great degree.  In fact most of it contradicts itself as well. Why is this? Well, to sum it up, "that's software project management theories". By no means does it make it useless, just I would really avoid thinking of almost any of it as science (esp XP!).

Never underestimate the value of a broad consensus and working code, as they say. Having a better technique does not automatically mean you have a valid reason to change somerthing - most managers know this well I would guess.

Robin Debreuil
Thursday, September 05, 2002

Most bad managers will not improve because they (a) are not interested and (b) are not able to.
As for the (a) part: in many organizations you climb the latter not but your achievements, but through whom you are friendly with. The "best" managers in these settings will not waste time on trying to get better results, but on rubbing shoulders with the senior brass.
(b) As I have argued before, I have observed that in our sector with its very short half-life of knowledge, managers that let go of tech issues completely to focus on the "managerial aspects" quickly loose touch beyond the point of recognition. Often this is reasoned away by "moving to a more abstract level where truths last longer". Most often this is pure BS since it assumes a structure of the development problem space that has clean separation between the different aspects and levels.

Just me (Sir to you)
Thursday, September 05, 2002

I think there are many ignorant software managers out there. I have met them. I have worked with them and  on occasion I have been one myself.

Let's face it, the blame comes down on both sides. When you look at the sheer numbers, well, there are many more developers than managers - so one could say there are plenty of really poor developers: Developers who think they know everything (and they learned it in 21 days); developers who do design work - in their heads - and won't discuss things with the people they have to integrate with; engineers with no ability or desire to communicate with others or give appropriate respect to non-technical people on projects; and then the folk who refure to documents anything ("read the code!" is their rallying cry).

Bashing managers is never going to stop - and there will always be more bad managers. Likewise there will always be great managers who say if "I would trade this team of fifteen for three really good developers and be done in half the time with better quality, more features and better documentation.

Bottom line, good people are hard to find. A great project with a prospect of success and a great team of developers and managers is rarer still. Finally, a great company that has great projects or products with great teams are virtually impossible to find. Add great clients to the mix and you have a one in a million situation.

Leadership isn't conferred with a title, great projects and team start with you - think beyond the hierarchy - you can make all the difference.

Nick Katsivelos
Thursday, September 05, 2002

The problem is that developers like experimentation, and a manager has to factor this in.  In fact, engineering is a way for an organization to learn about new processes, so it's usually good to use a new process or two in a project.

Maybe DeMarco is right and managers in large companies have to choose to be professional managers, with whatever p/maternalism that requires.
http://www.systemsguild.com/GuildSite/TDM/Professionalism.html

But dealing with ignorant managers...  Well, what is the way to deal with stupid people in power?  Find their weaknesses (politics), target enlightened managers, or take advantage of stupidity for fun & profit.

But you know, I've seen people who want everyone to adopt their New Methodology in mid-project.  Usually the names Kent Beck and Erich Gamma are not far behind...  I think there is an art to being a change agent, because while you may feel like Prometheus bringing fire from the gods (I've probably done this), people usually don't change unless there is an obvious problem.  Perhaps it takes extra work, because a) your work has to be respected and b) you have to slip in these changes without much pain to others.  You have to take your cow-orkers as customers, and see how their work becomes easier or nicer as a direct unquestionable result of the new Methodology.  And it should be opt-in until many start using it so stragglers must upgrade too.

Sammy
Thursday, September 05, 2002

I think it's partially a respect issue. You expect your managers to respect you and listen to suggestions for improvements when you spend your time slagging them off on message boards? I don't think so. Respect is a two way process. Perhaps if you showed them more respect, they would do likewise and you could move forward. Alternatively you can carry on bad mouthing them forever and nothing ever changing.

It's always too easy to blame the managers. Maybe you people should take a look at yourselves before you blame others.

Yanwoo
Thursday, September 05, 2002

This has been my experience over the last 7 years:

If something goes right, the manager takes credit for it.
If something goes wrong, the manager blames the developers for it (more frequently the 'lead' software engineer).

This has worked every single time.  The higher-ups have come to 'realize' that developers don't know what they are doing, and that's why projects fail so often.

Why would a manager want to change such a sweet setup?

Sven Galli
Thursday, September 05, 2002

If something goes right, the developers takes credit for it.
If something goes wrong, the developers blames the manager for it.

I'm not trying to take the side of managment here, sorry if yours is a dick. But I've been on both sides, in programming and non programming enviroments, and I would say:

a) it is common to hear a manager say the project's success was because of the team, it is much rarer (though not unheard of) for a developer to say that the manager was the key, even when they were.

b) When thinks go wrong it is pretty common for a manager to say something like, "mistakes were made, some of them mine, blah blah", where it is almost unheard of for a developer to say something like 'I made some real sloppy bits that really made it hard to build on' or 'it was too difficult for me' or 'I guess I was wrong, catching exceptions are important after all'.

One thing that both sides seem to have in common - it is not always the most competent that complain (about the other side) the loudest! That goes for client/contractor relations too...

Robin Debreuil
Thursday, September 05, 2002

Bella has the right idea.  Changing your current management is probably futile effort.  You need to find an employer with good management.  Or start your own company.

But how many people who do software development make any effort to find out about the quality of the company when they go out on a job search?  During the dot.com/Internet bubble expansion the goal was get-rich-quick.  Companies were trying to grow fast and have an IPO so the founders could get rich. Employees looked for lucrative stock options.

Right now the economy is in terrible shape so any job is a good one.  But at some point things will improve.  If developers start asking about the work environment they'll have some chance of improving things.

mackinac
Thursday, September 05, 2002

Come on, Robin.  Nobody gives a crap WHAT the developers think!  They can blame the moon for all upper management cares - they're not on the board & they don't have to answer to them.  Programmers have a right to blame a lot (not all) of their problems on management.  SOMEBODY has to take the heat.  Who should that be?  Whoever is in charge.  If programmers are in charge and running the show, then they should take the heat, otherwise, it belongs to the managers.

semi
Thursday, September 05, 2002

"b) When thinks go wrong it is pretty common for a manager to say something like, "mistakes were made, some of them mine, blah blah", "

Certainly true, but rather more true I think when the boss is talking to the team than to their own boss.

RH
Thursday, September 05, 2002

In the short term developers are justified in blaming management for software development problems.  Managers make the high level decisions that affect the overall work environment.

You might argue that really good developers should be able to produce high quality code in any environment, but I'd want to see some kind of proof.  Recall that in the Coding War Games reported in Peopleware the higher scoring developers tended to come from the same company.  This is an indication that some companies provide a better work environment (or maybe they're just better at hiring good developers).

In the long run, developers can blame themselves for not making the effort to find a job at a better employer.  Although, admittedly, those places are really, really rare.

mackinac
Thursday, September 05, 2002

Well thats true that the manager should get the blame, but then don't be suprised if he/she want to make the decisions too ; ).  Mostly I was suprised once managing how dumb some of the ideas coming up looked - when I myself used to get pissed when people didn't want to listen to me with the very same type of thing. I think most developers aren't focusing on the overwhelming need to get a result. A perfect result is always better, but it isn't usually worth risking the project to acheive. Most of my managing perspective comes from animation, but its the same idea (thousands of hours can be lost to a seemingly good new idea that isn't all its cracked up to be, or even one that just didn't work out...)

Its is a good point that managers probably tell 'their' bosses something else - I've never worked with more than two tiers though so its never affected me personally... Still you see a lot, even on websites, of managers taking some of the blame/ doleing out credit, much like a sports coach. Once in a while you hear people say they had a great manager who made a huge difference - people who can see that (when its true) are gems.

Robin Debreuil
Thursday, September 05, 2002

I agree with Robin, and add that perhaps it's more important to persuade your fellow/peer developers to agree with you than it is to persuade your manager.

Christopher Wells
Thursday, September 05, 2002

Fear of change = Outdated tech skills = Perfect management material. 

Theory:  Managers who are ex-programmers who simply never updated their skills are the types who hate change to begin with. That's why they're managers.  So this may not be as random as it initially appears. 

I used to hate running into Powebuilders programmers circa 1998 who STILL refused to admit PB was DEAD.  They insisted that everything could be done via Powerbuilder, even database exports!  Unreal.  All mgrs now.  ie:  Useless as programmers.  And they probably still hate any change from their nice safe comfort zone.

Bella
Thursday, September 05, 2002

So Bella,

You don't subscribe to the notion that ex programmers make the best managers? 

Sven Galli
Thursday, September 05, 2002

I think he believes that managers should occasionally "get their hands dirty."

nonanon
Thursday, September 05, 2002


Good management is about removing obstacles so that the team can succeed, and good managers care about people. There are too many people in management roles who don't  actually want to see other people succeed. If you feel that your manager doesn't really want you and your team  to succeed, then it's time to leave...

Gordon Taylor
Friday, September 06, 2002

I was in this exact situation. I work for a small company whose owner is an excellent software development manager. Because of his skill, the company grew and hired more developers and two new managers to run the projects. Both of these managers were useless. Immediately our projects went wildly overtime, our bug count went up, the quality of our software went downhill and our customers were unhappy. This even happened on projects that didn't have any of the new developers - so there is no question about the cause.

For months I also tried to educate the managers as to some processes that might fix the problems, but they were not interested. When reporting to the owner, they blamed the developers for the problems.

One day, a collegue and I managed to sit within earshot of the owner and we proceeded to discuss in a logical and rational manner the problems that we were having and how they could easily be solved with better management. The very next week, the two managers are being sent to training courses, being asked for detailed status reports, being asked to produce plans before starting projects, being forced to ask developers for opinions on approaches to projects. The company is doing much better now.

So how do you educate managers - you can't - you have to get their manager to force them to educate themselves.

As an aside, I like working here, but if this problem hadn't been fixed, I would have found work elsewhere.

Rod
Friday, September 06, 2002

I meant that outdated programmers tend to resist change.  They made bad programmers (in that regard) and will carry over that negative trait into mgmt.

"Best programmers" may be an overstatement.  but I certainly agree that ex-programmers bring a crucial perspective to management.  Working for a manager who has never ever coded usually sucks (uness he knows that shortcoming, and adjusts accordingly). 

In the Powerbuilder case, of course, their knowledge of GUIs and RDBMS and most likely business knowledge will help their mgmt success greatly. 

Bella
Friday, September 06, 2002

Folks, you can't have it both ways.

Either your managers are going to be a "former" programmers or you'll get stuck with totaly non-technical managers who came "up" from marketing or finance.

If your "manager" is the technical team lead, who is expected to roll up his sleeves and program with the rest of the gang, then he had better be a solid techie.

If your manager is running a larger project team (more than 5 techs) it is unlikely that he will have the time to roll up his sleeves because he's going to be busy keeping the next layer of management and/or the end-users off your backs so that you can get your job done.

Be glad you get someone who has paid dues in the trenches. I've had to work for clowns right out of B-school and marketing hacks whose only prior real-world experience was selling vomit bags to airlines.

I'm a PM. I try to keep up with the technical matter but it's only possible up to a point. I can't do my job and stay on top of the ever evolving tools and technologies. That's why I don't make arbitrary technical decisions. I ask the techs to teach me the newer technologies. Not so that I can do their jobs, but so that I have enough baseline knowledge to perform my job effectively.

When there are technical issues to resolve I work with the programmers to resolve them. I own the decision making process, but not the decision (unless there is a deadlock and I have no alternative).

I also deal with all the stuff that the developers usually hate: requirement gathering and documentation, status reports, project plan, budgets, endless end-user meetings, risk management, test plans, etc., etc.. You get the idea.

If your manager is ignorant of the technologies you are using, offer to explain them. If your manager is doesn't know how to manage, try to point him in the right direction (gently). Otherwise, you're out of luck, so CYA applies. He'll go down in flames sooner or later, just be sure to out of the splash zone when he hits and be ready with a recovery plan for when the fecal matter hits the occillatory membrane.

Tom Dratler
Sunday, September 08, 2002

I agree with Gordon Taylor, Rod & Tom Dratler.

However Tom's MBA crack is really a symptom of a larger problem that really got bad during the past 7 years.- teams that were infiltrated with people who did not adhere to the prime directive -  be passionate about designing, building, testing, shipping, supporting and upgrading qality software that delights everyone who comes in contact with it.

An MBA who is totaly into software can be a tremendous asset for any technical endeavor. It shouold be expected that they are always reading up on the latest management approaches and ways to lighten developers roles and improve quality and maintainability. The MBAshould be fluent enough in the dielect and practice of every discipline that comprises a development effortm (UI, Software architecture, documentation, pricing, scheduling, testing and customer service)

But as I implied above, the "no passion problem" is equally prevelant in the developer ranks. Sometimes it's rampant. In my expeience with larger teams, the folks coallesce into a few groups:

A small group that will flatly refuse to alter their workstyle and offer no alternative manner for them to get to the quality level the firm expects.

There is also a contingent that says nothing. They never complain. They never celebrate. When asked what the most important part of their piece of the project is they reply "everything". When asked what will make your life easier, they repond with "nothing".

Then there are the guys who want to follow the most esoteric approach.

Finally you have the part of the team that I like. The folks who are opinionated but more dedicated to learning through exploration that they are to the ideas they bring to the table. The folks who understand that it is a multi-disciplinary effort and everyone is valuable. The folks who want to talk it through to make sure that the best thing gets built the best way in a sane manner.

So, I would like to reiterate the fact is that someone may be the boss but that by no means makes him/her the Leader of the team. If you have great leadership  (could be a junior developer) and a dedicatited communacative team that produces the product the boss is asking for, then you have the boss marginalized - and he should realize that he just got handed a gift, so he better say thanks to the team and sing their praises up the line. If he forgets to do that, be sure and clue him/her in - he or she may just not understand.

Finally, the solution is in your hands: fix it or quit complaining. If you are miserable, but unwilling to take on the challnge of organizing at the grass roots level and being or finding a leader - then you are likely to be unhappy in most teams. Remember that people with a positive attitude are the ones who get picked to be on the good teams. No one want to pick the complainer.

I think there have been some really helpful and toughtfull comments on this thread - I would be great to carry on this conversation face to face. Perhaps some day.

Best,
Nick
www.katsivelos.com

Nick Katsivelos
Wednesday, September 11, 2002

When I am in a same company and make a proposal I get: "That's for big companies.  We're too small to do that."  When I am in a big company and make similar proposals I get: "That's for bigger companies.  We're too small to do that." When I spend a week at company company doing stuff that normally should take me a day or two from past experience, and I propose organizational changes to support that day or two turn-around time, I get "we don't have time to do what you want".  Don't have time?  OK, I'll continue to spend 9 months doing work that should have been completed in 4 months because you don't have time.  I always hear the "we don't have time to do that" excuse....well, in my experience in nearly all cases, you don't have time *now* because you failed to take appropriate action 6 months ago, or a year ago, or whatever.  So here we are *now* and 6 months from now we can be doing stuff in a day instead of a week, or we can keep doing the same stuff in a week and bitch that "we don't have time".

Quite honestly I truly feel after 10+ years that many more times than not it's really: "But your idea is new (to us), and we fear new things.  Therefore it must be rejected."

Stu (my boss may be watching; this should tell you something too)
Sunday, September 22, 2002

*  Recent Topics

*  Fog Creek Home