How many times have you heard someone say: "I just showed my boss how to [pick one] a) save the project, b) improve productivity, or c) improve quality, and he blew me off. What an idiot! I'm quitting this place to find a company that appreciates my good ideas."

This is one of those "The grass is greener on the other side of the fence" situations. While the grass may be greener, often it's AstroTurf®, and all you get is rug burn. The goats in these stories are always managers, most of whom are the equivalent of the pointy-haired manager (PHM) in the "Dilbert" cartoon strip. So off you go to find that the next company isn't any more receptive to your bright ideas, all the while avoiding any mirrors that happen to be around that would tell you the fault may be yours.

I've been working as a change agent for most of the thirty-plus years I've been in hardware, systems, and software development. I have a few rug burns, but I've begun to figure out what makes management buy into a change or a new idea, and what to do when speaking to management to facilitate the change I want. Understanding managers' needs, how to influence them, and how they make decisions are all part of being successful in getting their support (or getting them out of the way if that's what it takes).

Let's take a look at a hypothetical Six-Sigma distribution for managers. Rarely will we run into managers who initiate continuous improvement on their own. Fortunately, this isn't as rare as it used to be, because executives try to emulate Jack Welch and others who have been successful with Six Sigma.

There really aren't as many PHMs floating around as we think on our grimmer days. If that were the case, companies would never stay in business or develop products as successfully as they do. It just seems like there are more of them than we'd like. In reality, the distribution is biased toward the right side of the distribution. Of the twenty-plus managers for whom I've worked, three or four fall into the far left, and the rest have at least been "trainable" with three in the "initiate change" category.

So what have my rug burns taught me? First, you must understand what is important to your company and to your boss. Proposing changes that threaten their goals won't work. Second, you need to understand your boss's management style. Is it a hands-on, detail-oriented, need-to-be-involved-in-every-decision approach, or a hands-off, bring-me-a-solution-with-results style? How much time do you need to spend educating your boss? How rigid or flexible (need I say wishy-washy) is he?2

If on-time delivery is the paramount measure of success in your company, you can bet your boss is measured almost exclusively on that goal. Even if post-ship product quality is abysmal, trying to sell a change to improve quality would have as much chance as a snowball in Phoenix in July. (It was 118 degrees a few days ago.) If low cost development is the primary goal, any suggestion that is seen as adding cost will not be accepted. Unfortunately, your view of adding cost may not the same as your boss's view. Promises of future savings that offset a current addition may fall on deaf ears.

The Optimist Versus the Pragmatist
A wise senior manager once taught me that management gets lots of bright ideas from very smart technical people, all with some element of risk. If the organization is working reasonably well at handling the typical problems, there is a disincentive to change and assume a risk that cannot be quantified beforehand. He went on to say that many of these bright ideas, while good, did not fully appreciate the business environment and constraints placed on him. All too often the benefits were overly optimistic and the costs to implement the change were understated—a typical failing of the bright ideas from his smart technical people.

Some other lessons I've learned along the way:

Lesson Learned #1

• Do not underestimate cost, do not overestimate returns, and be sure to consider the business drivers that are limiting your boss's freedom of action

The Problem Saturation Index (PSI)
A number of years after learning Lesson #1, I was introduced to the Problem Saturation Index. I was at lunch with a group of friends bemoaning the boss's unwillingness to embark on an inspection program in spite of a logical and conservative proposal. "After all," I thought, "everyone knows inspections are a winner in a high-tech, high-quality product development, such as satellite control systems."

One member of the group said, "Ed, you don't understand! You are solving a problem that will occur two years from now—management is saturated with today's problems." Realizing this was the case and that the organization's culture was to empower individuals to solve problems, I took the approach of finding a project manager willing to try inspections. I trained the team, and we inspected a complete set of requirements documented in use cases. Along the way we discovered the need for standards for the use cases. When we finished, we had a useable set of use case standards that could be used by the rest of the organization, a much higher-quality requirements document, and significant savings in time and money. This was because several of the problems would have escaped through design and implementation and been discovered in the integration test stage or later. The latter point was critical because the product was to be subcontracted from the requirements document and it was unlikely the subcontractor would have had the overall systems view to recognize these problems.

The development team later presented the results at a brown bag lunch, where the afore-mentioned boss was present. He declared that inspections would be a best practice, remarking "pay me now or pay me later."Lessons Learned #2-#4

• Present solutions, not problems when faced with PSI
• The solutions should be actual experiments or pilots with data
• Have the development team members present the results. They did the work; let them explain it. The results will have greater credibility

Which Way Is the Wind Blowing?
Occasionally you will run into a manager who seems to have lost his compass. He will do whatever he is told by his boss, ignoring past experience that would tell him to at least protest mildly at the direction given.

I was approached by several development team members who complained they were being told to remove code inspections from the project plan because there "wasn't enough time to inspect all the code." It was interesting that years before, this manager was an early adopter of inspections, albeit at the direction of his boss. She was one of the rare "initiates change" managers at the far right side of the curve. His current boss was unconvinced of the value of inspections in the development environment, and saw no reason to "waste" time and delay the start of testing. (One might ask, if you do not need to inspect, then you do not need to test either, but then the senior PHMs might accept that proposal!)

What we proposed was to inspect a sample of the total code, and base the decision on whether or not to continue inspections on the results of the sampling. We had good numbers on the cost of defects found in test, so it would be a straightforward data analysis to determine whether or not to continue. The conditions to which we agreed were:

1. The code samples would be a representative sample based on complexity
2. The team would faithfully adhere to recommended preparation and inspection rates
3. The team would collect the data accurately, because this was another very complex product, it wasn't surprising that the defect rate for the inspected code justified continuing inspections

To say we fooled the manager might be a little strong, but we were reasonably certain of the outcome and the team members were motivated to do their best to justify their positions. Keep in mind, this was not a scientific experiment, but an experiment to justify continuing a process (i.e., participants were not unbiased).

Lesson Learned #5

• In the face of resistance, propose a low-cost experiment (such as sampling) to evaluate use of the proposed process or idea. It does not necessarily have to be a fair experiment either. (Accurate, yes, but it doesn't have to be fair. Think of it as gambling when you are the only one who knows the outcome is a certainty.)

In each of these examples, understanding what makes your boss tick is critical to getting your way. Giving up, calling him an idiot, or assuming he would not recognize a good idea if it hit him between the eyes are all forms of transferring the blame to someone else. Remember that when you are proposing a change or new way of doing something, you bear the responsibility for selling that idea to the decision makers. To do this effectively, you need to understand what they react to or are paid to do. Once you understand that, it is a lot easier to get your way.