I’m told that one quote preachers try to live by is, “If it’s foggy in the pulpit, it’s cloudy in the pew.” In other words, as the leader and communicator, if you’re unclear about any part of your message, it’s a sure bet everyone else is as well.
You don’t have to be a preacher to risk setting unclear expectations. If you’re responsible for performance outcomes of any kind, unclear expectations could be your biggest kryptonite. In fact, if the expectations you set are unclear, you force members of your team to work as much as three times as hard.
Consensus on the Intention Must Be Reached
With unclear expectations, before any work can be done, the folks performing the work must determine what they think the expectations are. Depending on the size or scope of the project, this could require significant time and energy. When an entire team is involved, the level of effort, time and cost adds up quickly.
The Original Work Must Be Completed
Regardless of expectations, the team must complete the initial set of tasks.
Constant Troubleshooting Must Be Performed
This is where the cost really multiplies. Whenever new information comes in, the team must halt their progress and redirect. In many unfortunate cases, additional re-work is required.
And this doesn’t factor in the cost of morale lost in the process!
So how can you make sure you’re expectations are clear as crystal?
First, always assume that the expectations you give will be misinterpreted. Then go the extra mile to reiterate your message. At the very least, for everyone performing the work, provide clarity of outcome and clarity of role.
One of the reasons the best bosses have the highest engaged teams is because everyone knows where they stand in relation to the goal. No one has to wonder and feedback can be more focused on what’s next, not what’s wrong. So go the extra inch – or mile – to create clarity from the start. Everyone comes out on top.
Nathan,
Two things come to mind from your post. First, I think of “rock management.” This is where a leader tells the team, ” I am thinking of a rock, I am thinking of a rock, now go get me a rock.” The team goes out and selects a rock and brings it back to the leader. The leader looks at the rock and says, “that is not the rock I was thinking about.” As you mention, this is expensive and can be very deflating to the team that has worked diligently to deliver, only to hear they have delivered the wrong result.
Second, when I was working in software development, it was always emphasized to spend more time on requirements definition (asking the users what do you want this “rock” to do) than on actually building the product. The reason? Changes are much cheaper to make in the requirements definition phase than after the coding or development phase are in process. The same principle applies to your post concerning project expectations.
As leaders we need to ensure we are clear. If we don’t know what we want, we need to tell our teams that we need their help with exploration of alternatives first, and then definitively decide on the direction to go. Who knows, the team may take more pride in ownership if they are in on the idea generation phase.
All the best.
John
Thanks John – my favorite phase in consulting is the analyze phase where you gather all the requirements. Kind of funny how it works that as a consultant you are responsible for getting the expectations yourself instead of relying on leadership to feed them to you. Maybe there’s another lesson in that somewhere!