What techniques I could use after I discover that one of my team members keep agreeing on time lines, but he does not communicate he will not meet those dates until the 11th hour (I mean just before the day).

When I ask him about his repeated behavior, I get a reply in the lines of:

I have been cc:ing you in every email of all my other tasks, so I assumed you knew the task xyz was getting delayed.

Other members of the team are have similar experience with this individual. The functional manager of this team member is also trying to change the behavior, but is still impacting parts of the project.

  • Does this person have one manager, or multiple managers? Commented Feb 24, 2011 at 6:38
  • One manager....
    – Geo
    Commented Feb 24, 2011 at 11:58
  • 15
    Please stop calling him a "resource". If you thought of him as a person, and asked, for instance, "How to help an employee meet his deadlines or more effectively inform us of delays" then different ideas might come to you.
    – Lunivore
    Commented Apr 14, 2011 at 10:00
  • 2
    @Lunivore, you are right the word resource is too objective and emotionless. For sake of space and time of the fellow forum readers I try to keep the information simple and to the point. The reality is that the team asked him about the situation, we even obtained estimates directly from him and also other team members offered him help. Thanks Lunivore for your honest comment.
    – Geo
    Commented Apr 14, 2011 at 12:01
  • I would verify if your employee is afraid to lose his or her job, because if it is the case, he or she can try to delay work or accumulate it to keep his or her job a longer time. He or she can also develop a specialty on his/her own and/or keep information only to himself/herself for the same reason. When an employee is assured that he or she will have enough job to keep his or her job a long time, the tensions in the company disappear quickly.
    – user30807
    Commented Apr 4, 2019 at 23:29

18 Answers 18


I'd approach the issue from two sides:

  1. Measuring progress. If you set a big task which is either done or not the only thing you can get is information whether it is done or not. Zero or one. However if you, or discussed person, split the task to a set of smaller pieces of work you can more easily tell where you are - we have 3 out of 12 done which means that you're ahead/behind/on target according to the schedule.

    You can do this as well as asking for updates of percent complete but then you are more likely to hear that you're going with the plan from 0 to 90% and then everything is stuck.

    Also to avoid waiting to the last moment for the information you're not getting what you expected set a more frequent update schedule. You want to hear current status every n hours/days/whatever. You may need to remind the person to deliver their status update, but hopefully they can learn to do this. If not you have a problem somewhere else as well (with the basic work organization of the discussed team member).

  2. Clearly setting expectations. This is something we often forget about. We don't tell what exactly we do expect from team members. In other words if we don't tell we need to hear about the slip at the very minute you're falling behind the schedule, we shouldn't expect everyone would willingly come to tell us about that. If we don't tell we need regular status updates in specific time slots, we hardly get any. If we don't clearly explain that being CCed on email doesn't mean we are able to decide whether we are on time or not, people may assume that.

    Whatever method we choose in point 1. we should clearly explain what we expect or request from the team member (or team members). Without that we can address the issue to our communication problems and not discussed person's bad self-organization and poor communication.

  • 6
    In addition, start adding padding in your schedule for tasks assigned to this person. There is no compelling reason to publish the extra padding, of course. He's now proven to be a schedule risk so you have to mitigate the risk.
    – SBWorks
    Commented Mar 1, 2011 at 9:10

Good question.

I find if I am working with someone like this that I need to leave no room for doubt. You have to become pro-active. Make a point of asking for updates, follow up and make sure you actually get the updates. Gently but firmly insist that this person provide you with the detail you need for the project to be successful. You need to make sure there is no wiggle room, if you do leave wiggle room it sounds like this person will wiggle out of his commitment.

I have found in dealing with folks like that that you don't need to do this for too long before they understand they will need to be responsive to you and they start at a minimum communicating more normally.

One word of caution... don't let this become personal. Keep it about the project, never about you and never about the other person. If this person turns it around you want to be part of the team that helped him/her turn it around. If he/she doesn't turn it around chances are good this person will be losing their job - either way you want all your actions to be professional.

  • 6
    +1 on the be professional part. Sometimes people do surprise you and turn it around, and your attitude plays a major part in their ability to turn it around.
    – jmort253
    Commented Feb 24, 2011 at 3:59

