As a motivational tool, catching people doing things right is effective.  But it doesn’t work long term if all you is praise their results.

I led the winning team on a bid worth $85 M in Hong-Kong.  It was complex, with months of technical, commercial and legal negotiations. The team gave all it could, and then some.

Coming off the plane, I went to the office and attended the celebration party. Executives, heads of department and the entire team drinking champagne (yes, they allow this in France). Speeches.  How happy the executives are. Proud of the team who worked so hard.

It was nice.  The bonus was nice too.  But it did not change much. Business as usual the next day.

But not for me. I had been debriefed, the “Encouragement” way.

Pierre-Louis Bertina – my VP of Sales at Alstom Signaling Group (then GEC-Alsthom), went beyond congratulating me for doings things right.  He commented on “WHAT” I did right.  He took the time to observe my work.  He noticed what I was doing right, and re-enforced it by focusing on it. This is “Encouragement”.

He never said “you did well” and stopped there.

After an intense negotiation session, which he attended, he told me:

“You did great. We got what we wanted, because you always knew, almost before they did, what part of the spec affected the discussion. You’d turn to the right page faster than they – who wrote the spec.  That’s a great skill you should cultivate. I wonder what we’ll do after we win this and you move on to something else.”

Another time, he learned the fellow in charge of installation had moved his vacation (rare in France), to finalize his part of the bid.

“You know, why they do this don’t you?” (I didn’t’ – but said nothing) “You make them feel that what they do is important to winning the bid.  You should keep that up.”

Let’s face it. We all like our boss to tell us he’s proud of our good results. It’s nice. But it does not make a huge difference in our work.

Pierre-Louis went beyond congratulations.  He notice how I did my work.  He connected it to the results.

• It gave me confidence. A manager with his experience confirmed what I did was the cause of my results – I was emboldened to continue.
• It felt like he really cared about the team’s success, since he took the time to notice.
• It opened the door to discussion. I’d feel comfortable discussing my plans with him, because we focused on the how-to, the process, instead of only the results.

I spoke to Pierre-Louis before writing this to get his permission to quote him. I learned that three people in his latest team have now become Directors.  I am not surprised.

It’s called encouragement.  It uses words that notice.  It works equally well with successes and failures.  Notice the process – what works or does not work.  Encourage what works, coach what does not. It sets up improvement. It sets up growth.

All you need is to take the time, start noticing what the team does right, and tell them about it.

Blanchard and Johnson were right.  It really works.  But I disagree with them on one point:

It does take more than one minute.  But it’s a great investment of your time.

Going over this problem in many coaching sessions, I discovered one reason why this is so

Engineers skip the middle step, of this three step process:

• What can go wrong?
• Why would it happen?
• How can we prevent it (or at least lessen its impact)?

Intellectually, it makes sense.  If a risk has actually occurred, it’s now a problem.  The normal engineering response is to perform a root cause analysis: “Root out the cause –the solution will be obvious” my first boss used to say.

But when considering risk – that is, a potential problem that has yet to happen, engineers tended to focus on prevention at all cost.  I found that when they looked at what might happen, they were keenly aware of the potential impacts, and this naturally focused their mind on preventing the possible disaster.  Solving this is simple:  re-focus the team on the possible causes. Answer the question:  Why would that (risk) happen?

However, it is not that easy discussing the cause of a problem that does not exist yet.  After all Root Cause Analysis is a process of elimination.  And, it is a lot easier to eliminate wrong causes, when the problem has occurred and we can test our hypothesis.  In risk analysis, we work with suppositions.

To make the process easier, I have found that using Toyota’s five Whys is quite useful.

The process is simple.  The “Whys” form a chain of questions, each consecutive “why” inquiring about the previous answer in the chain. (The goal is to ask “Why” of the previous answer – and not ask “why” five times about the initial risk and come up with 5 different answers).  It is a chain of inquiry that digs deeper in each successive question.

In reality, I have found that we rarely need all “5” whys – 2 or 3 really helps to clarify the potential causes enough for a mitigation plan to emerge.

From the coaching file:

The QA team was discussing their proactive QA plan on phase 2 of the project.  They were reviewing the design review process:

