The Elastic Leadership Book



        RSS Feed

Latest Entries


My team keeps breaking their promises. What can I do?

Execution – actually having the team get things done– requires people to :

  1. Say what they will do 
  2. Mean it (be committed)
  3. 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.

« The Bus Factor - Why your ‘best’ developer is your biggest problem | Main | Kevlin Henney – 3 things every programmer should know »

Reader Comments (2)

Thanks for the reminder! It is always difficult to understand what a commitment really means. Seen this lack of commitment lead to unfinished sprints and too much added to the sprint queue. Why add more if noone will commit to the tasks?

May 9, 2010 | Unregistered Commenterthommy

Hi Roy,
What a great name and concept for a blog.

I think you've hit on some important points in this post. It's pretty insightful. I also think it's important to emphasize the "5 Whys" practice more specifically in these cases of people not able to commit to something.

In my experience, a mistake that managers or team leads often make is the "Assumption of Ease", which is that they hear a requirement and think, "Wow, that sounds really easy!" What they often do not see and oddly are often unwilling to face is the cost of embedded complexity and inconsistency that they have allowed or even contributed to appearing in the system's code.

This is a very dangerous situation for a project with a tight timeline. Very, very dangerous. I've seen it happen recently where a teammate was asked to solve some inconsistencies and others on the team seemed to think the task was "not a big deal", but the problem was that there were 5 or 6 different ways that people had coded a small feature, and bugs were resulting because of that inconsistency. Thus, what was not necessarily a difficult "technical problem" was a very large and "big deal" time sink for people.

So, one possible 5 why breakdown for this could be:

Q1: Why is it that you don't feel able to complete fixing all those labels by Monday?

A1: I am unsure of how many places in the code it's currently implemented, but I know it's done differently and I don't know all the reasons it was done differently or the expected look and feel or how dynamic it should be.

Q2: Why has this labeling feature been implemented differently in many places?

A2: I am not sure, but I'm pretty sure that there has been a lot of people and not a clear standard.

Q3: Why has there not been a clear standard?

A3: Well, I am not really able to answer that, since I don't have control over making those decisions. But, in my own estimation, I think there was not enough guidance as to how this area of the application needed to behave.

Q4: Why do you think there has not been enough guidance on how this area needs to behave?

A4: Again, while I"m not really sure the real reason, I can say that perhaps when it's requirements were defined there was no unambiguous picture of what it needed to look like or whether it needed to be consistent in one area or not, and therefore no standard was set. It's understanable.

Q5: (Five might not be enough here!) It's true that there has not been a clear vision or standard on this feature. Why is it important that there be an unambiguous requirement for this feature?

A5: Well, I think it's all about two things. One is for stakeholders and business people being able to say that they, or anyone, understands exactly WHAT is needed, not necessarily the HOW, but a clear picture of WHAT is needed is the first thing before those of us developing can deliver it. Second, a clear approach for HOW to achieve it is needed so that there is no question and that people can feel comfortable knowing where to go in the code and HOW
to implement this requirement in accordance with WHAT is needed.

Well, that was tiring!!! But, it was useful in my own mind at least.

Take care,

September 10, 2010 | Unregistered CommenterJosh Gough

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>