When faced with this kind of challenge (often, in the past) I ask myself (and then, the team) some questions:

  • What's wrong with our system here that allows this kind of thing to happen?

  • What's up with the social dynamic in this team that makes it hard for people to break "bad news"?

  • How can we all help each other (including the person in question) to reduce the occurrence, impact of this issue?

  • Why do I feel it's "my" team, and why do I feel I have to be "the one" to find the answers?

And finally, if it really IS an issue specific to ONE person, (it almost always ISN'T), then consider applying the Toyota-ish policy of 3R's (Retrain, redeploy, remove - in that order).

Don't forget, how you (collectively) resolve the issue WILL have an impact on the social dynamic (for good or ill) for months or even years to come.

¬ Bob @Flowchainsensei

See also: post by David Joyce mentioning the 3R's


Does this person give to you his time estimate or you give this estimate?

What Is would do is to ask how much time do you think the task could take, compare with your estimate, average and ask commitment from the person because he is giving a confident estimate he have set.

When you ask for estimate, the person psychologically commits to the estimate, if you set it, they will feel it as pressure and the performance in some people can decrease under this circumstances.

Other issue I can imply from the question is, he have more than one manager, what % of his time is he commit ed to each? Does the other manager interfere??


When I ask him about his repeated behavior, I get a reply in the lines of: ...

The question is what are you doing next? What are the consequences for this particular person, for you, for your project? I assume that almost nothing happens.

In order to solve this situation get back to Human Resource Plan, and analyze, whether:

  • motivation is clearly defined for every team member
  • rewards and penalties are objective and explicit
  • everybody agreed on this plan
  • + Point to answer because refers to PMP BOK. The BOK has knowledge on hot to act when this problems presents. Commented Feb 25, 2011 at 19:49

I think there are a couple of possibilies, but you're the person on the spot, so I'll defer to you on which one it might be. I'll just throw these ideas out there for you to decide on:

  1. The person is terrible at confrontation, and they agree to the deadlines because they are incapable of saying "no." CC-ing you on all the emails might be one way of them trying to tell you they can't meet the deadline without the stressful/fear_provoking step of actually saying it out loud. This might be an assertiveness issue (which can be fixed) or it might be a cultural issue (and beyond what you can fix).

  2. The person is incompetent. They are over their head and don't know it. I've got a friend in this situation, and he can't face that he's long past his "sell by" date. He hasn't been keeping up with technology, but he has a high maintenance wife and so he can't afford to go back to school (he'd be 60 by the time he's done with a bachelors) nor can he transition to a less demanding career than programming. My friend is really good at blowing smoke up your butt and cc-ing you on everything. Since he is also wonderful with manager-speak, he comes across to managers as a highly competent person, but in scrums, his peers will quickly identify his lack of progress and call him on it. Ask this person's peers in confidence, because it is really hard to fake technical competence and very easy for managers to get a warm fuzzy feeling with all that smoke blowing up their butt. The cure for this is to let the incompetent "work" somewhere else.

  3. The person is overworked. This might be because they can't prioritize, or they might have too many things to do. I'm reminded of the scene in Office Space where Peter mentions that he reports to 8 bosses.

  4. The person cannot handle interruptions with any skill, so all interruptions derail them to the point that they can't meet any deadline. If you've read any of Covey's books, you will have come across the Four Quadrants. Many folks have trouble distinguishing between quadrant 1 (urgent && important) and quadrant 3 (urgent && !important). This gets called "the tyrrany of the urgent." Resolutions of this situation will involve teaching them time management practices.

  5. The person cannot prioritize things. As above.

  6. They're (marginally) ADD and have trouble getting into "flow". I have no recommendation for this one, and if you do find a fix for it, let me know, because I'm in need of it too.

  7. They are worse than terrible at estimating. looks around guiltily...

  8. They are bored with what they are doing, and aren't working.


First thing should to point out the obvious, which seems not be for him: cc:ing email is not communicating. When he realize the deadline will not be made, he have to get to your office and say it. If you commonly use chat, it can be an acceptable alternative, but any asynchronous communication system simply can't! Because that information is too important to be delayed.

Second thing is: this person may be demotivated. He's not meeting the deadlines, and he's not giving a heck about it. So you should do something about his motivation if you want to help him to improve.

Third: what's your reaction when you hear (early) that a deadline will not be met? For example, if you are yelling at people (I'm not accusing you of doing that), it's no wonder people are waiting as long as possible to give you the info, by a way not implying being near to you. But if he's the only one with that problem, it's probably not the issue.


Unlikely you'll ever change this person's behavior.

