Engineers and Management

Originally send to sage-members

Version 0,0 / July 17, 2002

> How common is it for senior management to make engineering decisions,
> overriding the engineers?

Fairly common. In good groups, ~70% of the time it has been a good thing. In average companies ~40% of the time it was a good thing, and in places that were pretty broken approx ~5% of the time it was a good thing.

The question is, how good is senior management and why is this happening. There are three common reasons why an engineer might get overruled:

1) Engineer came up with something that is wrong or short-sighted

Sometimes the engineer is just wrong and their management has to stop them before everyone regrets the results. I have done this to people who work for me, I have had it happen to me. It's better if there is involvement *before* something have to be overruled, but things aren't always caught.

In some companies senior managers have many years of experience working as an engineer. They have build numerous systems, been bit by a wide variety of bugs, made countless bad decisions which enables them evaluate decisions effectively and see long term implications others might miss.

The best way to avoid this sort of problem is to have design reviews before huge amounts of time are invested into a project, and people need to learn not to get too attached to ideas... sometimes they are wrong.

2) Bad Specifications

This is typically a management bad. There are a number of things which could cause this:

This is very common unless there is a strong product management team in place. For a project to be effectively completed you need to capture and weight issues like what reliability is requires and how does this design effect reliability? What about efficiency, deployment cost, etc? Do the customers want this feature? etc. Everyone should understand and agree on these things, and what the appropriate utility function (e.g. sometimes reliability is more important than a new feature).

A common example of this is that the engineer designs a great system which is over-engineered because there weren't clear specifications and requirements. e.g. a design which could scale to say 10k transactions/sec with a 99.99% avail., but the most aggressive business growth plan says that in the next two years the system only as to support 3k transactions/sec with an avail of 99.8%. The engineering design is a factor of 12x the cost of the system which would met the requirements (and assure profit margins). This disconnect could be that no one set the avail metric until after the design was done, or sales promised something without getting an engineering estimate and experienced sticker shock when they found out the real cost and asks to a new (cheaper) design, or the engineer doesn't want to build "crap" and is going to "do the project right".

The best way to prevent this is to actually plan the project and document requirements, specifications, etc. Then have a project review were everyone who cares about the project comes and signs off. Many people think this is a waste of time, but in my experience, I have regretted not doing this for any project which last longer than a week.

3) Breakdown of Trust

Sometimes there is a breakdown in trust. It could be that the engineer rightfully no longer trusts the directions they are being given and decided to "do right by the company" ignoring information they have been given. Sometimes this might be the right thing to do, but most of the time it will backfire. Sometimes the engineer has too much attitude and needs to learn to trust their coworkers. Sometimes the manager needs to trust that the engineer knows their domain better than the manager and they just need to trust the engineer. [Though I typically think any of these things should be explainable in approx 5 minutes or you don't understand the problem well enough.]

There are times that the management (immediate line managers) or company execs are demonstrating the Peter Principle and are screwing everything up. If this is the case the a person has to ask themselves "Do the benefits working here outweigh the idiots I have to endure?" In my career the answer was "I am out of here" twice, and "I will ignore the idiots because this place rocks" once.

In companies that are 200 people or larger, effective middle management is key for things to work well. Alas, very few people are effective middle managers. They try too hard to mask information up and down resulting in a disconnect between the execs and the individual contributors. This results in lots of surprises for everyone which sucks.