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.

I have often been asked how the High-Performance behaviors of successful teams differ from the not-so-performing teams I have met or worked with over the years.   Here’s a selection of topics – by no means all inclusive – that show this.   Look at this as a spectrum: most teams fall between the two extremes – but usually they lean towards one column or the other.

“Whether you believe you can do a thing or not, you are right”  (Henry Ford)

People are capable of doing great things. Whether they do great things is up to you, the Leader.

As leader, you must believe that the team can achieve great results.  In fact, believe more than the team itself is willing to believe. You can’t fake it though.  It must be genuine because people can always tell.

From the coaching file (in a seminar I gave):
“Norm, this is all fine and good, but how do you use your methods when some engineers can’t even be trusted to get a can of soda from the corner store?”

What is the likelihood that these engineers will actually go the extra mile for this manager?

(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:

We are creatures of habit. We operate within our comfort zone and resist change that makes us act outside of it. The resistance level is proportional to how far outside of the comfort zone we are asked to go. Thus a change program must move our comfort zone by increment towards new practices. But that is not enough.Teams exist because we are creatures of habit. We need the consistency of others. It allows us to operate within our comfort zone within the team. In fact the team culture mandates it.

Culture is not something we define or prescribe. It emerges. It is a tacit agreement between all participants. I like to think of culture as an unconscious jigsaw puzzle, where each individual comfort zone is made to fit together. Team members fit in the team by adjusting their actions slightly. If we are in a team long enough, these adjustments become part of our comfort zone. And that’s the problem.

I have argued that improvement only occurs if we change our current actions. From books to seminars to training programs, finding best practices that will give better results is straightforward. Getting the whole team to adopt these is the problem. To implement change it helps to understand what we’re up against.

We individually resist change because we act within our comfort zone. And we can’t change that.

Though we would like to think otherwise, we are predictable in how we work. We favor actions and methods we have already mastered. We are creature of habit, because we trust our habits to produce repeatable and acceptable results. In this comfort zone, we are relaxed, confident, focused. We know how. We have experience. We may not always succeed, or produce great results, but we rarely fail.

It’s not that we don’t like change. In fact we crave it. We want to improve, to get better. But to produce better results we must act differently. This means doing things outside of our comfort zone. Unconsciously or outright we ask ourselves: Will I succeed? Will I do it right? Will it work, for me? Isn’t it most likely I will fail at first?

I am training a group of engineers and managers on planning R&D work. And I’m getting nowhere. A manager and his best lead engineer keep attacking every thing I say.  For every example, they have a counter example.  For every method, they are already doing it, only better and different.  They never really overrun projects.   Not if you take into account the fact that clients changed scope mid-project or management undersold it in the first place.

I’m at my wits end.  But then I see it.  I am up against “the” roadblock to change:

“That’s not how we do things around here!”

During a break, I asked the functional manager:  Why are you here?  “Management think we don’t know how to do our work”, he said.  “The CEO blames us for overrunning. But in fact, if it was not for us, they’d be doing worse.  We’ve been doing this work for 30 years, I think we know how by now”.