Some context: I look at objectives as having two parts: A purpose ( “why are we doing this work?”) and a Stop Criteria (“ how do we know that the work is good enough).

We had covered the purpose of the current task easily. But nailing down the stop criteria was difficult. To focus the discussion, I asked a question, and promptly received an answer to a different question.

From the coaching file:

Coach: What are we trying to really get at, when we discuss the concept of stop criteria?

Mgr #1: We want a clear message of what the purpose is, …

Coach: I suspect that my question did not register correctly. Could you share with us what question you heard me ask?

Mgr #1: You asked: “What is the purpose of doing this exercise in a team environment?
Mgr #2: You said: “What’s the purpose of discussing the objective?
Mgr #3: I took it differently. I thought you were asking “Why are we doing the Test Procedures?”
(note: test procedures was the task we were discussing)

The astute reader will no doubt have noticed that none of the participants heard “stop criteria”, which was the focus of my question. But my point is not that there was a misunderstanding – that was obvious and easily fixed. The interesting question is:

How is it possible that three people hear different questions, and none heard the actual question?

I have written about this. We humans don’t listen.

No, we are mean or self-centered. We are just built in a way that makes it hard to listen. Our brains are pattern recognition engines. Experts say that we would not be able to function if we tried to remember everything we hear or see (too much input). Instead we map what we hear to previous patterns (read experience). But when we find one, we hook unto it, and think we have “understood” because we have matched a pattern. At that point we are listening to ourselves – the pattern – rather than to whomever is talking.

We do this naturally, without effort. In fact, trying not to do it – which is possible – requires effort and concentration.

So why is this important to managers of engineers (or other knowledge workers?).

Have you ever discussed a task or an objective with your team, to find out later that people did not do what you said? If so, you saw people’s pattern recognition at work.

If you asked them, your team likely said they understood you. They did exactly what you wanted. But in fact, they did what they thought you said – the pattern you triggered by talking to them.

I’ll be blunt: telling people what to do, does not work. Because they don’t hear us completely. (Cue in protest and screams!)

If you want your team on the same page –find out first on what page they are on.  Ask them what they understand the objective to be, before you tell them what you think it is. Then, and only then, adjust for what’s missing – if any.

I call it – Management by asking questions.

A word of warning. Using this post to tell people they don’t listen, and asking them to start listening,  is asking for trouble.   Must better you just ask them what they think – and try listening to them first.

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

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 you can  discuss if they are wrong.  But they will not  share their 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.

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.

But team leaders still report their team is not “on the same page”.  They reformulate what the team said – and everybody seems to agree. But at the design review, they find that not all was clear to everybody.

What gives?

Reformulation as a means of checking understanding is a bit like going to the fair and standing between two funny mirrors that face each other: your image gets distorted a bit more with each back and forth reflection.

Are you sure you understood what the team member said? And are you sure they understood that you understood? Is there a way to break this cycle?

When discussing objectives, you want to be on the same page.  The “little voice in your head”, which is commenting on everything you hear, looks for agreement – and finds it.  Then you reformulate, and they want to hear that you understood them. So they find agreement.  And we’re a happy family…

I understand your understanding of my understanding as a confirmation of what you meant. Meeting adjourned, let’s start!

I for one, no longer trust myself to understand correctly.  So I make sure to break the hearing – interpretation cycle. There’s a very simple way to do that:

Listen with a pencil!

When a team member is speaking I write down the key points they say – exactly as they say them – with their own words. My little voice finds this so boring, it gets out of the way. Writing down what they say means I hear what they say.

I split the listening process into 4 steps: Write – Regurgitate – Clarify – Reformulate.

1. Write down key words exactly as said by team members.
2. Regurgitate by reading back to them what you wrote,
3. and immediately asking clarification questions
4. Finally, Reformulate by sharing your understanding, and ask if it is correct.

From the coaching file:

Team member:  “We plan to prove there are no technical gaps in the customer requirements”
(Leader writes: “Prove”, “technical Gaps”)
Leader: (regurgitating then clarifying) “When you say ‘Prove no technical gaps’, what do you mean by Gaps?”
Team Member: “A technical gap is when there are two customer requirements that conflict with each other.”
(Leader writes: “conflict”)
Leader: (regurgitating) “So at the end of the task, you will prove that there are no client requirements that conflict with each other?”
Team member: “Exactly”
Leader: (now sharing her interpretation) “So I guess your objective is to make sure we don’t end up with requirements that we cannot implement because one says black and the other says white, for example.
Team member: “That’s exactly it – That’s one of the biggest problem we get, so we need to get rid of it at the beginning”
Team Leader: (adding further interpretation comments) “I agree. But a first, I was confused by the word ‘gap’ – I thought you meant ‘holes’ in the customer requirements –you know, something missing.”
Team member: “Oh no, that’s a ‘completeness analysis’ – that’s a separate task.”

Note: when I heard this exchange, I too was confused: my little voice had interpreted “gaps” to mean something missing – not conflicting.  It’s a good thing the team leader did not let her little voice assume that she had understood.

Why should you do this?

The obvious benefit of listening with a pencil is that it stops the “little voice in your head” so you can really hear what is said – and take time to understand.

But it also makes it clear to the team whether you are stating your opinion or simply echoing what you think they said, trying to understand them. Thus, the following cannot occur:

From the coaching file:

(Leader)  “So I understand that you want to perform tests that exercise every possibility of error.”

(Team member) “That’s not what I said!”

(Leader) “Well that’s what I heard.”

Let’s face it; we don’t listen well at the best of times. When we have an agenda, our listening is skewed. Our mind is too busy trying to decide if what they say is in agreement with what we think.  It can’t focus on what is said and what is actually meant.

Listen with a pencil.  Read back what you heard – without the little voice getting in the way.  Then discuss what it means – with the whole team – to get on the same page.

Most technical Team Leaders have proven their technical chops. I assure you, the objective is just fine. But “telling” the objective to the team does not work. Here’s why

Humans hear but they don’t listen.
Or at least – they don’t listen well.

From the coaching file:

I often tell a team leader that “Humans hear, but they don’t listen”. Later in the session, I’ll ask, “Do you recall what I said about listening?”

• “You said that my team members don’t listen to me”
• “You said that I don’t listen”
• “You said  People hear what they want to hear”
• “You said People don’t understand each other“

Wow! I said none of these things. But they swear that I did. They actually remember me saying something I did not actually say.

So what’s happening here?

The fact is, we don’t really listen to the words we hear. We are too busy listening to that little of voice in our head, which is running a constant commentary on what is coming through our ears. We interpret what we hear – continuously.

Try it. You have to concentrate to quiet that little voice. It’s not so easy to recall exactly what somebody said.  It’s a lot easier to recall what we thought of, or how we felt about, what was said.

We are not computers. We can’t store what was said in one location, and our opinion of what was said in another – for further analysis. So we tend to listen to our interpretation. And when we tell the objective to the team, the team members listen to their own interpretation of it.

From the coaching file:

“I tried an experiment. We had to perform a simulation study. I defined the objective to the team. Then I asked each engineer to write down the objective and the stop criteria I just talked about. Then I read the answers out loud.

It was rather humorous. The answers went from a back of the envelope calculation, to a full computer simulation in a 20-page report. There was quite an argument among the team!”

There is a simple solution: Ask, don’t tell.  Try defining objectives this way:

1. Define it for yourself
   Write the key points of the objective, then prepare a general overview statement.
2. Give the Team an Overview
   Read them your overview (NOT the key points). Stop talking, start asking.
3. Let the Team Define it
   Ask the team what the Objective means to them. Discuss purpose, and stop criteria. Ask questions to clarify – don’t judge right or wrong.
4. Adjust Focus during the discussion
   • Reinforce points on your list: “Yes Jim, that’s key for this project”.
   • Introduce missing points with a question: “Do you think we need to consider the quality aspect at this time?”.
   • If a point is not on your list – and doesn’t belong on it – try to understand why the team thinks it should be: they are misunderstanding the objective.
