Is the Grass Greener on the Other Side of the Fence?


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."

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.