What I thought was enough
Three years ago, I stepped into a remote PM role managing a distributed team across multiple time zones. I had the tools. I reviewed the roadmap. I scheduled my alignment calls. I genuinely believed I was prepared.
Within the first few weeks, I made a planning decision that unintentionally reopened a debate the team had already settled months earlier. No document mentioned it. No ticket explained it. The reasoning lived only in conversations I wasn’t part of.
*That was the moment I understood: access is not onboarding. Context is.*
According to Buffer’s State of Remote Work report, 77% of remote workers say unclear expectations from the start are the leading cause of project friction in distributed teams. I was living proof of that number.
What we overlook
The obvious stuff only tells half the story
When you join a new team, you naturally gravitate toward the basics. Tools, documents, shared drives, backlogs. These are useful. They show you how things are supposed to work. They do not show you how things actually play out in practice.
That gap is where new remote PMs run into trouble. The Project Management Institute found that 11.4% of every dollar invested in a project is wasted due to poor performance, with the root cause traced back most often to a lack of context and communication, not technical failure. And organizations that actively apply lessons from past projects are twice as likely to meet their goals. Despite this, most onboarding processes hand you a Confluence link and call it done.
Documents don’t capture unwritten rules. Backlogs don’t capture the lessons from previous missteps. Without that knowledge, you end up repeating old errors, the same dead ends, the same stakeholder friction that slowed everything down before.
The three questions
What actually closes the gap
Over time, I’ve landed on three questions that reliably surface the context no document captures. Ask these early, and the fog lifts fast.
1. What has already been tried before, and why didn’t it work?
Early in one of my roles, I proposed shifting the team toward a more self-managed approach. The team was capable, and I believed increased ownership would improve delivery and reduce dependency on constant supervision.
Management pushed back immediately. Not because they doubted the team, but because they had already tried it. That transition had led to missed deadlines, unclear accountability, and a forced return to hands-on management. What I saw as a step forward, they experienced as a risk they had already paid for.
McKinsey research shows that 70% of organizational change initiatives fail, and most repeat the same patterns precisely because the reasoning behind past failures was never documented or passed on. That is what I walked into.
Every organization carries memory. Decisions are often shaped as much by past failures as by current needs. Asking this question helps you understand which ideas failed, why they failed, and whether the conditions that caused those failures still exist.
2. Where do people hesitate to speak openly, and why?
In one of my interviews, I noticed something. Whenever the CEO joined the conversation, the tone shifted. Responses got shorter. Open disagreement disappeared. It felt at first like a lack of confidence or collaboration.
Over time, it became clear it was neither. The hesitation was learned, shaped by the organization’s history and culture in ways that predated me by years.
Gallup found that only 3 in 10 employees strongly agree they can voice concerns at work without fear of repercussion. In remote teams, that number tends to drop further without deliberate culture-building. And Salesforce research found that employees who feel their voice is heard are 4.6 times more likely to perform at their best. The silence you encounter during onboarding is not neutral. It is data.
In remote environments, signals like these are especially hard to detect. There is no body language to read, no informal interactions to observe. Asking this question helps you map where psychological safety is limited and where trust needs to be built intentionally, rather than mistaking silence for agreement.
3. Where have past projects broken down, delivery, communication, or expectation alignment?
On one project I inherited, everything appeared to be on track internally. Tasks were being completed. Delivery followed the defined scope. And then the final delivery happened, and the client was frustrated.
Their expectations had evolved, and the product didn’t fully reflect where they had landed. From the team’s perspective, they had delivered exactly what was agreed. From the client’s perspective, they had been left out of the process entirely.
PMI data shows that 57% of project failures are attributed to communication breakdowns rather than technical errors or missed deadlines. The execution was fine. The visibility was not.
If I had understood earlier that previous projects lacked continuous client engagement, I would have prioritized regular demos and alignment from day one. This question helps you identify where breakdowns historically happen so you can reinforce those areas before they become problems again.
The one move that changes everything
If you are onboarding as a remote PM, make this your first priority. Ask: “Can you walk me through the last few projects, especially what went wrong and why?” It might feel uncomfortable. It is also the question that actually matters. It saves you from trial and error and lets you contribute meaningfully sooner.
FAQs
Why is historical context more important for remote PMs?
In remote work, you miss the in-person cues that naturally surface context. Knowing past failures, friction points, and team dynamics helps you avoid repeating mistakes and build trust faster without the benefit of proximity.
What are the most common onboarding mistakes for remote PMs?
Focusing only on tools, documentation, and backlogs while ignoring the history behind decisions. That leaves you relying on incomplete information and walking into avoidable situations.
How can leaders improve onboarding for incoming remote PMs?
Share historical context early, including project failures, stakeholder dynamics, and the unwritten rules that shape how decisions actually get made. It saves time and reduces frustration on both sides.
