On Being the Bearer of Bad News

Philip Koopman
2/28/96
koopman@cmu.edu

Though it be honest, it is never good
To bring bad news; give to a gracious message
A host of tongues, but let ill tidings tell
Themselves when they be felt.
--- Antony and Cleopatra, William Shakespeare

Engineers are sometimes in the position of being the bearers of bad news. An experienced engineer will not report a problem empty-handed -- it is always wise to have some idea of a solution to present to management. Nonetheless, finding a major problem that disrupts the execution of a project plan can make life difficult for an engineer.

The discovery of a major problem imperils management's goal of delivering a product according to a set of constraints. Commonly, fixing the problem extends the schedule past an important deadline. A nastier situation arises when the bad news conflicts with a non-technical agenda. For example, the customer may demand a particular technology, but it may be impossible to create a design using that technology which will actually work. The situation may be particularly difficult when management does not have the technical expertise required to appreciate the nature or severity of the problem.

An engineer's report of a big problem can result in the following impasse. The engineer is insisting that the project will fail unless the problem is fixed. But, fixing the problem will cause the project to fail due to violated constraints. Changing the problem constraints is deemed unacceptable because of market pressures, management goals, or potential loss of face.

The result is a dilemma for management. The engineer says the project will fail if the problem is not fixed. But, management knows the project will fail for non-technical reasons if problem is fixed. At this point, management may over-rule the engineer and declare that the problem need not be fixed. Or, management may mandate a quick fix that evades liability, but will not in fact solve the real problem. "After all," management may reason, "no design is perfect, and the engineers will figure out a way to patch things up later (the way they always seem to do)". Or, management may not truly grasp nor want to believe the scope of the problem. Or, management may in fact plan to deliver a flawed product and simply declare it to be successful.

If management decides not to fix the problem, it is the engineer who is in a dilemma. Of course, the engineer will talk things over with peers and mentors to try to understand what is happening. But, what if in the end the engineer doesn't agree with the reasoning behind a management decision? Does the engineer go along with management's decision, and deliver a product with major flaws? What are the risks to the engineer's career of having knowingly designed a bad product? What if someone is likely to be injured or killed? Don't engineers have a professional obligation to refuse to create designs that are dangerous or don't work?

If management decides to press on, the engineer may feel a need to protest. Then, management perceives the engineer as the problem. After all, if the engineer weren't standing in the way, there would be no more problem (at least for the time being).

There are several options available to the engineer, each of which has risk. It is important to discuss the options available with trusted friends and mentors who might be able to bring some objective wisdom into what is probably an emotional situation. But, ultimately if you are in this situation, you will have to make a choice from options that include:

• Trust management to make the right decision, and prepare the best possible technical recovery strategy for a product fix/upgrade. In most cases, this is the right thing to do, no matter how unpalatable. Many managers reading this will no doubt consider this the "correct" solution. However, this approach may in fact be wrong if management truly does not comprehend the consequences of their actions. An added risk with this path is that in some organizations you may be seen as a troublemaker simply by presenting an above-average number of problems to management, even if you do go along with their decisions.

• Stand your ground, and be perceived to be the problem yourself. In this case, it is important that you turn out to be right -- and, even if management backs down, you may pay a high personal cost. Punishing an engineer who stands his ground may have the effect of encouraging others to ignore problems.

• Don't look for problems; don't tell management if you find them. Follow Shakespeare's advice and don't be a trouble-maker. The risk of being disciplined (in the near term) is minimized. Things may work out of their own accord. But, you may be shirking your professional obligations, as well as putting your company and its customers in jeopardy. It's hard to see how anybody wins with this approach.

• Change projects or leave your job. You can only do this so often, and the personal cost may be high. But, it might be worthwhile if you don't want to compromise your integrity, and standing your ground does not seem worth the cost.

There is no clear answer on how to handle being the bearer of bad news. It is always a good idea to work with management to make effective risk tradeoffs, and try to understand the non-technical factors affecting decisions. It is also nice if your management views finding problems as a healthy part of the engineering profession. But, there will be times when management goals conflict with your professional and personal interests as an engineer. Then, you may have to choose among compromising your integrity, abandoning the project, or suffering the results of a conflict with your employer.

Selected correspondence:

On Sun, 13 Sep 1998 19:01:44 EDT:
>Hi, just read your commentary on bearers of bad tidings, you might want to
>add that the less than ethical management that will ignore "problems" is often
>the management to stick the blame on the engineer when the "problem"
>eventually comes to light. Curiously? The problem always seem to eventually
>be exposed. It's exposure is often accompanied by a virulent case of
>selective memory loss on the part of management...... been there, done that.
>My advice?, keep good documentation to assist in jogging faulty memories.

Phil Koopman -- koopman@cmu.edu