Build in the expected variance into your schedule.

Move them out of the critical path.

  • 1
    Not a bad answer; but doesn't affect the root problem -- just gives it to someone else.
    – ashes999
    Commented Apr 14, 2011 at 14:21

Insist on a weekly report. This person should learn to summarize rather than just cc: emails.

If you aren't going that way, either talk to him after getting emails that report problems or if his emails aren't reporting it, explain that to him.

  • Thanks Brian, the developer does delivers weekly reports. Those reports are worthless, since they don't update the status. I even went a step further to give him an example of a good status report.
    – Geo
    Commented Feb 24, 2011 at 17:15

I had similar experiences in the past. A specific example was a developer that was constantly late with his deliveries. One of the differences from your case is that I directly managed that developer.

Anyway, I have seen an improvement in my ability to get a sense of when his tasks were behind schedule when we moved to using SCRUM. In planning he was expected to create tasks that were up to 12 hours of effort. On the daily stand-up meetings he needed to talk about tasks he completed and his plan going forward.

Moving to SCRUM did not transform him into a developer that is constantly delivering on schedule but at least the team and the project knew when he was lagging behind.


My take on this is first go for visibility. Start a coaching engagement with him. Recommend he map the things he's working on using something like a "Personal Kanban". All his tasks, due dates and whatever information is relevant. Ask him to start visualize his work there for a couple of days, and meet with you every couple of days to see what you can learn from the picture.

