Remote project managers are no longer unusual. Most organisations have hired one, worked with one, or are actively considering it. What has not kept pace with the prevalence is the hiring practice. Companies that would spend three rounds of interviews pressure-testing an on-site PM’s stakeholder management or delivery methodology will hire a remote PM based on a clean LinkedIn profile and a decent first call.
That is how you end up with someone invisible, reactive, and impossible to manage — and conclude that remote project management does not work, when the actual problem was the hire.
This guide is for people responsible for bringing on a remote PM — whether as a direct employee, a contractor, or a fractional engagement. It covers what to look for, how to assess it, what the red flags are, and how to set the engagement up so it actually succeeds.
What is Different About Hiring a Remote PM
The core job is the same. A remote PM still needs to plan, sequence, communicate, manage risk, and deliver. The difference is the operating environment — and some skills that are merely useful in an office become load-bearing when there is no physical presence.
Written communication is the most important. In an office, a PM fills information gaps by being visible — stopping by someone’s desk, overhearing a conversation, getting pulled into a hallway discussion. Remove the office and none of that happens. Everything that would have been communicated informally now needs to be written: decisions, status, blockers, context, rationale. A PM who is a strong verbal communicator but a weak writer will fail remotely. The communication load shifts to email, Slack, Notion comments, Loom updates, and meeting follow-ups — and if those are vague, late, or missing, the whole project suffers.
Async discipline is closely related. Remote teams run across time zones, which means real-time communication is rationed. A PM who defaults to calling a meeting whenever something needs to be resolved will burn the team’s goodwill quickly. Strong remote PMs know how to push things forward asynchronously — a well-structured update, a Loom walkthrough, a decision doc with a response deadline — and use synchronous time for the things that genuinely require it.
Proactive visibility is the one that catches people out most. In an office, presence is visible by default. Remotely, you have to create it. A good remote PM keeps stakeholders informed without waiting to be asked — they send the weekly status before the client emails to ask where things stand. The PM who goes quiet until the next scheduled meeting is a risk even if the work is progressing well, because confidence in progress is built on communication, not just delivery.
Documented decision-making is the final one. Without documentation, remote projects accumulate invisible debt — decisions made on calls that nobody logged, scope changes agreed in Slack threads nobody can find, risks flagged verbally and then forgotten. A remote PM who does not document in real time is, over time, a project manager with no paper trail and an organisation with no institutional memory.
What to Look For in a Remote PM
Communication style
Ask for writing samples from their work history. Status reports, risk registers, project summaries — actual artefacts, not a portfolio presentation deck. What you are looking for is clarity, structure, and appropriate brevity. Long-winded, jargon-heavy writing is as much a warning sign as sparse writing that leaves too much to interpretation.
Also watch how they communicate during the hiring process itself. Are their emails clear? Do they confirm details in writing after a call? Do they follow up promptly? A good remote PM treats the hiring process as a professional communication exercise — because it is.
Documentation habits
Ask directly: how do you document a project? What does your status reporting look like? Can you show me a decision log or meeting notes from a recent project? If they cannot answer this concretely — if the answer is “I keep it in my head” or “we used Teams but I did not really own the documentation” — that is a signal.
The documentation does not need to be elaborate. It needs to exist, be findable, and be useful to someone who was not in the room.
Time-zone management
If your team is distributed, ask how they have handled time-zone differences in previous engagements. What you want to hear is a concrete answer: how they structured their working hours, how they communicated their availability, how they managed hand-offs across time zones, how they handled urgent issues that arose outside their hours.
Vague answers (“I am flexible” or “I just work whenever I need to”) are not adequate. Time-zone management is a system, not an attitude.
Tool fluency
Remote project management runs on tools. The list varies by organisation, but expect a remote PM to be competent in at least: a project management platform (Jira, Asana, or similar), a communication platform (Slack or Teams), a documentation platform (Notion, Confluence), video and async video (Zoom, Loom), and collaboration tools (Miro, Figma, or Google Workspace).
Fluency does not mean they use every tool you use. It means they can learn new tools quickly, they understand why tools exist and how they support delivery, and they do not resist using them.
Track record of delivering remotely
This sounds obvious but it is under-screened. Ask specifically: which of your projects were delivered fully remotely? What was the team size and geographic distribution? What was the project outcome? Were there stakeholders in different countries?
Someone who has managed on-site projects and one remote pilot is different from someone who has delivered complex programmes across three countries over several years. Both might be excellent — but they are not the same hire.
From my end: I have been working remotely across Australia, New Zealand, the USA, and Mexico for years. The discipline I rely on most is written status — I send a concise update at the end of every week without waiting to be asked. Not a lengthy report. A clear paragraph: what moved, what is blocked, what needs a decision by when. It takes ten minutes to write and it prevents most of the “what is actually happening with this project” anxiety on the client side. It is also the thing most remote PMs skip.
How to Assess This in the Hiring Process
The hiring process itself is your first data set. Pay attention to the following:
Response speed and quality. Do they reply promptly? Are their emails clear and appropriately structured? Do they confirm call times in writing? A remote PM who is slow to respond, unclear in their writing, or disorganised in scheduling during the hiring process is showing you their working style — not their best behaviour.
The questions they ask. Strong remote PMs ask good questions early. They want to understand governance, decision rights, team structure, tools in use, and how success is defined. Candidates who ask no questions, or only ask about salary and start date, have not thought about how they would actually run the work.
Their answers to process questions. Ask open-ended questions about how they have handled specific situations: a stakeholder who went quiet, a scope change mid-delivery, a team member in a different time zone who was underperforming. What you are listening for is a clear, structured answer with a concrete example. The STAR format (Situation, Task, Action, Result) is fine — but the specificity matters more than the structure.
A structured task. If the role or contract is significant, consider sending a short written task — a project brief to summarise, a risk register to review, a status update to draft from a set of notes. This tests written communication and structured thinking in one step. A strong candidate will turn it around promptly, present it clearly, and likely ask a clarifying question before starting.
Red Flags Specific to Remote PMs
Over-reliance on synchronous communication. If a candidate’s answer to almost every scenario is “I would set up a meeting,” that is a problem in a remote environment. Meetings have their place. But a PM who cannot push anything forward without a call will create unsustainable meeting overhead and fail in time-zone-distributed teams.
No documented work output. If they cannot produce a single artefact from their recent project history — a status report, a risk log, a decision document, a project plan — that is a significant warning sign. Either they do not document their work, or their documentation is so poor they would rather not show it.
Vague about their own process. “I am adaptable” and “I just do what the project needs” are not process descriptions. Strong PMs — remote or otherwise — can articulate how they work. They have a clear view of how they start a project, how they maintain momentum, how they manage risk, and how they close. If they cannot describe their process in concrete terms, the process probably does not exist.
Misalignment on tools. Resistance to specific tools is sometimes legitimate — there are bad tools. But a blanket resistance to documentation platforms, project management software, or async video is a red flag in a remote context. These tools are not optional overhead; they are the infrastructure the work runs on.
Communication that goes dark. If there are gaps in communication during the hiring process — emails that go unanswered for days, interview follow-ups that never arrive — take that seriously. It is not a reflection of how busy they are. It is a reflection of how they communicate.
How to Onboard a Remote PM Well
A remote PM who cannot access your systems, does not know who to contact about what, and has no clear expectations for their first few weeks will spend that time managing their own confusion rather than your projects. Bad onboarding is recoverable on-site. Remotely, it sets a tone that is hard to reverse.
Access on day one. Before they start: project management platform, communication channels (Slack workspaces, Teams channels), document libraries, calendar access, and any other systems they need to do the job. Waiting until day three to provision access is a concrete statement about how prepared you are for this engagement.
Introductions with context. An email blast introducing the new PM is not enough. Make personal introductions to key stakeholders and team members — ideally a short call or Loom message that gives the PM some context on each person’s role, their preferences, and what a good working relationship with them looks like. The relationship-building that happens organically in an office has to be deliberately constructed remotely.
Expectations in writing. What does success look like at 30, 60, and 90 days? What are the reporting expectations — who gets what update, how often, in what format? What are the escalation paths? Write these down and share them before the first day. A PM who knows what good looks like from the start can get there faster than one who has to reverse-engineer it.
A clear operating cadence. Establish the recurring meeting rhythm early: what is weekly, what is fortnightly, what is ad hoc. Remote teams without a clear cadence tend to have either too many meetings (everyone overcommunicating out of anxiety) or too few (nobody knowing what is happening). Agree on the structure in the first week.
Tools and Infrastructure You Need Before They Start
Remote project management does not work without the right infrastructure. If you are planning to bring on a remote PM, make sure the following are in place before day one:
- Project management platform — Jira, Asana, Linear, or equivalent. Not a spreadsheet. The PM needs a system they can own and maintain.
- Communication platform — Slack or Microsoft Teams, configured with relevant channels. Not email threads.
- Document and knowledge management — Notion, Confluence, SharePoint, or equivalent. A shared place for project documentation, decisions, and status.
- Video conferencing — Zoom or Google Meet, with calendar integration so the PM can schedule meetings without friction.
- Async video — Loom or equivalent. Particularly valuable for walking through complex information without requiring a live call.
- Shared calendar access — so the PM can see team members’ availability across time zones.
- Defined access permissions — know in advance what the PM can and cannot access, and why. Ambiguous access wastes time and creates security risk.
If your organisation does not have most of this in place, a remote PM will spend a significant portion of their time working around the gaps rather than managing the project. Fix the infrastructure before the hire, not after.
A Note from Aaron
I run remotely across Australia, New Zealand, the USA, and Mexico. My clients are typically mid-to-large organisations running complex projects — post-merger integrations, digital transformations, major technology programmes — and none of them are in the same office as me.
What I have learned over years of remote delivery is that the clients who get the most out of a remote engagement are the ones who treat the working relationship as a designed system, not an improvised arrangement. They have the tools. They share context. They communicate expectations clearly. And they trust the PM to operate without being managed.
If you are hiring a remote PM and you are not sure whether your organisation is set up to support one well, that is a worthwhile question to ask before you sign the contract. A good remote PM will ask it themselves.
If you are looking for a senior contract PM with remote delivery experience, get in touch →.
Aaron Darke is a Senior Project & Program Manager with 25+ years’ experience running complex programs across Australia, New Zealand, the USA, and Mexico. He is available for contract engagements in all four markets. Learn more or get in touch.
Frequently asked
How do I hire a remote project manager?
To hire a remote project manager effectively, assess five areas: written communication quality (ask for work samples such as status reports or decision logs), documentation habits (can they describe and demonstrate their documentation practice), time-zone management (how have they handled distributed teams before), tool fluency (Slack, Jira or Asana, Notion, Loom, Zoom), and their track record of delivering projects fully remotely. The hiring process itself is a sample — a strong remote PM will communicate clearly, promptly, and in writing throughout the interview process.
What skills should a remote project manager have?
The four skills that matter most for a remote project manager — beyond the core PM competencies — are: strong written communication (because informal hallway conversations do not happen remotely), async discipline (the ability to push work forward without defaulting to meetings), proactive visibility (keeping stakeholders informed without waiting to be asked), and documented decision-making (maintaining a real-time paper trail of decisions, scope changes, and risk). These skills are load-bearing remotely in a way they are merely useful on-site.
How do you manage a remote project manager?
Managing a remote PM well requires three things: clear expectations in writing (success criteria at 30, 60, 90 days; reporting cadence; escalation paths), a defined operating rhythm (agreed recurring meetings and async update formats), and the right infrastructure in place before they start (project management platform, communication tools, document storage, and calendar access). The most common management failure is treating a remote engagement as identical to an on-site one and assuming the PM will figure out the gaps. Write the expectations down and share them before day one.
What are the red flags when hiring a remote project manager?
Key red flags when hiring a remote project manager include: over-reliance on synchronous communication (answering every scenario with 'I would set up a meeting'), no documented work output to show from previous projects, vague descriptions of their own process ('I just adapt to what the project needs'), resistance to documentation or project management tools, and communication that goes dark during the hiring process itself. These are not minor gaps — they are predictors of how the person will perform once hired.