5. Conclusion- Recap
   Recap the key points of the objective, using the words the team used (Do NOT simply read the key points on your list).

There are “gotchas”.  Don’t force the discussion to your key points only.  Don’t dictate through fake questioning – “leading the witness”.  Ask – don’t tell.  And don’t let the discussion degenerate into an argument.  It is not a democracy.  When team members have clearly expressed their understanding, indicate what is in – and what is out.  Your goal is clarity – not consensus.  You are the Leader – they expect you to do your job.

Warning: Your team might start to think they don’t really need you since they are now apparently setting the objectives – and then doing the work of the task.  They might even tell the VP, who realizing you don’t seem to do much with that team anymore will likely promote you to something that gives you more work – and more pay.  That is the risk.

From the coaching file, here’s what engineers tell me:

I hate to go to design reviews to find out what I did is not what They wanted – never mind that the specs weren’t clear about it in the first place.

I am being micro-managed by my Lead Engineer who keeps fiddling with my tasks every second day – as if he didn’t trust me.

I went into engineering to learn to solve problems – not to follow exactly how somebody else who got to the company before me wants me to do it.

I’m tired of having to get approval for every solution to every problem I hit on my task – just because the lead engineer wants to make sure we do what “They” want.

These comments are symptoms of teams who don’t discuss objectives.  Instead, Team Leaders assign tasks by explaining how they want them done.  Why do they do this?

Because Team Leaders don’t really know how to define the objective - out loud.

I asked Team Leaders, “Do you have an objective?”  The answer is yes .  They have a clear picture  in their own mind.  “So, why do you define each step of the task for the team?”, I asked. They believe that if the team understands every step of what should be done, then, they can get to that objective. And they said,  it’s better to check on small sub-tasks often and “realign” the engineers if needed.

I, for one, loose my enthusiasm if I’m realigned too often.

We all need to know where a task is going to do it right.  So when engineers are not explicitly given a purpose and a “good enough” criteria (objective) , they make one up – in their own mind – based on their experience.   They don’t think long about it.  It just happens.

This works pretty well if the engineer and the Team Leader have been working together for many years – because they know how the other thinks.   Otherwise…

From the coaching file:

“We don’t have time to do it right the first time.  But we have time to do it twice.”

“We did everything right – but it was wrong!”

Defining sub-tasks instead of objectives is costly.  All that defining and checking and arguing and reviewing, it wastes time.  It’s bad for morale.  It’s the reverse of buy-in.  It does not engage the engineers fully and stifles creativity.  And that’s just for starters.

Discuss the objectives.  Talk about that picture in your mind, so the team shares it, and let the engineers use their skills to get there.  You will  check less and understand more.  You may find yourself listening to engineers explaining how their solution gets to your shared, clear objective, and being impressed with their solutions.

My mission:  In every team, create a language of objectives, replacing the current language of tasks -  for assigning work. This leads to work done once, with everybody on the same page.

It takes practice.  But it works.

When I led my first electrical engineering team, we did not discuss Stop Criteria. We did not discuss objectives much either. We talked about how to do the tasks. We asked “how long do you need to get it done?” And answered: “That’s too long”. Call us the typical team, keeping its head above water. It was not working.

This was the late 1980’s and we were building a small rugged computer + software to run the engine of a car. Another team – mechanical engineers – worked on the fuel flow equations. But the equations changed every week! And in those days, microcontrollers came with lots of outside logic chips that needed changing as a result, so we could never get a stable design. Something had to be done.

I headed the delegation to the project manager to insist that the mechanical engineering team stop changing the equations. That failed. Something about electrical engineers not getting it. We needed a different approach.

We took a step back to discuss our objective – which involves defining the purpose. “Why are we developing this computer?” We were thinking: To run the fueling program of the engine. But we were wrong. That was a small part of it.

Our correct purpose was: Build a computer that could run – on the test car, in real-time – equations that changed week to week. It was our job to figure out a design that would allow for that.

In retrospect, it might have been a good idea for the Project Manager to make that clear – but he told us it should have been obvious. It was to him.

