I am the PM for a smallish-medium software development team at a large IT services company. One of the developers is knowledgeable and generally a nice guy, but has a tendency to ignore "small" requests I send by email. I say they are small requests because they aren't critical issues but they help keep me informed and keep the team running smoothly, like when I ask him to help another team member get a particular software version or provide information on our branching strategy. I have started keeping track of these small, ignored requests and they average out to about one per week.

I know sometimes he just spaces out, but I don't know if all of these are innocent "Sorry, I just missed your email" incidents because sometimes he won't respond even after I send a follow-up email, and I need to physically go to his desk and ask. I feel like he unilaterally decides which of my emails are worth responding to. On other occasions, he has also made decisions that were either not in his scope or should have at least been consulted with me.

How should I handle this? This website suggests confronting the team member, but as a PM I have no formal authority, he has already shown a (willful or not) lack of regard for what I ask him to do, and it feels like something I should be able to handle myself without escalating to our manager.

3 Answers 3



You have one or more process problems involving communication and prioritization. You need additional information in order to inspect-and-adapt your team's process in a collaborative and sustainable way.

Your Problems, Restated

You make the following points in your original post:

  1. I say they are small requests because they aren't critical issues but they help keep me informed and keep the team running smoothly[.]

  2. I feel like he unilaterally decides which of my emails are worth responding to.

  3. I have started keeping track of these small, ignored requests and they average out to about one per week.

These are what I consider the key elements of your situation. I will examine each of them in detail below.

Analysis of the Problems Described

Assessing Information You've Presented

You're asking a couple of things that are tightly-coupled. I have tried to tease them apart for analysis, but in the end they remain closely linked. However, by breaking them down, the specifics become addressable.

  1. You yourself make the statement that these aren't mission-critical issues that are being dropped on the floor. If you don't think the issues are important, why should the developer? If they are important, then you need to find a way to effectively communicate the level of real importance.
  2. You make a "feeling statement" about the ignored emails. Your feelings are largely irrelevant to pragmatic project management. Instead, you need to ask the developer why these requests aren't priorities for him so that you're acting on information from the developer rather than feelings which are subjective and unprovable.
  3. An average of one small request (rather than a key deliverable) being missed or ignored per week is not a high volume. You are attaching a rather high level of importance to something which seems, from an outside perspective, to be a statistically small level of communications failures.

On the whole, it appears that you are communicating low-priority information and expecting a high-priority response or acknowledgment. Your expectations aren't being met, and you are having a reaction to that. However, you have not clearly identified the process problem involved yet.

Extracting the Core Issues

The central issues seem to be that you are:

  1. Chasing information which is probably more important to you than you are effectively communicating to anyone else.
  2. Concerned about a communications issue, but lack information about the developer's perspective or context.

In short, you are operating in an information vacuum. That is never constructive. There is clearly a disconnect in your communications process, as well as in the operating assumptions between you and the developer. You both need more (and better) information in order to resolve the process problems here.

Possible Solutions

There are any number of ways to approach this issue, but there are some key elements you definitely need to take on board. Specifically, consider adopting one or more of the following steps.

  1. If the "small requests" aren't that important, or if they are being addressed most of the time, then you can simply treat it as a very minor problem when you have larger dragons to slay.
  2. If the "small requests" are actually important, which would contradict how you've presented them here, then you need to ensure they are tracked by your project, visible to the team, and their priority clearly communicated to everyone involved.
  3. If you have a communications issue of any kind, you need to open a discussion about it. This doesn't have to be an adversarial confrontation, but you do need to open a dialog so that neither you or the developer is operating in an information vacuum.
  4. You need to understand the developer's time constraints and priorities to see how they align with the project. Whether or not he is ignoring your messages, he is likely making prioritization decisions based on his available bandwidth and his understanding of his immediate priorities.
  5. If email isn't working for you, stop relying on email as your communications mechanism. Sometimes face-to-face is the best way to communicate about something, especially if it's too important to get lost in the information stream.
  6. Acknowledge that lower-priority items are lower priority. Not everything can be Job #1 at the same time, so lower priority tasks must give way to more urgent matters.
  7. Recognize that even "small requests" can be time consuming. They create task-switching overhead, and science tells us that it often takes almost half an hour to regain flow in addition to the time taken up by the task itself.
  8. Hammer out a process everyone can agree on. If the process and the priorities are not explicit, then you are operating in a gray (and largely unmanageable) area.

At the end of the day, unless this developer hates you personally and with passion (which is not in evidence as presented here), then it is a process failure. As the project manager, identifying process problems and defining process controls is your job. Luckily, defining process controls and communication strategies isn't something you have to do on your own; you can collaborate with your team to identify a more effective process!


A very thorough analysis is already given in CodeGnome's answer. Perhaps some bottom lines would be helpfull:

  • E-mail is very a bad tool for most issue tracking. Use an issue tracker, backlog with post-it's, shared Excel sheet. Anything will beat e-mail. Make sure a central location has the issues visible to everyone, indicating priority from business perspective.
  • Low priority issues should be placed in the issue tracker and discussed with preferably the whole team, at a designated event. During this event, you can also indicate scope and priority.
  • If the developer is determining scope, and you don't want that to happen, make sure scope is determined another way. Either you set it, discuss it with the team then set it, or a stakeholder perhaps?

The case you present gives an overall feeling that transparency, clarity and self-inspection could be improved. Have a dialogue with the team, determine expectations between all parties involved in the project. If something's not going smoothly, have a group discussion on how to make it better.


As a PM I understand it is for you to resolve this situation. It is good idea to confront the Team member, but before you do so also some bit of analysis is required interms of the reporting hierarchy if there is one. If it is matrix organization where the reporting of the person is with someone else then it will be good idea to include that person as well.

Having a streamlined process of tracking the requirement with priority and expected closure dates over a simple tracker or dashboard will definitely help as this will bring in more clarity for the individual.

  • Thanks, Amit. The developer and I both report to the same manager, according to the org chart. And the thing is, these requests are not requirements per se; they are not user stories or defects. They are requests: do this, research this, provide a status on that. Not the kind of thing that would usually be tracked on a dashboard. I don't think there should be any administrative overhead for these types of tasks.
    – Pedro
    Commented Feb 10, 2016 at 13:26
  • If developer and you both report to same manager then it will be very difficult unless there is formal power being delegated to you. Request your manager to delegate or intervene because if you both report to the same person few times team considers why should I do the work given by someone reporting to the same manager as me. It will make be a good idea to discuss this with the manager and seek help.
    – Amit sinha
    Commented Feb 13, 2016 at 2:20

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.