[Lead]: What could go wrong with this plan?
[Team]: The engineers might not follow the development process.
[Lead]: So what can we do about that?
[Team]: Hmm – I don’t know, get their boss to make sure they do it?

[Coach]: Let’s focus on the risk first before we look at solutions. – try the 5 Why questions

[Lead]: OK – Why would they not follow the process?
[Team]: Because they don’t know it?
[Lead]: That’s not likely – we just had a kick-off where we reviewed the process with everybody.
[Team]: OK – Maybe because they don’t want to follow it?
[Lead]: That could be – but Why would they not want to follow it?
[Team]: May be they don’t agree with it
[Lead]: so Why would they not agree with it?
[Team]: I think they want to do it a different way
[Lead]:  and Why do they?
[Team]: at the meeting, I heard some of them grumbling about the process – they think it’s too vague – they think they have a better way.

[Coach]: OK – now let’s look at mitigation – how can we prevent the risk that they won’t follow the process, if the engineers think they have a better way?

[Lead]: I think we should have a discussion about the process with them – ask them what they think, see what they don’t like – you know – get buy-in…

(the rest of the discussion is for another post…)

Please note:  There usually is more than one possible cause.  The 5-Why approach tracks all causes until they are clear.  Then, before mitigating, you need only assess the probability of the cause actually occurring is. Normally, you would mitigate the higher probability causes.

The 5-Whys have been criticized because they can trivialize the root cause process – leaving details out that would otherwise lead to a better solution.  That is quite possible, when using them to solve a problem that has happened.  However, they are the perfect tool for clarifying causes of potential problem – i.e. risk.  Even if the clarification can lack some details, I have always found the 5-why method to help identify risk mitigation plans.

High Performance Engineering Teams embrace risk:  they look for what can go wrong continuously (yes! almost every day), and seek to prevent the risk by adjusting their approach to the work.  For this, asking why 5 times is a great tool.

I am sure there are many reasons – but I have noticed one that is not often mentioned.

Failing teams have a culture of risk-avoidance.  Successful teams have a risk-embracing culture.  They are diametrically opposed – and it affects how they deal with risk.

Risk-avoidance cultures want the risk to go away.  They want no risk to remain.  They secretly believe that if the risk management process is done well, risk will actually be removed – even though they know that engineers are not perfect so this ideal is rarely reached.  In these teams, risk management is a discrete task: something you do at select times in the project which, when completed, results in the removal of risk.

Risk-avoidance cultures say:
Risk must be eliminated – it should not remain on my project!

Risk-embracing cultures believe that risk is a fact of life.  They expect it at any turn. They are comfortable with risk.  They learn to love looking for risk. No matter the mitigation plan – they reason, something can always go wrong – so they keep planning for it.  Risk management is a continuous affair – almost a state of mind.

Risk-embracing cultures say:
Risk is part of our life – we expect it and use it to get better

In my experience, no team is purely risk-avoidance or risk embracing. These are opposite poles of a spectrum – the team tends towards one or the other.

I have learned to identify the dominant behavior (avoidance or embracing) by looking for telltale signs of how the team reacts when risk becomes an actual problem (i.e. it was not avoided).

A warning:  Do not confuse risk-avoidance with risk-adverse. They are two different concepts. I know many successful entrepreneurs who are clearly  risk-embracing and yet are very risk adverse. I also know team leaders who are in the risk-avoidance camp but are reckless risk takers.

Engineering teams do well in a risk-embracing culture.   It is the nature of engineering work that we cannot predict everything. Evolving an approach that always looks for what can go wrong, understanding the source of the potential problem and creating adaptive mitigation plans  requires great engineering skills. It’s actually challenging and fun.

“My people do listen to me”.

Do they?  Or are you just lucky?

As a young manager I used to think that what I said mattered. But it did not.  Sometimes it looked like it did: the team members already agreed with me – hence they ended up doing it.  It was luck.

That is why I developed a strong affinity for asking clarifying questions:  If I can discover what a person is really thinking about a given task, at least I now know what they plan to do.  Then, if I don’t agree, I have at least a fighting chance of discussing it.

I have developed a golden rule:

When it comes to doing the work, what I say most likely won’t matter. Only what the team member thinks will matter.

Most engineering managers eventually discover that they are not Lords and Masters.  They cannot tell people what to think.

