Idiot Lights

I’m old enough to recall cars that had useful gauges – the cooling-system temperature gauge, for example.

Nowadays they have on/off indicators, referred to as “idiot lights.” Such as the check-engine light. The idiot light that this morning is illuminated in my car. I’m writing this article while sitting in the dealer’s waiting room until they attach a computer to my vehicle to diagnose the problem. (And then charge me a bunch of money to fix it.)

The car’s computer system stores a diagnostic code that the dealership’s computer will retrieve, at least as I understand it. What I don’t understand is why the car doesn’t simply display that diagnostic code on the dashboard – a gauge instead of an idiot light.

With that diagnostic code, I could call the dealer’s service department and say, “Do I need to bring this in now? Can it wait a couple of days? Can I fix it myself?”

As a project manager, what do you offer your clients and team? When do you offer a gauge? When is an idiot light appropriate?

Consider the range of reactions to detailed (“gauge”) information:

  • Jolene understands the information and uses it to make informed choices.
  • Stan doesn’t understand, and asks for clarification.
  • Charlie thinks he understands, but doesn’t. He makes a potentially poor choice based on his ego, since asking a question would, in his world, display ignorance, or at least less-than-competence.
  • Susan trusts you, period, and asks you to do what you think is necessary.

On the other hand, consider reactions to limited/high-level (“idiot light”) information:

  • Jolene is frustrated that you don’t trust her or respect her intelligence, so she asks for more information in order to make good choices.
  • Stan asks for clarification.
  • Charlie… well, he gripes about not having the information he needs, but he’s less likely to make a dumb choice in reaction to the information.
  • Susan trusts you, period, and asks you to do what you think is necessary.

(Hmmm. Given how little I know about cars, I sure hope I’m not a Charlie here. Nah. I know my competence ends with changing a headlight or checking the oil. I want the diagnostic code to help the dealer with scheduling, not to try to fix anything beyond tightening the gas cap.)

One possible solution – and it’s one I’ve employed myself many times – is to provide gauge data to Jolene and idiot-light information to Charlie. A project manager must do whatever is necessary to keep the project moving forward effectively. If that means different approaches to different people, do it. Don’t be underhanded about it, though. If Charlie wants to see the same information Jolene receives, you’ll need to accommodate him, assuming there’s no privilege or confidentiality issue.

Another solution is to provide idiot lights for everyone while making it clear you’re not just available but eager to share more details. This approach lets you feed information to Charlie in a way that minimizes (though does not eliminate) his propensity to guess at what he doesn’t know. However, it frustrates Jolene and leaves her less effective… and probably makes your own job less fun as well.

A third approach provides full gauge data to everyone and then try to ensure Charlie doesn’t get a case of the stupids. Good luck with that.

A fourth approach – keep the Charlies off your team, or maneuver them to the exits. I’m all in favor of this method, but it’s hard, takes time, and is unavailable in many workplaces, legal and otherwise.

Fifth, you can try to train Charlie. That can work. We’re part of a world full of very smart people, many of whom are willing, even eager, to get smarter about a wide range of subjects – including themselves. That said, there remain many lawyers who think they know what there is to be known, in any subject area.

Sixth, don’t play one-size-fits-all. Some project management information is best presented in detail (as a gauge), while other items might be best served up in idiot-light form. I think this is generally an effective approach, usually coupled with one of the preceding options. For example, I usually share detailed project-risk issues with the team, since their on-the-spot decisions will often benefit from a knowledge of risks, mitigation, and contingency. On the other hand, I tend to share dependencies in idiot-light form – e.g., “John, Sally needs this by Tuesday in order to make her own deadlines,” rather than offering, say, a Gantt chart that a) is hard for non-project-managers to interpret, b) inevitably contains inaccuracies with regard to timelines, and c) offers little information that team members can use to make choices in any case. (I should note that when I ran hand-picked teams with little turnover, I used no “idiot lights” at all.)

In the end, with one exception, I come down on the side of gauges over idiot lights whenever possible. I believe people and teams do better with more rather than less information. I’d prefer to spend time close-managing the Charlies rather than keep information from the team.

The exception? When the client is a Charlie.


  1. What I wonder about is Susan. why does she trust you and what exactly is it she expects from the trust. i.e. She is OK with you getting it wrong as long as you gave it your best shot (and she is your mother), or does she trust that you are going to get it right eventually? Or that she trusts you will get it right the first time within the estimated cost.
    I call it subjective vs objective trust, but I’ve haven’t found much literature about it.