What's the single biggest reason Senior Executives tolerate poorly-performing software development projects and teams?

Question

Many senior executives of businesses that rely on custom software - within their products or underpinning their company's services - seem to tolerate or avoid tackling long standing dysfunctionalities in the projects and teams developing that software. In your personal experience, why should this be so?

Answer 1

To them they might not be poorly-preforming. If the team is making money for the company then even though them may be outputting garbage that crashes all the time the execs may not really care.

Answer 2

It takes time to fix the dysfunction. Time = money, and many people don't realize that the initial hit of fixing things usually makes up for itself in a short period of time.

Answer 3

Depends on what you mean "poorly", but 90% of time, the reason that raw / bad software goes through is because there are deadlines to meet. You can only postpone them so many times before it becomes a "now or never" thing. In two words:

"Deadline and Bottomlines"

Answer 4

There are two answers:

1) The manager is too weak to take on the tough eye-to-eye meetings with each team member that is underperforming (which may be caused by the manager being unable to prioritize, understand or care about the business needs that the team need to address).

2) The team is contributing enough to the overall business needs that they are being paid for, but the manager is unable to explain the business needs to the team members so that everybody knows what is being expected of them. Many development projects that fail have been managed without any real measurments of progress against the needs that are being addressed.

Answer 5

Because they don't know any better.

Answer 6

I'm not sure that you can make a blanket statement that it's "Many" (unless you have research to back this up) but I think it definitely does happen.

If I had to guess, I would say that the biggest factor is ignorance. Much like how sausage is tasty, but you don't want to see what goes into making it, many non-technical execs are only capable of judging these things on their outputs and prefer to remain ignorant of the process.

If the tech team gets something out that works to such a degree that it's better having a slightly dysfunctional solution, rather than no solution, and that spending another 50% of the dev budget won't result in at least a 50% improvement in output, most accountants will be happy to make do with the dysfunctional part-solution.

See also Satisficing.

Answer 7

There may be aswell a lack of control to evaluate the performance of the IT team.

If the team do their best, their could be a lack of training, short deadlines, customers always changing the scope of the project, etc.

Answer 8

I've noticed a huge gap between developers and the management they work for. What my boss says is "sometimes we don't need to build a Cadillac", suggesting that a simpler built solution is what the company needs to operate right now.

I'm an advocate of free and open source software whenever possible, and our company is an advocate of using FOSS software (although prefers those supported or warrantied), however the simple idea of releasing any of our projects to the general public is downright rejected.

Making a project for the masses is a good way to keep it from hard coded passwords and patchy "goto's".

Making a project patchy and proprietary does guarantee some things for the company... it guarantees mayhem down the road, and helps form a sort of "Super Hero" out of an undeserving employee.

-Tres

Answer 9

There is no answer to this question because the premise that "many" teams are dysfunctional is incorrect. In my experience, most executives do not tolerate or avoid tackling long standing dysfunctionalities in the projects and teams developing software because, in most cases, these dysfunctions do not exist.

Answer 10

Few companies are willing to cut their losses, realise it's a mess, and STOP the project. They see the $100K they have SPENT, but not the $500K more that they are going to have to throw after the project to finish it properly.

This is usually caused by someone not wanting to tell their more-senior people that something went wrong. "no no, it's fine, we just need a little more time and money".

Sometimes it's cheaper to just kill the project than it is to finish it. I have way more respect for anyone who can objectivly step back from "their baby" and just kill it when it needs to be.

Obviously, this doesn't apply to actual PEOPLE - killing people is bad, mmmmmkay?

Answer 11

If they kill the project, their budget will be taken away.

If they kill the project, it will be admitting to a failure which will cause them to lose face.

Answer 12

We (the software industry) have trained them not to ask questions or they'll get gobbledygook answers followed by belligerence if they press. The common overreaction to this is to make unilateral demands on the developers. What I shoot for is dialog. It's seldom easy, because I have to translate what I know into language they can understand. It's scary, because my flaws are exposed. It works out better, though, as I'm reminded every time I change back.

Answer 13

Many senior executives ... seem to tolerate or avoid tackling long standing dysfunctionalities in the projects and teams developing that software

They think there's something more important to work on, generally a short-term goal. Their choice of which short-term goals are higher priority than long-term goals often differs from the people writing the software. So either there is a manager between you and them who is also misinformed, or they trust their own judgment more than yours on technical issues.

An interesting question is, "How do you distinguish between competent employees working on a very difficult task, and incompetent employees bungling an easier task?" You need technical skills, or to trust someone that you believe has technical skills. Management doesn't have technical skills, so they have to pick someone to trust. And how do you pick someone to trust on technical matters, if you yourself don't have technical skills? Easy, you just pick whoever is highest on the Org Chart, some middle-level manager. However, the set of selection criteria for moving up an Org Chart isn't the same as the skills needed to successfully develop software.

It's much easier to mock managers for their failings, then to suggest a way for them to fix their problems. Unless they abdicate ultimate control of product development in favor of someone more technically competent than them (who may lack in business/management/interpersonalCommunication areas), they are kind of screwed. And people very rarely give up whatever amount of power they've managed to accumulate.

My interim solution to this difficult problem that plagues humanity is to not work at companies with more than 15 employees.

Answer 14

as usual, "it depends" -

some executives are reulctant to admit failure, any failure, due to loss of face with other exectutives, loss of budget, loss of 'headcount', etc.

more common is that everyone below them lies to their superiors so they don't actually know that anything is wrong

example: you, in the trenches, see a dysfunctional team with low morale, poor tools, contradictory specs and goals, irate users, unreasonable/impossible demands, and a project that is in a fast death-march to utter failure. Do you tell your team lead this? Does he tell the project manager? Does the PM tell the Dept. manager? etc? Probably not.

so at the senior-executive level, if he/she is even aware of your team's existence at all, he/she probably only knows that your project is 'a little off schedule', if that.

Answer 15

Many times I have found that it is the senior executives who create the problems that lead to poor software and poorly functioning teams. They then reinforce their belief that software is supposed to have bugs and that programmers are lazy and have to have unrealistic goals and deadlines to make them work harder.

The senior exec team sets the environment and goals. The lower level managers and developers work toward that.

Studies show that developers will generally implement what is asked and do it well. Where there are conflicting requirements (even unspoken ones - like "get it out the door as fast as you can and we'll fix the bugs later") they do what they can/have to do.

There are well-known best practices. Those that ignore them do so at their peril.

Do not blame the developers. Blame the management - that is what they are there for. If they cannot lead a development group, then they are in the wrong business/profession.

There is a host of literature out there on this,

Peopleware is a good place to start.

The DeMarco, Yourdon, Lister, et.at crowd have bludgeoned this topic to death.

Answer 16

If I had to pick a single reason, it would be this: the problem is with the engineers, not the executives.

The responsibility for advocating change lies with the engineers on the teams, not the senior executives or upper management. Their responsibility is to take accept and business cases and make an informed decision between the proposed options (which may or may not be your first choice).

So here's the punchline: if you think you know of a "long-standing dysfunctionality" in a project or team, document it, research some of the options to address it (stackoverflow is only one of the forums available on these topics) and put together a business case to solve it. Document the risks and rewards, the costs and the benefits and put together the explanation as to why the investment of time, money or general frustration will be worth it.

Worst case: things don't change but you've learned how to produce a business case. Best case: you were part of a solution to a long-standing problem.