Don’t get me wrong – managers have authority.  They tell people “what task” do to.  They may set the general approach of how a task will be done.  They can hire.  Sometimes they can fire – so they can carry a big stick.

But even a big stick cannot force people to think like we want them to.

And when your team members are knowledge workers who must think to do their work, it follows that you cannot tell them what to do.

This can be frustrating.  What’s a manager to do, when the project is late, over-budget, the client is coming next week – and it’s still not working because the team member is not getting “it” ? (it being what you think needs to be done – of course)

A good friend of mine, a psychologist who works with CEO’s, Sport Pros, National League Coaches and the like, told me:

When you see a coach, or a leader get very upset, and start screaming, it’s usually a sign that he has tried everything he knows. He just doesn’t know what else to do at that moment.

I have been there.  Time is running out, and I realize I can’t make people think like I do.  I’m stuck – and I want to scream to make something happen (which it won’t).

My advice?  Don’t let it get to that point.  Recognize that you can’t force someone to think like you.  Don’t assume that because you told then what to do at the kick-off meeting, it will happen that way.

Instead, ask questions to discover what they are thinking.  Then – and only then – might you be able to bring them around to your way of thinking.

Here’s a link to the IEEE Pittsburgh monthly newsletter (pdf file: see page 4 – bottom) if you want to see the abstract.  It is requested that you RSVP at the email address given in the newsletter if you would like to attend.  There is no fee.   You do not have to be a member of IEEE to attend.

My discovery of the “local” IEEE (Institute of Electrical and Electronics Engineers):

I have been a member of IEEE on and off since I graduated, but until recently never realized how much the association offers locally.  I used to think IEEE was mostly about publishing in the IEEE transactions and creating standards.  It is much more. They offer events, seminars, round-table and speakers locally.   This is organized by the local section.  They are also a great network: It’s a great way of meeting other engineers with similar interests.  I find that everybody is really helpful.   For my part, I have decided to become more involved: With another member, we will be setting a consultant’s network for the Pittsburgh section.  I’ll keep posting notes on this here as we move forward.

The IEEE Website  membership page shows all sorts of online resources available to members.  Also this page shows all the local sections (in the world), in case, like me, you want to meet those individuals who volunteer to run the local sections.

I previously suggested asking questions about what your team will do, instead of telling them what to do (see: Ask, Don’t tell).   But some people find it difficult to get team members to explain their views in a manner that is clear for the all to see.  I’m often asked “How do you come up with the right questions?”

The secret is simple:  it has nothing to do with the questions.  It has all to do with what you expect to find, and what you want to do with the answer.

Think about it.  If somebody asks you questions for the purpose of judging your answers, you can feel it.  And you’ll be guarded.  On the other hand, if they are only interested in what you think …

Think “treasure hunt”.  Start with:  Whatever answer I get, it will be OK.  The only goal is to help them bring their views out clearly, in the open, for all to understand.  Their answer is the treasure – but it’s hidden.  The job is to bring it to light.

If you do not intend to judge, but only to discover, your questions will naturally occur to make this happen.

So you must decide: are you on a treasure hunt, or are you judging their answers?

Note that it cannot be faked. You can pretend to be inquisitive, but if you are judging, it will out. Your true purpose will slip through:

From the coaching file:

Mgr: “How do we know that an engineer has developed a good test procedure?”

Lead: “He knows the requirements, he’s familiar with the requirements, and then knowing them, he makes sure that the test covers all the aspects of the requirement, and the results to be produced are clearly stated.”

Mgr: “But what you explained here is purely theoretical. You say, a good engineer knows the requirements – how do you know when you assign the work to someone that the work will be done that way?”

Lead: taken aback – is fumbling his words: “How do I know it will be done that way?”
… …
Coach: speaking to team leader: how did you feel when he said “what you said is purely theoretical?”

Lead: “that I don’t know what I’m doing!”

Coach: “And why did you seem confused about the question?”

Lead: “I don’t know, it’s like something clicked off in my mind, I could not think straight.”

The sad part is that the manager had asked a very good question – but the judgment proffered destroyed it.

I must emphasize: the skill is not how to ask questions.  The skill is how to truly focus on the treasure hunt – a discovery – and stay away from judging.

That is a simple decision – But it can be difficult, if you are like this other Team Leader:

From the coaching file:

How am I supposed to use this method, if I already know that the person is wrong? How can I make him see that he is wrong?

You can’t.  It is a two step process:

1. First, focus on clarifying the answer, with no hint of judgment.  Discover their view.
2. Then, when the answer is crystal clear and possibly written on a whiteboard for all to see, and only then, can you share your views about its correctness, sparking a discussion.

After all, even people are incorrect, you  would still need to understand their position before  discuss were they are wrong.  But they will not  share her thoughts openly, if they  feel that the “questioning” is about judging them.

So don’t worry about what questions to ask.  Just stay away from judging.  Of course, it’s  not always easy, if you are a manager with schedules to meet and budgets to keep.  Not judging, actually takes practice.

It had started badly.  Louisville returned the opening kick-off for a touchdown.  Then Louisville could do no wrong getting 25 points before Rutgers would score on the last play before the half.  Going to the locker room, loosing 25-7 at half-time,  Coach Schiano  would talk to the team:

“Just keep chopping away guys. It’ll turn, if you let it – it’ll turn.  You just gotta keep doing it though. If you don’t do it, you’ll never know what could have happened.”

The second half was like a new game. Louisville would not score again. Rutgers won, on a field goal with 13 seconds left, 28-25.

Asked by a reporter at the press conference, if a moment stood out for him, coach Schiano answered:

“There was a moment when Eric Fosters came walking down the sideline like this (coach makes hand chopping movement), and we passed each other and he never even looked at me he was so focused… At that point I said, you know what, these sons of a gun just might do this.”

The Washington post would write about the chop on the week-end:

“He (coach Schiano) first heard about it from Dr. Kevin Elko while serving as Miami’s defensive coordinator… Right now we’re in a bad spot, we’re in the middle of the forest, it’s all dark, we can’t see. Get an ax and just start chopping away.”

The “Chop” is your process.

It‘s not just for sports.  It applies to all aspects of life – including work.  Define your process for success. Then stay focused, keep applying it.  Keep “chopping wood”.  I will turn.

It’s easy to keep chopping when everything is working.  At the start of a project, teams are newly formed, project plans are glowing with optimism – everybody is following the process.  But then reality sets in.  Metrics and reports start coming in. Some tasks are late. Some are over budget.   Documents are not approved, design reviews fail.  Then it’s gets harder to stay focused on the process.

Coach Schiano speaks of this in the press conference:

“Let’s do what we can do. You can’t control the results; you can only control the process.”

It takes focus and dedication to apply a process flawlessly.  It takes even more willpower to stay with the process when the score – the results – are not going your way.

The score is useful: it tells you two things:

• How well you’re working your process
• If you are working the process well:  How good is your process.

But the score can also distract.  If your results are great, you might relax and get off process. If your results are poor, you can loose faith in your process, and start acting like a headless chicken – expanding tremendous energy without aim and focus.

Does your team have a process?  Does every member of the team apply it?

• How do you define objectives so everybody is on the same page?
• How to you assign work and obtain commitment?
• How to you assess risks and deal with it? How often do you re-plan?
• How do you deal with issues and failure?
• How do you communicate with other teams?
• …

Do not confuse process and audited procedures (ISO, CMM etc.). Of course, these procedures -  if they are used – can be your process. But they can lack details for your particular team. So look at how you work.  Your process is what you do.  Define it as a team.  Get buy-in.  Then stay with it.

Stop looking at the score – Stay on process.

But they raise a valid question: Isn’t it the Team Leader’s role to define the objective?  If we ask questions of team members, about the objective, do we not abdicate this responsibility?  And is there not a chance that the team will settle on a wrong interpretation of the objective?

No, there is no chance.  As team leader, you guide the conversation. You reinforce what you agree with. You discuss the areas you disagree.  The goal is to use questions as a means to clarify – so that you understand what the team members are thinking.  Then you can “adjust”,  if necessary.

Team Leaders, however, find it hard to relinquish control.  So they ask leading questions:

From the coaching file: (TM: team member)