So now, we had a purpose. That’s half the definition of an Objective. We also needed our Stop Criteria. When could we stop working on the design? When would it be good enough?

The trick was to look at our end users. We interviewed the mechanical engineers. They could give us a new set of equations Friday evening, and they would be happy to be on the car testing by Wednesday noon. So we came up with our stop criteria: We would stop designing when we could prove to ourselves that we could turn around a new set of equations in two and one half days. The rest was technical: proving the design could handle that was relatively straightforward for electrical engineers.

* * * * *

These days, I work with teams discussing stop criteria. It’s still not so easy when teams are used to discussing tasks. So here are some of the examples I have collected in coaching sessions. Nothing is ever perfect. But I like these. I feel if I was working on those tasks, I would have a good understanding of what I must deliver.

From the coaching file:

In some cases, the stop criteria will be specific (sadly – it’s a minority):

• A simulation task that provides a margin of error less than 10%
• Software changes that pass all existing regression tests for all modules and classes in sub-system

In some cases, it is subjective – a picture of the mind – the meaning of which must be discussed to be agreed to:

• Using only our documentation, the customer’s engineers must not only understand the functionality but they must also be able to train their own technicians without our help.
• Existing user must not have to relearn how to use existing functions after we update the user interface. Design can stop after we can demonstrate that existing usage is not affected by additions to the user interface.
• User actions should not cause a failure of the system. Even though we cannot fully test for this, we need to imagine a large number of user scenarios, and no matter how weird the action, or sequence of actions, our system must be shown to withstand it and not fail.

Sometimes, it’s in between:

• Each and every technical requirement in our internal specification must link up to at least one customer requirements (objective part). The written description must be free of ambiguity. Our software and hardware teams must understand and interpret correctly what we have written, even if they have not read the customer specifications themselves. (subjective part)

* * * * *

If you feel like it, post a few more examples of your stop criteria. It could be useful to others reading here.

1. Purpose: Reason(s) why the task needs to be done
2. End state/Stop Criteria: Explains when to stop working on the task, because the desired quality and characteristics of the results have been achieved.

These are typical questions to ask, to define the objective:

• Purpose:
  • Why are we doing this task?
  • What is it important?
  • How will its results be used (by following tasks or people)?

• Stop Criteria:
  • Level of quality required (of course, define what quality is for the task)
  • What do people want as results of this task, to ensure they succeed at the tasks that
    follow?
  • What is an acceptable result versus what is unacceptable?
  • How do you decide that the work you have performed on the task is good enough – so that you can stop working on it?

What an objective is NOT:

Objective is not a task description:
Many engineers attempt to define the steps (sub-tasks) to complete the task.  They think that the desired results are logically obvious and need little additional discussion.  Don’t do it.  It’s only obvious to you, I promise.

Tip:
Do you define good objectives? Try this:

Write your objective.  Then ask a co-worker to cross-out any fragment of a sentence that deals with how to do the task (look for action verbs).  What’s left?  Does it address purpose and stop criteria?  If not, your objective needs to be clarified.

Objective is not the Deliverable:
Deliverables are just a list of output.  You need the objective to qualify the deliverable.

• Example of deliverable:
  • Production drawings
  • System requirements
• Example of Objective:
  • Production drawings in a form that nobody needs to call you to clarify details later.
    (This is a real issue from my coaching files – when new products are sent to production).
  • System requirements that are not ambiguous: the software group will not make the wrong interpretation.

Discussing objectives is a good habit to develop.  You’ll find defining the purpose straightforward.  Defining the Stop Criteria takes a bit more practice.

* * * * *

To read more:

Military doctrine defines a concept called “Commander’s Intent”, a good example of Objective:

• A concise expression of the purpose of the operation
  (purpose is defined as the reason for the operation with respect to the mission of next higher unit)
• A clear expression of the desired end state
• It is the single unifying focus for all subordinate elements.

The exact source can be found here (pdf format) on page 5-10, article 5-55.

There are many military blogs on the subject, for example this one.