This is your monthly e-Newsletter from
Effective Engineering Consulting Services
If you would like to receive Effective Engineering e-newsletters as they are
published, please send an email to
firstname.lastname@example.org, and we
will add you to our distribution list. Comments and suggestions are welcome
Can You Pass The Red Face Test?
Dennis – President, Effective Engineering [email@example.com]
You’ve just taken
over responsibility for a project or program that seems to be slipping or
just not going right, and you need to understand what is really going on and
where and why problems have arisen so you can begin to take actions to
correct them. How do you do this when the questions you raise don’t seem to
provide useful answers? If people aren’t giving you helpful answers to your
questions, maybe you’re asking the wrong questions.
Several times in my career I’ve had to give depositions and testimony in
legal cases, mostly patent related, and I learned some lessons in getting
ready for and during these cases that are directly applicable to
project/program management. These include determining the right questions
to ask to get the information you really want, and “reading” the
answers and body language of the people responding to these questions.
In preparation for giving depositions our attorneys told us repeatedly that
when a question is asked, you should answer the question honestly but only
answer specifically what has been asked. The example they gave, which has
stuck with me to this day, is that if their attorney asks you if you know
what time it is, and you do, the proper response is, “Yes.” You are
not under any circumstances to respond, “The time is 3:12 PM”. In
giving this response you are going well beyond the question asked, and you
are not to do this. This has broad application to the situation above,
where people may honestly answer your question, but where you haven’t really
asked the right question. I’ll expand on this shortly.
Further, our attorneys stated that, when asked questions, you must be able
to pass the red face test. What this means is that you must
be able to answer the questions responsibly without your face turning red.
Most people who try to lie, or stretch the truth, or move out of their
comfort zone tend to get a bit red faced, which indicates to the opposing
attorneys that they should challenge the answers being given or statements
being made to try to sort out the real truth from what is being said.
Passing the red face test is always important for project/program
development team members, and again means you need to ask the right
questions, and then properly follow up on those questions. It’s not that
you are trying to “interrogate” your people, but you need to gather
the real facts if you are to get things back on track.
There are a wide range of people in any work environment who respond to
problems and questions in different ways. What follows is just a brief
assortment of some of the types of people you may encounter and need to deal
► Honest Hard-Working Folks: I strongly believe that these
are the people who constitute the great majority in most organizations.
These are people who work hard, do everything possible to deliver on their
commitments, state early and often when problems arise so that there are no
surprises, and honestly let people know what is going on and why, whether
favorable or unfavorable (see also
eN-040108 – Herding Cats: Management Challenges 4). You usually
know instinctively who these people are. Such people easily pass the red
face test because there is nothing in their actions or their approach or
their responses that would ever cause their face to turn red. These are the
people who say what they mean, mean what they say, and do what they say
they’ll do (see
eN-050804 – Say What You Mean, Mean What You Say, and Do What You Say You’ll
Do!). These people are the heart and soul of every organization
and can be counted on to do the right thing every time. Ask your questions
and verify their answers, but unless proven otherwise, you can generally
accept their answers as honest and complete.
► “Present” Voters: These are people who never really step up
to the plate and take responsibility for their work or “do something”
either pro or con. They try to stay under the radar by “voting present”
and may not even know whether or not they’re a source of problems. They
simply don’t want to be noticed or take a stand on anything or to really be
part of the team (see also “The ‘Wally’” in
eN-031208 – Herding Cats – Management Challenges 3, and
eN-080508 – Looking Down versus Looking Up). You need to
develop questions that prevent the option of “voting present” and
require them to commit to clear answers. Ask questions that probe directly
what the “present” voters have personally done and specifically where
their work stands. Do not accept vague answers or partial responses. Get
confirmation from others about the nature and completeness of their work.
► Buck Passers: These are people who believe they are never
to blame for any problems; it is always somebody else’s fault. They may not
be able to successfully do what they’ve committed to do, but they’re never
at a lack for creative excuses as to why it’s not their fault. You need to
develop questions that strip off the opportunity to pass the buck and their
attempts to blame others. As with the “present” voters, ask questions
that probe directly what they have done and specifically where their work
stands. Do not accept their attempt to pass the buck and blame others, and
let them know you will not accept their excuses. When they accepted their
assignments they knew others would be involved and that it was their
responsibility to do what they said they’d do without excuses.
► “90% Done” Claimers: These are people who, when you ask
where their part of the project or program stands, will tell you it’s “90%
done”. They often truly believe this, but unfortunately, what this
often means is there is still 90% left to do. It generally means they have
done “some” work, like the very basic functionality associated with
design or coding, but not all of the error path considerations, failure
analysis, memory leak analysis, and the many, many other elements of design
that are essential to any real product or program. Their claims of
being “90% done” also tend to leave out the considerable time needed
to unit test (and then correct and re-test), integrate (and then correct and
re-integrate), integration test (and then correct and re-test), system test
(and then correct and re-test), etc. Also keep in mind that many people who
may claim they are “100% done” are really “90% done” claimers;
they just don’t know it for the same reasons the “90% done” claimers
don’t know. Your questions to these people must get at the heart of what
they’ve really accomplished and how complete what they’ve done
really is. Ask them to describe the remaining work. Make sure they
understand what “done” really means and get a true assessment of
where their work stands given this. Verify with others the true state of
► Range Chickens**: These are
people who know they are in trouble in meeting their commitments, but who
hold back admitting it in hopes that others will admit their problems first,
thereby alleviating themselves of having to admit they’re having problems.
By not admitting their difficulties these people’s problems are the hidden
rocks just below the surface of the water the project/program is gliding
over. You may solve the problems you do uncover only to crash and burn on
the undiscovered problems left by the Range Chickens. Range
Chicken behavior can become contagious (why be the only one to speak up
when everyone else is keeping quiet and getting away with it), so you need
to be on guard for this. Your questions need to probe diligently to uncover
the Range Chickens’ problems. You need to develop questions that
force them to expose the problems they are having; for example, where would
they stand if everyone else was fully ready to go? You can’t let them
escape scrutiny or you will be doomed without knowing it.
► False Evidence Planters: These are people who avoid blame
for problems by planting false evidence of blame on others (see also “The
Cheshire Cat” in
eN-040122 – Herding Cats: Management Challenges 5). They are
especially pernicious in that they are not only the real source of many
problems, but they divert your efforts to find the real problems with false
trails and false blame. Their existence generally becomes evident when
questioning others inevitably leads to the conclusion that disinformation is
being spread; that what is supposed to be wrong with one person’s work is
not only not wrong, but not even possible to be wrong. Eventually, through
the questioning of them and many others, it will become evident that false
evidence planters are at work, and who they are. Your ultimate questioning
of the false evidence planters should be targeted at understanding why they
attempted to plant false evidence, and whether such lowlifes have any
redeeming values to keep them around for any reason. You should get them
off your team (and out of the company) at the earliest point possible.
Trust is a critical element of any team, and liars (see below) and false
evidence planters undermine that trust and cannot be allowed to remain (see
eN-080207 – Trust Me, I’m Not Like The Others!).
► Liars: Some people are able to lie or bend the truth with
impunity and with no “tells” that indicate they are not being
entirely truthful; they are the exception rather than the norm, but spotting
them can be difficult, and the damage they can do can be unrecoverable.
Liars typically lie in areas well beyond their project or program work, and
tend to be uncovered by them forgetting their trail of lies to the point
where their lies become unsupportable. Your questions should be directed to
uncovering the fact that they are liars, and, once proven, getting them out
of your organization, or, preferably, out of the company. As with the false
evidence planters, they cannot be trusted, and they undermine the critical
trust that is essential in an effective organization.
► Others: Of course, there are an abundance of other types of
people who can intentionally or unintentionally hide or cover up problems
that may be the primary, secondary, or other sources of problems that may
stymie the success of your project or program. You must ferret out all such
sources and causes of failure if your project or program is to succeed.
So how do you ask the right questions? How do you determine what the right
questions are? You need to ask questions that will truly address what you
are trying to learn. You’re working to learn what the real problems are and
where those problems exist and what needs to be done to address and correct
them (see also
eN-050303 – Project Management: When Bad Things Happen to Good Projects).
Your questions need to get to the heart of these issues and need to fully
probe the people you are questioning.
First, let them know that you really need their help and that you need them
to answer your questions honestly and fully. Work to establish trust.
People typically don’t want to mislead, but neither do they want to
disappoint or point fingers at themselves or others. So they’ll find ways
to reply to the questions without responding to the issues. Let them know
you are not trying to attack anyone, but that you need to understand the
root causes of the problems if corrective actions are to be taken to get the
project or program back on track. If you’re trying to ascertain where
things stand – for example, what is the real state of a project – ask the
right questions, not ones that can be easily avoided. In other words, don’t
ask, “How is the project going?” The answer will likely be, “Fine.”
Instead ask, “Will you meet your next milestone (specifying what that
milestone is) on a specific date?” and, if not, why? You can generally
learn most by asking open questions (where you don’t restrict the scope of
the answers) to honest people, and closed questions (where you do restrict
the scope of the answers) to devious people. Stay specific with your
questions but allow the person the opportunity to expand on their answers to
give their opinions of where problems may exist and why. These responses
can help direct follow-up questions and identify others to question.
During your questioning, try to determine the type of person you’re talking
to. Ask some straightforward questions with clear expected answers and see
if they have normal responses and whether they answer the questions you
asked with specificity, or give answers that are not really responsive to
what you were asking. Also check their body language to see if they seem
comfortable or uncomfortable in responding. Are they passing the red face
test? If their answers are responsive and their body language seems
comfortable (and without a red face), then move on to more questions, and
keep looking for responsive answers and comfortable body language. If their
answers are non-responsive and/or their body language shows discomfort (or a
red face), then press to get responsive answers and refuse to accept
non-responsive answers. When you see body language discomfort (including a
red face), then press in to uncover the cause of the non-responses and the
discomfort. Expose the root causes of problems, and identify the types of
people involved in the project or program.
Again, your intent is to determine where the project or program stands and
what needs to be done to get it back on track. You need facts to make this
happen. Asking the right questions and looking for people who pass the red
face test can most directly point you to the right way to understand and
resolve the problems that need to be addressed.
An additional benefit is learning who the people really are, and who can
most or least be trusted. Trust is absolutely essential and plays a central
role in effective project management. If the underlying relationships are
not reliable, then no project or program forecasts can be reliable. In
addition, trust greatly enhances the efficiency of the organization and
enables them to excel (see also
eN-081002 -- Pigasus – When Pigs Fly!).
People who can be most trusted can become valuable and reliable sources of
information and can potentially be groomed for further advancement in the
company. Work to identify, and possibly even reward, those who stand up and
admit that they are one of the sources of problems, especially if they
propose solutions on what they will do to get the project or program back on
track. Note those who simply report problems without any potential solutions
(see also “Whiners” in
eN-030508 – Are You Part of the Solution, or Part of the Problem?).
People who can be least trusted can be put on notice, perhaps be given
opportunities to shape up, or be positioned to be moved out of the
organization in an appropriate timeframe.
Of course, better project management methods can reduce the need for “red
face” questioning after the fact. It is always better to prevent
problems than to have to remediate, make excuses, or provide explanations.
Better tracking of shorter intervals can let you know where things stand and
where problems are developing well before things get out of hand. This is
discussed prominently in project management literature and will be addressed
in some future e-Newsletters. Still, critical questioning can be an
essential tool to avoid being surprised, and determining whether people can
pass the red face test can help in that effort.
** [Note: The suggestion of the “Range Chicken”
category and the essential role of trust in project management comes from my
friend Lee Beaumont (see prior e-Newsletters
eN-071004- The Schedule Estimate Extortion Game and
eN-081113 – Start Spreading The News!), and also see Lee’s “Range
Chicken” history and description at his “Bureaucrat’s Handbook”
http://www.HonorAtWork.com/rangechicken.htm, and his discussion on trust
Copyright © 2009
Effective Engineering Consulting Services, All Rights Reserved