Lead: What to you understand the objective to be?
TM: We must prove that the upgraded sub-system supplies the same functionality as the old system.
Lead: Why use the new sub-system?
TM: The old one is not supported anymore.
Lead : Can you think of other reasons?  (note: starting to lead)
TM: Quality is probably better, easier to validate?
Lead: Hum, that’s true – Can you think about what are the uses of this new-system?
TM: (getting a bit upset)  It’s just about the migration, why should I worry about why we transition?

We can see that the Team Leader  is trying to get the team member to see something – using leading questions to do so.  Roles are reversed: The Team Leader was supposed to clarify the team member’s understanding of the objective – now the team member has to guess where the leader is going.

See what happened, when the Leader agreed not to lead, but to clarify and influence:

Lead: What to you understand the objective to be?
TM: We must prove that the upgraded sub-system supplies the same functionality as the old system.
Lead: What do you include in “same functionality?”
TM: Every thing the old system used to do:  I must make sure the transition did not break the old system. (note: here we see his true focus)
Lead: yes, that’s very important.  But is the new system exactly the same functionality?
TM: Well no, there are improvements – but like I said, we can’t break the old system.
Lead: I agree with that – but does our objective end there?
TM:  I suppose not.

In this example, the Team Lead went on to discover that the team member did not understand the new functionality very well and as a result had naturally focused on the old functionality.  The Team Leader was able to agree on the importance of not breaking the old functionality, but was also able to provide guidance on the new functionality so that the team member could focus equally on both.

Leading questions do not work – they are simply different form of telling:

• Leading questions will usually frustrate the team members.
• Leading questions will not allow the Team Leader to understand the details of how the team members view the objectives.

It is counter-intuitive: Although clarifying questions appear to simply follow the team member’s train of thoughts, they also allow the Team Leader to control the outcome of the discussion:

• Clarifying questions let the Team Leader see what the team members really understand, where they place the emphasis and what they consider important.
• After clarification has occurred, the Team Leader can easily identify what is missing and point it out to the team members to guide the objective definition.

From the coaching file:

When I try to “lead the witness” I never get to where I want to go.  But if I just ask them what they mean, I can drive them to see exactly what I want them to see.  This is weird: the only way to drive is to not touch the steering wheel.

Warning: it’s not easy to catch yourself asking leading questions.  But it’s easy to see somebody else doing it.  One manager I worked with,  found that he usually fell back to leading questions, even when he did not want to.  So he told his team to let him know when he did it.  It worked quite well.

We can assign accountability, duties, even authority – but not responsibility.

Think of a parent responsible for her child.  It’s a “no excuses” kind of responsibility. You can’t force this unto others.

Accountability only lays success or failure at my door. If failure results, I’ll give you reasons why I am not responsible (such as: I did not have authority over the team feeding me late/poor inputs to my work).   Accountability does not make me act extraordinarily.

But if I choose to be responsible, I behave as if I own the results.

Needless to say High-Performance Teams exhibit a high sense of responsibility, which they have freely chosen. But how do they motivate members to take responsibility?

The decision to assume responsibility is more emotional than logical:   Taking responsibility occurs before we know how or if we control all factors. Logically speaking, assuming responsibility is risky.

Consider the following exchange between a QA Team Leader and team member (TM).  From the coaching file:

TM: I am willing to take the responsibility for the quality on this project – but the other people (engineers) have to do their job.  They have to follow the process.

Leader: Don’t you think you have a role to play, in helping them follow the process?

TM: How could I? I’m not their boss. I can’t make them follow the process. Maybe you can because you’re a manager – but I can’t. All I can do is check and report if the process is followed or not.

This is a good example of “not taking responsibility”.  Truth be told, the team member does not even feel responsible for checking the process.  She told us that if the engineers fake it, or hide stuff, she can’t be responsible for accurate quality control. It is logical.

Contrast this with her team leader who chose to be responsible for quality work at the company.  Again from the coaching file:

Leader:  The way you approach and talk to a person determines whether they will listen to you or not, whether they will follow a process or not.

TM: Are you saying I’m supposed to “make them” want to follow the process?

I spoke at length with this QA Team Leader. She is passionate.  She has taken on the responsibility for Quality. Of course, she does not “do” the engineering work.  So she uses her skills to motivate the engineers, who might otherwise cut corners.

Nobody could have forced her to “declare herself responsible”.  She made that choice.