It will help you see some of the effects other mentioned here - bad multi-tasking, procrastination (Parkinson's 1st Law), tasks that are blocked/impeded and why. Start using elements like "Work in progress Limits" to help him focus/flow.

Break work into small tasks - ideally tasks that are less than a day. Each task should have a clear "Definition of Done" what will he have ready when done. Ideally each task should have value...

Use elements like colors that mark how far a task is from a due date (when unable to break into very small tasks, or when tracking a project comprised of several tasks) - for example if a task is due in a week (5 work days), once it starts a clock counts down from 5. when clock is 3-5 item is green when 2-3 yellow - warning! when 1 red - really need to finish! when 0 and below - black you are LATE! Expect most tasks to be finished while yellow... due to uncertainty in estimates...

Another technique is to stop having due dates for a while, and just tell him to do tasks as fast as he can while still delivering at the agreed quality and sustainable pace. Tell him to track his actual cycle time (how many days it takes to process) and create a "Control Chart" showing his various results. With that in hand, have a discussion on what can be the SLA/expected due date for various kinds of tasks.

Make sure he knows that there is a commitment - when the task can be done with 95% confidence. And beyond that the expectation that tasks will most of the time will be done BEFORE the committed date. (there's a bell curve of certainties).

There are all techniques that are relevant at a team level as well, and those familiar with Scrum and TOC will recognize them. They are aimed exactly at those problems.


If he's got only one manager, then the manager should be responsible for informing the resource what the prioritization is. If XYZ is more important that ABC or DEF, then the manager should be telling him that.


You can't change the person - and in most cases it's not easy to 'move the person on'...(aka giving them the boot) - but if you can boot the person out after repeated issues, the impact of one poor performing individual on an entire team is often large.

To reduce risk, only assign the lowest priority work to them, assume they will fail to deliver on time and assume you will not know until after it's due.

Keep track of all of their deliveries with original est. delivery date and current and final- and post it on their cubicle wall. Mark in RED all late deliveries. Ask them to send you a email daily with each task's delivery date - updated daily. This is basically raising the pain of late delivery...aka negative reinforcement.

  • Agree, the problem is more "peopleware" than task management, I think the person can be "Burned-Down" or is not motivated. Commented Feb 25, 2011 at 17:50
  • -1 giving the person negative tasks will affect whatever morale and team spirit they have. Don't try to break them; work with them, not against them.
    – ashes999
    Commented Apr 14, 2011 at 14:20

This may be a bit broad of an answer as the problem description is 3rd hand. You know via another manager that has told you. There can be all sorts of team dynamics and politics that are not being surfaced via your question.

Communication seems to be a real problem. Hiding behind emails is not a way to build a highly functioning team. There sounds like things are been chucked into the "too hard bucket" that are not being discussed.

What is the progress like for the rest of the team? Are there any team feelings of being over/underwhelmed? It is best to ask this anonymously as personal dynamics and the feeling of letting the team down can affect how people react. "Everything is great! Full speed ahead off the edge of that cliff."

What sort of development cycle are you working in that the person keeps going through deadlines?

Is there also a problem with the quality of the work the person is doing? Is the team also building to a high measurable quality?

Is the person a key man risk? Are they responsible for a certain part of the system that no one else can do? Is this person having to juggle work to help others complete their tasks as they are required on so many features?

Is the person working on multiple projects at a time or just one? Is he/she working on more than one feature at a time? Are there external pressures/people that change the priorities of feature deliveries?

Multitasking is a great way to kill productivity and increase errors. It may be that his WIP (work in progress) is too high. Is the delivery split into enough slices to allow displayable progress?

Do not use percentages of progress. The feature is either done or too large to be done in a short iteration and needs to be split into separate smaller deliverable features. You do not want to get into the case of "It is 98% done all we have to do is test it now..."

Are these real commitments to external or internal customers for delivery of features or is the delivery part of some sort of Gant burn down chart? At the end of each deadline is the functionality showcased to the clients?

If we are only talking about estimations that's what they are estimations. A great way to kill team moral and encourage the wrong behaviour is to beat them to death with artificial deadlines. Once missed and the team scolded then a pattern is set. You may be dropping quality for the time constraint.


First of all, it's a "person", not a "resource". A computer is a "resource".

I know what you mean and I know that term is used throughout the industry, but it's annoying to people on dev teams and many developers lose a little respect for people when they use that term to refer to people. We aren't just a cost item that is listed in a spreadsheet.


I recently had the same problem. What I found was the problem did not lie with the one team member. Everyone played a role.

The higher ups didn't clearly communicate roles and responsibilities. It was not made clear who was in charge of what. This lack of communication caused rifts that made both myself as the project manager and the team mate, who is creative director, feel as if the other was stepping into their territory or not respecting their say.

The sales manager wasn't watching his team and their capabilities. He was promising clients timelines and start dates to projects that overwhelmed the team and created a bottleneck. Work flow was completely disrupted and a huge weight was placed on the team member.

The team mate didn't communicate. He felt that took up precious time and was desperately trying to push through. If he had, he may have found he had help and could have gotten the projects out on time.

I took too long to address the problem. I feared I would upset my teammate and they would become less responsive. Although I had touched on the problem, I wasn't firm.

Finally, I took the time to call out these problems. I was firm. I didn't call out anyone by name and I addressed my own faults. What I found was everyone had some sort of issue that was bothering them, my calling out all of it made everyone feel validated. We became more open and honest at our work. Deadlines aren't always hit, but I know about it ahead of time.


First thing I would suggest is that you make sure all dealings with him/her are professional, friendly and cheerful. Put yourself into this mind-set before all interactions. And make it sincere (!?). (Yes I know this is completely insincere!)

Be clear with them why it is important to the rest of the project team to have agreed, achievable targets (so that other people's work can be planned with some confidence - i.e. it is a courtesy to other people) and why striving to achieve those targets is also important. (Avoids other people having to go out of their way, or do extra work, or do re-work, or re-plan at short notice, or... or... or...). The idea being that there is a better understanding of the context for closely monitoring his/her success in setting and meeting those targets.

If the person understands their interconnectedness with others - and that those inter-dependencies have real effects on others, hopefully they will realise that hitting deadlines is something that team members do for OTHER PEOPLE. (Not for the faceless project/organisation).

The person will either get on board with the team - or they will effectively be disengaging themselves from the team. If the latter - they are likely to depart the team of their own accord eventually.

But I'll recommend again - that the positive, cheerful approach is always the best line. Especially if you are a contractor. I can't tell you how many times I have been polite and cheery to people that I think are lazy or annoyingly disengaged - and some time later (weeks/months/years) had to ask them a favour, or needed their help when in a pinch. It is an investment with a massive ROI.


There is one aspect of this question that I haven't found in any answer. Person is saying that delay is due to other tasks. As already stated in other answer there has to be clear expectations, however it could be a bit risky in some areas. For example person is being asked for a help, because of some specific knowledge that nobody else has in the team. If he/she would start reject such request because it's simply something 'forbidden' to him/her it could harm whole team.

Therefore I would go with short period of micro-management, when person should always ask manager for approval to work on anything other than regular planned user story or task. This will help manager better understand what are other tasks and also guide person what is important for overall team success and what could be ignored or politely rejected. Again this period should be quite short not to become personal, annoying and simply contra-productive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.