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.
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.
Most companies have risk management processes. And most teams follow these processes fairly well. Why is it, that with same risk management process, some teams succeed at avoiding big problems, and while other teams fail to do so repeatedly?
I am sure there are many reasons – but I have noticed one that is not often mentioned.
Failing teams have a culture of risk-avoidance. Successful teams have a risk-embracing culture. They are diametrically opposed – and it affects how they deal with risk.
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.
I will be speaking in Pittsburgh on “Building High-Performance Engineering Teams“. The event is organized by the SSIT section (Society for Social Implications of Technology) and GOLD section (Graduates Of the Last Decade). The event is held at the Westinghouse Energy Center, Monroeville, PA (map) at 6h30 PM, Thursday May 27.
Here’s a link to the IEEE Pittsburgh monthly newsletter (pdf file: see page 4 – bottom) if you want to see the abstract. It is requested that you RSVP at the email address given in the newsletter if you would like to attend. There is no fee. You do not have to be a member of IEEE to attend.
My discovery of the “local” IEEE (Institute of Electrical and Electronics Engineers):
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?