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.
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:
- Define it for yourself
Write the key points of the objective, then prepare a general overview statement. - Give the Team an Overview
Read them your overview (NOT the key points). Stop talking, start asking. - 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. - 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.
- 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.
