A new project manager on my contract project refuses to accept an invitation to our GitHub repository and wants to handle everything through email. Since I cannot assign her issues, I have to act as a go-between and manually transfer information between email and the issue tracker. This also makes it harder to track items blocked on her, such as requests for client information, and leads to repeated "where are we?" status questions.
The rest of the small team already uses GitHub Issues, and there is no other project-management system in place. I cannot escalate the matter or delay the project, and I do not want to create friction with someone who is likely to stay on the team. How can I explain the value of issue tracking in a short, polite way that focuses on making her work easier?
4 Answers
It may not be worth making this a battle. A project manager does not necessarily need to work directly inside the developer’s tool if she can provide clear requirements and receive useful updates another way. Offer a simple routine—perhaps a weekly summary or a link to a filtered board—and see whether that meets her needs. If not, keep your own process organized and let the limitations of an email-only workflow become visible through the project’s progress reports.
If she still refuses, use the tracker for your own records. Turn each relevant email into an issue comment, record decisions and blockers, and keep the status current. You can continue responding to her by email while maintaining a reliable timeline of what was requested, what you completed, and what is waiting on someone else. That protects the project and makes handover or payment discussions much easier.
Ask whether she already uses another planning tool. She may be separating project-management tasks from technical issues, or she may simply be unfamiliar with GitHub. An email such as “We use GitHub Issues to track development work—would you be able to accept the invitation, or is there another tool you prefer?” gives her an easy way to explain the objection without making it a confrontation.
Keep the pitch focused on saving her time rather than telling her that her current process is wrong. You could say: “The tracker gives us one place to see what needs doing, who owns it, and what is finished. It should reduce email back-and-forth and make project updates easier.” You can also offer to give her a quick walkthrough of how the development team uses it, rather than presenting it as formal training.
That wording is exactly the tone I was looking for—short, practical, and not confrontational.
This also helps with requests that are forgotten later. Every email can become part of the issue’s history without requiring her to learn a new system.