When I was a young manager, I read “The One-Minute Manager” by Blanchard and Johnson. I learned to “manage by walking-around” and “catch people doing things right”.
As a motivational tool, catching people doing things right is effective. But it doesn’t work long term if all you is praise their results.
I led the winning team on a bid worth $85 M in Hong-Kong. It was complex, with months of technical, commercial and legal negotiations. The team gave all it could, and then some.
Coming off the plane, I went to the office and attended the celebration party. Executives, heads of department and the entire team drinking champagne (yes, they allow this in France). Speeches. How happy the executives are. Proud of the team who worked so hard.
It was nice. The bonus was nice too. But it did not change much. Business as usual the next day.
But not for me. I had been debriefed, the “Encouragement” way.
When doing risk analysis, engineers have no problem identifying potential problems – answering the “what could go wrong?” question. The difficulty is with the mitigation plan – “How can we prevent it?”
Going over this problem in many coaching sessions, I discovered one reason why this is so
Engineers skip the middle step, of this three step process:
- What can go wrong?
- Why would it happen?
- How can we prevent it (or at least lessen its impact)?
Intellectually, it makes sense. If a risk has actually occurred, it’s now a problem. The normal engineering response is to perform a root cause analysis: “Root out the cause –the solution will be obvious” my first boss used to say.
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.
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.
On November 9th, 2006, the Rutgers football team was having a bad night – but they just kept “chopping wood”.
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.”
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?
The biggest fallacy I have encountered in corporations is the belief that we can assign responsibilities. Responsibility is by choice – never by assignment.
We can assign accountability, duties, even authority – but not responsibility.
Think of a parent responsible for her child. It’s a “no excuses” kind of responsibility. You can’t force this unto others.
Accountability only lays success or failure at my door. If failure results, I’ll give you reasons why I am not responsible (such as: I did not have authority over the team feeding me late/poor inputs to my work). Accountability does not make me act extraordinarily.
But if I choose to be responsible, I behave as if I own the results.
Needless to say High-Performance Teams exhibit a high sense of responsibility, which they have freely chosen. But how do they motivate members to take responsibility?
Lead Engineers are promoted to Team Leaders typically because they were great at completing engineering tasks.
A new Lead Engineer will transfer the techniques that worked in managing her own work, into managing the team. Most often, this does not work as planned.
If Lead Engineers managed their team exactly as they did their own work, it might actually work. But they don’t. They assign tasks, but keep the thinking behind them, in their own heads.
From the coaching file: Coach speaks with Sophia (S), a team leader:
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.