Often we try replacing responsibility with processes.  Then we hold people accountable to follow the process.  But many processes are written as if we were machines.  They do not account for human errors, they do not account for fatigue.  They do not account for a bad manager who demoralizes people. They ignore under-staffing or inexperienced new staff. If all goes perfectly – the machine will work.  But we are not machines even if we idealistically hope to be.  Responsibility bridges this gap.  It drives what we do in the context of the process.

Processes guide us in best practices.  But they are not enough.  We need a declaration of responsibility.

How do we instill responsibility? Here are a few tips that I have seen work in high-performance teams:

• Discuss with the team how they define responsibility.  Where does it stop? Listen for limitations: I am willing to be responsible for X if “they” agree to do “Y”.
• People limit their scope of responsibility to what they feel they can control.  Explore how they can “exert control” in ways they have not thought of.
• Do not give them the accountability, if they won’t take the responsibility. You would be surprised how people react when they realize they are only accountable for 1% of the team’s output.  Remember, taking responsibility is more emotional than rational.  Use it.
• Map accountability for the team.  Look for holes.  Then ask who wants to take responsibility for that missing accountability.
  Example:    Team members take responsibility for their work if the necessary inputs show up on time. Thus, there is no accountability for making sure the inputs show up on time.  Specifically ask if somebody wants to take the responsibility to make sure the inputs show up.

Above all, as a team leader, choose to be responsible for your team’s output.  Do not limit it with external circumstances.  That is perhaps the best way to have the team also take responsibility.

A new Lead Engineer will transfer the techniques that worked in managing her own work, into managing the team.  Most often, this does not work as planned.

If Lead Engineers managed their team exactly as they did their own work, it might actually work.  But they don’t.  They assign tasks, but keep the thinking behind them, in their own heads.

From the coaching file: Coach speaks with Sophia (S), a team leader:

As soon as you‘re told to integrate the database in the product (the task), your experience helps you picture the objective in your mind. You do not speak it, or write it down.  You may not even realize you’re doing this.

• (S):”That’s right – I know what I want to accomplish.

Next you define the steps (sub-tasks) to integrate the database. You visualize it: first I do this, than I do this. In your mind each sub-task has an objective – but you don’t spend time spelling it out.  You’ve done this for many years, and you were good at it.

One day, they said: “Now you’re a Team Leader”. Manage the work of these people.  On that day, what did you know about managing people?

• (S): “Not much”

True, but you did know how to manage engineering work. It’s just bigger tasks. So what’s your natural tendency?  You still picture the objective in your mind and define the steps.  Then you call a meeting, and assign the tasks to your team members.

• (S): “That’s right.”

But get this: when you start out as a Team Lead, you think they will do the tasks as you would do them.  Unconsciously you think you’re leading multiple Sophias to get this large task done. But of course, they are not all Sophias.  Even though you give out the task clearly, team members execute somewhat differently then you would.  They focus on different things.

So you say “why did you not do what I asked?”  But their answer is always:   “I did what you said!” Then it dawns on you:  they did not understand what you meant.

• (S) “That exactly what they say – every time:”   “I did what you said, why are you on my case?”

So what do you do, the next time?

• (S) “I try to define the task better. Also, I check on them more often.  If they are going in the wrong direction, I can let them know quickly, and they can fix it before the review.”

Isn’t it time consuming and tiring?

• (S) yeah, but what can you do?

Actually, you could give them what’s been missing.  You gave them the task, but not the picture in your mind of what you wanted to accomplish.  They understand the task – but they don’t have your vision of the objective.

To my point – Don’t leave out the objectives:

Engineers can’t read their Team Leader’s mind. When they receive a task, they do what you used to do: They define their own “picture in the mind” objective.  It will not be exactly like yours – unless you took the time to discuss your own vision of the objective.

A final point:

Handing out detailed tasks and checking often can work, sort of, if you have a small team and you don’t mind micro-managing.  But it won’t work when you get promoted to lead 30, 60 or 100+ people.  You will have to share your vision of the objectives and step back.  If you haven’t perfected a method to share objectives when you led 10 people, it may be a bit of a learning curve to do it with 100.  So why not start now? You’ll work less and achieve faster results.

I propose a definition of objectives here.  I also discuss how to share them here. I offer it as a starting point you can transform it into your own method.