Dave's Observations And Thoughts About Bad Management In Embedded Software Development
Bookmarks
I (Dave Ashley) have become really cautious about which recruiters I deal with, which employment interviews I consent to, and which job offers I accept. Understandably, my caution comes from experience.
Generally speaking, the management in the auto industry involved with the development of small embedded systems is the worst management I've seen anywhere. The general components of the poor management performance and low-quality work environments are discussed at some length in the following sections.
Some might claim I have a bad attitude. Nothing could be further from the truth. In most cases the key issue is an elusive quality that I'll call technical maturity. Some people (specifically, the bad supervisors and managers I've had the dishonor of working with) go their entire careers and never grasp the essential nature of the technical and management problems they confront on a daily basis. That failure to technically mature does not make these individuals morally defective--it just makes them technically defective. My desire to distance myself from such individuals doesn't come from anti-social tendencies; but rather from the self-preservation instinct.
I'm very much reminded of a quote from one of the Superman movies where Lex
Luthor (Gene Hackman) (
)
delivers a line something like, "Otis, why is it that some people can
read the list of ingredients on a chewing gum wrapper and unlock the secrets of
the universe while others can read `War and Peace' and come away thinking it is
a simple adventure novel?". How true, Lex, how true! Some
people don't get it and won't ever get it.
Much of the remainder of this page is devoted to observations about management that has failed to technically mature.
What Is One Trying To Achieve In Software Development?
Before slamming bad management for failing to get it, one should state what it is that needs to be gotten. What is one trying to achieve in software development?
On the administrative side, the bare minimum that one is trying to achieve is administrative neatness. In modern software development, neatness is not neatly-labeled file folders and Microsoft Word® documents with attractive cover pages and attractive headers and footers. Neatness is a comprehensive information management plan that:
On the human resources side, the bare minimum one is trying to achieve is to create the most rewarding experience for the top 10% of technical contributors. Not all engineers or employees contribute equally. The 10% of engineers/employees that contribute the most technically to product development tend to have unstable personalities (these are the people you want to keep away from customers, for example). These individuals tend to strive for technical excellence, and don't tolerate environments that dilute their productivity. So, it makes sense for an employer to try to create an environment free of performance obstacles so as to be able to retain these individuals.
I'm not claiming that an employer needs to identify the top 10% of technical contributors in order to be effective at retaining these people. All that is necessary is to create an environment where those who wish to perform can do so.
It may be difficult to for the reader to envision a scenario that creates a low-quality experience for a solid technical contributor. A concrete example is that "coding standards" example, which I present next in the section Performance Dilution By Technically Immature Management.
Performance Dilution By Technically Immature Management
One phenomenon that drives away gifted engineers is performance dilution by technically immature management. The nature of the phenomenon is that management often doesn't understand the work or the nature of the work well enough to make sound decisions; and some of the decisions (or failures to make decisions) invariably lower the quality of life for engineers. The most gifted engineers tend to have the strongest desire to contribute to the company's productivity, and so these decisions tend to frustrate the most gifted engineers into leaving the company. The net effect is to place an upper limit on the caliber of employees the company can retain.
The phenomenon of differentially frustrating employees is also mentioned by Colin Powell in his awesome presentation, A Leadership Primer (available here as a .ZIP'd PowerPoint presentation). The bottom line is that the most productive employees are most sensitive to obstacles to their productivity. The graphic below is from Powell's presentation.
One example from my own career is the issue of coding standards. At one point in my career with a large company, I was given responsibility for products that were politely called legacy products. Legacy products was a euphemism for products that had been poorly-designed and modified too many times.
Each file that I opened in these legacy products contained inconsistent indentation and a mixture of space and tab characters (something that is prohibited by most coding standards). Because 'C' functions in embedded work can be quite lengthy, the net result is that I had to replace all tabs with spaces and then manually indent about 10,000 lines of code. It was an unpleasant experience.
During the experience, I discussed with my boss the need for coding standards that prohibit tab characters in source files. He was unenthusiastic about coding standards in general, and nothing ever got done. The net result was sure to be that more source files with inconsistent indentation were coming my way.
The general trend with bad management is:
One question I often ask myself is "How did things get so bad in small embedded work?".
I'm convinced that the answer lies in evolution and co-evolution. From time to time, one may watch a nature special where in some dark cave with a closed ecosystem, a species of blind fish has evolved. Blind fish can exist in such an environment because they do not need to see.
Similarly, I'm convinced that the poor management skills abundant in small embedded work come from the environment. Every project is small enough that one can just keep throwing people at it and somehow the work will get done, even without a design. Skill is not necessary. A large pool of young energetic engineers who are easily deceived and manipulated is necessary.
In projects of higher complexity, the same approach would fail miserably.
Q: Why are the supervisors and managers of small embedded software products so bad?
A: Because they can be (the complexity of the product allows it).
Emotional Manipulation Of Employees
Recognizing Problems But Resisting Solutions
Sound
credit: The Austin Powers series of films starring Mike Meyers.
This
web page is maintained by David
T. Ashley.
$Header: /cvsroot/esrg/sfesrg/esrgweba/htdocs/authindiv/dtashley/bad_management/index.html,v 1.7 2003/05/10 00:28:43 dtashley Exp $