Last week as I was discussing objectives with a group of engineering managers, I was reminded how that little voice in our head prevents us from listening.

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.

I have a received a few “raised eyebrows” comments about my statement that people don’t listen.  A manager said to me:

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

Continue reading »

You can ask questions, or you can judge.  But you can’t do both.  You have to choose.

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.

Team leaders readily switch to question mode, once I demonstrate that their team does not understand the objective if they simply tell them.  This is why I recommend to Ask – don’t tell.

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?

I have recommended that team leaders set objectives through a team discussion.  At a minimum, you should ask the team about their understanding of the objective.

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?

I advocate defining objectives instead of itemizing the steps of the task. But when Team Leaders try it, it does not work too well. At the design review they still don’t get what they were looking for. They discover that the objectives were not understood the same way by each team member. Is something wrong with the Objective?

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.

(for reference: my definition of Objectives )

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?

(this post refers to my definition of objectives)

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.

There are two parts to a good objective:  Purpose and Stop Criteria (also called “the end state”).

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: