TL;DR
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:
I say they are small requests because they aren't critical issues but they help keep me informed and keep the team running smoothly[.]
I feel like he unilaterally decides which of my emails are worth responding to.
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.
- 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.
- 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.
- 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:
- Chasing information which is probably more important to you than you are effectively communicating to anyone else.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!
