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

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.

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.

I remember a director at a contract R&D firm. He complained out loud and often about his staff. He had come from a big car manufacturer where apparently they could measure load curves for engines in a quarter of the time it took his current team to get them. Somehow this poor man had now ended up with a bunch of nitwits who could not do it right. Was he right? Do R&D firm hire nitwits?.

Well, he looked at measurable results – that was the good part.  Comparing the time it takes to get load curves told him that his current team needed to improve, and by how much. But it didn’t prove “nitwitness”.

The part he got wrong was that he kept looking at the people, judging them as if they were their results. But he never focused on what they actually did. To his mind there was little else to fix but the staff themselves.  And the results never improved.

People are not the source of improvement, their actions are.

A trivial distinction? Not when it impacts how managers relate to their team. If we believe people are the source of improvement, we can easily assume that there is something wrong with them when improvement fails to materialize. That R&D director told me his staff lacked motivation and/or pride in their work. You name it, they lacked it.

But if we believe that actions are the source of improvement, we do not look for “people flaws” as the cause of failures. Instead we analyze how the work is performed. We objectively see what’s missing. Then we address it.

Taking “people” out of the improvement equation offers a different perspective. Webster’s defines improvement as “a change for the better”. What exactly becomes better? And what changes?

“Better” implies a comparison with what was before. This can only be about results, since only they can be measured. But results cannot be changed directly. It is our actions that produce results. Hence my definition:

Improvement: Changing how we act to produce better results.

Here is an interesting corollary I never truly realized until I pondered the source of improvement:

We get the results that our actions create, nothing more and nothing less.
If we want different results, our actions must change.

Look to the collective actions of the team as the source of improvement:

• What actions must change?
• What are we not doing that we should be doing?
• What are we doing that we should stop doing?

The source of improvement is working differently. Thankfully, figuring out what actions are needed to reach new goals is becoming simpler in this information age. Best practices, empirical research, training seminars, continuous improvement point the way.

How we’ll make everybody work the new way – That’s the real challenge.