Execution – actually having the team get things done– requires people to :
- Say what they will do
- Mean it (be committed)
- Do it
Everyone likes to do #1. Only some do #2. Great teams also do #3.
This post is about #2.
There is a vast difference between people being committed to something, and people saying something.
For example, you can start looking for words that are not committing to execution:
- “I’ll try to get that to you by Monday”
- “Someone should get that thing fixed”
- “I hope to get to that later”
- “I think I can make it”
spot these things and see if you can ask people to actually commit to the thing they need to do:
- “I will do this by Monday”
- “I commit to getting this done by Monday”
- “It will be done by Monday”
If someone can’t commit to that – that’s good. Maybe they are not sure they can – maybe there is something stopping them. But you won’t know until you can either get them to commit, or get them to say why they cannot commit to it.
Also notice how there is a specific end date. Committing to something with an end date make things more real, and also prevents whoever is depending on that thing from bothering the doer. “Is it done yet?” “How about now?” .
No need to ask. They committed to do this by Monday.
Don’t under estimate peer pressure.
Doing all this talking in an open daily standup makes the commitment more important. it’s not just you and someone else. now it’s you telling the whole team you will get something.
If your team members don’t know how to verbally commit to something, you can teach them. You can actually ask them to say things differently:
“Can you say you will do it by date so and so? Is that something you can commit to? Why not? “
I can’t commit to something I don’t have control over
Of course, the biggest hurdle is that sometimes people really can’t commit to something if they don’t have full control of it. Expecting people to commit to something that depends on other people is less realistic.
If that happens, see what things that person can have control over. For example, if the task is about getting a bug fix to a client and making sure it’s closed by Monday – the dev might have control over actually sending the email to the client, but they have little control over when the client responds back. In such a case they can commit to sending the fix to the client .
Failing commitments
There should be no such thing is a failed commitments. the moment one sees that they will not make the deadline, they should notify whoever they committed to, that they will no make it in time – this allows the team to see if something can be done to maybe still get that thing in time by reorganizing or changing priorities.
A failed commitment means you won’t live up to what you promised and you didn’t notify anyone beforehand that you will not make it in time. that is something that is fully under your control and should not happen.