(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?
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.
