VP Engineering, EM, and PM — The Right Collaboration

These three roles exist in almost every engineering team that grows past the early startup phase, but how they work together is often never explicitly defined. As a result, conflicts appear not because the people are bad, but because there’s no agreement about who decides what, and when one role may enter another role’s territory. This article discusses the healthy collaboration structure between the VP Engineering, Engineering Manager (EM), and Product Manager (PM) — from role definitions, how a project should flow from initiation to delivery, the most damaging dysfunctions, to how to diagnose that something isn’t running right before it’s too late.

Three Roles, Three Orientations

Before discussing how the three collaborate, it’s important to understand that each role has a different orientation — and this difference isn’t a weakness, but a deliberate design.

The VP Engineering ensures the team has the best conditions to succeed. The EM ensures the team delivers healthily and grows as engineers. The PM ensures the team builds the right thing at the right time.

The three can fail alone, but can only succeed together.

Position picture in the org:

VP Engineering
├── EM
│   └── Engineers
└── PM  ← in setups where the PM sits in the engineering org

The setup where the PM sits under the VP Engineering (rather than under a separate VP Product) is a very common pattern in companies that don’t yet have a separate product division. This article uses this setup as its main context.

The Often Misunderstood VP Engineering Role

The VP Engineering isn’t a “senior engineer with a higher title.” This is a role fundamentally different from engineering — and precisely because of this difference, many newly promoted VP Engineers struggle with the transition.

From Technical to Systemic

A great engineer solves technical problems. A VP Engineering solves systemic problems — why the team keeps facing the same problems, why velocity drops every quarter, why the best engineers leave the team within the first 18 months.

ANTI-PATTERN: VP Engineering as a technical problem-solver

The VP Engineering receives a report of a serious production bug.
Reaction: directly open the code, analyze the root cause, fix it themselves.

CORRECT: VP Engineering as a systemic problem-solver

The VP Engineering receives the same report.
Reaction: ask the EM — "is this the first time or is there a pattern?",
         ask the PM — "is there timeline pressure causing
         testing to be cut?", then decide a systemic intervention:
         add a coverage threshold in CI, or review sprint planning.

The difference isn’t in the outcome (the bug still gets fixed), but in what changes afterward. A VP Engineering working directly creates no systemic improvement — only incidental fixes.

As a Buffer Between Business and Team

One of the VP Engineering’s most critical functions is absorbing pressure from above before it reaches the team. When the CEO or business stakeholders ask for something unrealistic, the VP Engineering is the first layer that must be able to debate, negotiate scope, or delay with an acceptable reason.

ANTI-PATTERN: pressure passed through raw

CEO: "We need feature X done next week."
VP Engineering to EM: "The CEO wants X done next week."
EM to team: "There's an urgent request from above..."

Result: the team panics, quality drops, people work overtime without context.

CORRECT: VP Engineering as a buffer

CEO: "We need feature X done next week."
VP Engineering: "Okay, I need to check with the team first. What's
                 most critical about X — can we identify its MVP first?"

[VP Engineering discusses with the EM and PM, then returns to the CEO]

VP Engineering: "We can deliver the core of X in 2 weeks with
                 reduced scope on this part. If you need full X,
                 realistically it's 4 weeks."

Without this buffer, the team lives in a permanent reactive state — never having room to think, plan, or build properly.

Delegating, Not Doing

A good VP Engineering has high technical curiosity, but knows when to hold back. When an EM is leading a technical discussion with the team, a VP Engineering who suddenly enters and dominates the conversation — even with good intentions — weakens the EM’s authority in front of their team.

ANTI-PATTERN: VP Engineering micromanaging the EM

Sprint planning is running. The VP Engineering enters the meeting,
comments on each engineer's estimate one by one, changes task
priorities directly, and concludes the meeting.

Result: the EM looks like they have no authority. Engineers are confused
        about who to listen to. The EM starts losing ownership of their own team.

CORRECT: VP Engineering gives the EM space

The VP Engineering attends sprint planning only when invited,
or to provide strategic context at the start ("Q3 priority is X because Y"),
then leaves.

If there's a concern, the VP Engineering raises it with the EM
privately — not in front of the team.

The EM Role That’s More Than Just a “Manager”

The EM is often described as “the person who takes care of people” — this isn’t wrong, but it’s too narrow. The EM is the convergence point between the human side (engineers) and the execution side (delivery). Without a strong EM, the gap between “what the PM promised” and “what the team can deliver” will never be well managed.

Guardian of Team Capacity and Rhythm

The EM knows exactly who in their team is overloaded, who is learning a new technology, who is dealing with a personal problem affecting performance. This knowledge can’t be obtained from a sprint board or daily standups alone — it’s the result of consistent relationship investment.

That’s why, when the PM comes with a new request, the EM is the only person who can give a credible estimate — not based on a theoretical “how long it should take”, but based on “with the current team and conditions, realistically how long.”

Gatekeeper of Technical Quality

The EM is responsible for technical standards within their team — not just delivery. Code review culture, test coverage, technical debt management, internal documentation — all of these fall under the EM’s attention. The PM can’t and shouldn’t enter this territory.

ANTI-PATTERN: PM pressuring the EM to skip quality for speed

PM: "This feature must be done this Sprint. Testing can come later, right?"

CORRECT: EM maintains standards while still negotiating scope

EM: "If we skip testing now, we'll spend 2x that time
     fixing bugs next Sprint. I can suggest
     we cut feature Z from this Sprint's scope so testing
     stays for the most critical features."

Proper Escalation to the VP Engineering

The EM must know well when to handle something themselves and when to bring it to the VP Engineering. Escalating too often makes the VP Engineering unable to focus on strategic matters. Escalating too rarely lets problems pile up without anyone knowing.

Escalation to the VP Engineering is needed when:
  ✓ A decision impacts cross-team architecture
  ✓ There's a conflict with the PM that can't be resolved between the two
  ✓ There's a resource or hiring need beyond the EM's authority
  ✓ There's an engineer performance issue past the early PIP stage
  ✓ There's a scope change threatening commitments to stakeholders

Handle yourself without escalation when:
  ✗ A production bug that has an owner
  ✗ Small conflicts between engineers
  ✗ Task priority changes within one sprint
  ✗ Deliverable delays still within a reasonable margin

The PM Role in the Engineering Org

When the PM sits under the VP Engineering (rather than a separate VP Product), the dynamic differs from the classic two-division setup. The PM isn’t from an independent “product side” — they’re part of the engineering org, but with responsibilities inherently facing user and business needs.

The PM Brings Problems, Not Solutions

This is the most often violated and most damaging principle. When a PM comes to the team with a finished solution (“we need to use WebSocket”), the engineering team loses the chance to offer a solution that might be technically better and more resource-efficient.

ANTI-PATTERN: PM comes with a solution

PM to EM: "We need a WebSocket implementation for real-time notifications.
           I've researched this and it's the most appropriate."

Problem: the PM closes the technical discussion space. The EM doesn't know
         whether this was considered vs polling, SSE,
         or a simpler solution for the current scale.

CORRECT: PM comes with a problem

PM to EM: "Users complain they don't know when there's relevant new
           activity. Our data shows 40% of users don't return
           after the first day. We need a notification solution
           that can reduce this number."

Result: the EM and team can propose solutions considering
        technical constraints the PM might not know.

Acceptance Criteria Are the PM’s Responsibility

The PM defines what “done” means — functionally, not technically. Good acceptance criteria let engineers and the EM work without having to keep asking the PM about every small decision.

Bad acceptance criteria are the most common source of rework and delivery delays.

Bad acceptance criteria:
  ✗ "The notification feature is working well"
  ✗ "Users can see notifications"

Good acceptance criteria:
  ✓ Users receive a notification within a maximum of 30 seconds after an event occurs
  ✓ Notifications appear in the in-app notification center
  ✓ Users can mark notifications as read
  ✓ Read notifications no longer appear in the unread count
  ✓ The system doesn't crash when there are more than 100 unread notifications

The PM Doesn’t Bypass the EM

This is important enough to discuss separately. When the PM directly approaches engineers to ask for something — even something small — without going through the EM, the consequences aren’t small.

flowchart TD
    A[PM bypasses EM, goes straight to the Engineer] --> B[Engineer has two de facto 'bosses']
    A --> C[EM loses visibility of team capacity]
    A --> D[Informal commitments form without the EM's knowledge]
    B --> E[Engineer confused, picks the most vocal]
    C --> F[Sprint planning is inaccurate]
    D --> F
    F --> G[Velocity drops, delivery misses]
    G --> H[EM is blamed for problems created by the wrong communication pattern]
    E --> I[EM authority erodes in front of their own team]
    I --> J[EM loses ownership, performance declines]
    J --> H

The biggest problem isn’t delivery delays — but the erosion of EM authority happening slowly and only being felt when it’s already severe. And at that point, fixing it is far more expensive than preventing it from the start.

The Healthy Project Flow

With an understanding of each role, here’s how a project should flow from initiation to launch.

sequenceDiagram
    participant BIZ as Business / CEO
    participant VPE as VP Engineering
    participant PM as PM
    participant EM as EM
    participant ENG as Engineers

    BIZ->>VPE: Request / new project initiation
    VPE->>PM: Delegate: validate the problem and create a brief
    PM->>PM: User research, data analysis, competitive check
    PM->>VPE: Problem brief + solution hypothesis
    VPE->>EM: Involve the EM for initial feasibility
    EM->>VPE: Technical input: constraints, dependencies, risks
    VPE->>PM: Align scope and expectations
    PM->>EM: Requirements + acceptance criteria
    EM->>ENG: Technical planning, task breakdown
    ENG->>EM: Estimates and technical feedback
    EM->>PM: Negotiate scope vs capacity
    PM->>EM: Agreed final scope
    EM->>ENG: Sprint begins
    PM->>ENG: Answer requirement questions (via EM if structural)
    ENG->>EM: Progress updates, blockers
    EM->>VPE: Escalate if there are cross-boundary issues
    VPE->>BIZ: Update stakeholders, protect the team from interruptions
    EM->>PM: Delivery for review
    PM->>EM: Acceptance / feedback
    EM->>ENG: Internal retrospective
    VPE->>VPE: Analyze systemic patterns from retrospectives

Stage 1: Initiation (VP Engineering + PM)

A request comes to the VP Engineering — from the CEO, from data, or from the PM themselves identifying an opportunity. The VP Engineering doesn’t immediately involve the EM. First align with the PM: is the problem statement clear enough? What’s the success metric? Is this worth building now or can it be postponed?

Involving the EM too early, before a solid problem brief exists, only wastes the EM’s thinking capacity on something that might not get done.

Stage 2: Problem Brief (PM leads)

The PM explores the problem: user interviews, data analysis, competitor benchmarks. The produced output is a problem brief — a concise document answering: what’s the problem, who’s affected, how big is the impact, and what happens if we don’t solve it.

The PM brings this brief to the VP Engineering for confirmation. The VP Engineering decides: proceed to planning or not.

Stage 3: Triad Alignment (VP Engineering, EM, PM)

This is the only stage where all three must sit together. The EM is brought in to provide the technical perspective: is it feasible? Are there dependencies on other systems? What’s the rough estimate at the current team level?

Healthy negotiation happens here:

PM:  "Users need real-time notifications, both push and in-app."
EM:  "Real-time at 500k user scale is heavy — WebSocket or
      polling? This could take 6 weeks with our current team."
VPE: "6 weeks is too long for the Q3 window. What can we cut?"
PM:  "In-app only first, push notifications phase 2 — acceptable?"
EM:  "In-app with polling every 30 seconds? 2 weeks."
VPE: "Deal. Document the trade-offs, we'll revisit push in Q4."

The result of this stage: scope agreed, timeline locked, trade-offs documented. Nobody can unilaterally change this afterward without renewed discussion.

Stage 4: Planning (EM leads, PM accompanies)

The EM translates requirements into a technical plan: architecture, task breakdown, sprint breakdown. The PM ensures the priority order in this plan is consistent with the agreed business priorities. The PM also finalizes acceptance criteria for each deliverable.

The VP Engineering doesn’t need to be present at this stage unless there’s a decision requiring their authority.

Stage 5: Execution (EM leads)

The engineering team builds. The PM actively answers requirement questions that arise — because there’s always ambiguity only visible after coding begins. But structural questions (those affecting scope or capacity) must still go through the EM.

The EM protects the team from scope creep. If the PM wants to add something mid-sprint, the EM is the first responder: “We can, but we need to discuss the timeline impact and what gets dropped in exchange.”

The VP Engineering is present at this stage in a minimal but consistent capacity:

• 1-on-1s with the EM: coaching, removing blockers the EM can’t resolve alone
• Occasional skip-levels with engineers: not to micromanage, but as a pulse check
• Stakeholder management: protecting the team from sudden interruptions from above

Stage 6: Review and Retrospective

The PM does a product review — does the output match the acceptance criteria? The EM leads the team’s internal retrospective. The VP Engineering reads retrospective results and looks for systemic patterns needing intervention at the org level.

When There’s No VP Product

The setup without a VP Product — where the PM sits under the VP Engineering — creates a vacuum on the strategic “what and why” side. This vacuum doesn’t disappear; it just needs to be explicitly filled.

flowchart TD
    A{Is there a VP Product?} -- Yes --> B[VP Product holds product strategy]
    A -- No --> C{Who fills the vacuum?}
    C --> D[VP Engineering steps up]
    C --> E[A more independent senior PM]
    C --> F[CEO directly involved]
    D --> G[VP Engineering sits in business conversations]
    D --> H[VP Engineering becomes the technical-to-business translator]
    E --> I[PM has direct access to leadership]
    E --> J[Risk: decisions too reactive without a strategic filter]
    F --> K[High speed]
    F --> L[Risk: inconsistent roadmap direction]

Three main risks to explicitly anticipate when there’s no VP Product:

The roadmap becomes reactive. Nothing structurally maintains the product’s long-term vision. The VP Engineering needs to explicitly allocate time for this — for example monthly roadmap review sessions with the PM and CEO, where long-term priority decisions are locked and documented.

The PM burns out. A PM without a “product superior” receives pressure from all directions — business, engineering, and users — with no one filtering. The VP Engineering needs to be aware of this and actively help the PM prioritize, not just accept all incoming requests.

Technical debt has no advocate on the business side. Usually the VP Product helps explain to stakeholders why technical investment is needed. Without them, the VP Engineering must be able to translate technical needs into business language — and this is a skill not all VP Engineers naturally have.

1. Define Authority Boundaries Explicitly

Most cross-role conflicts happen not because the people are incompetent, but because there was never a written agreement about who decides what.

ANTI-PATTERN: authority boundaries left implicit

"Everyone is mature, they'll surely know their own boundaries."

Result: the PM makes technical decisions because nothing feels forbidden.
        The EM rejects requirements because it feels outside their territory.
        The VP Engineering overrides EM decisions
        without knowing the EM already had strong reasons behind them.

CORRECT: authority boundaries written and communicated

Example of a simple working agreement:

The PM decides: feature priorities, MVP scope, acceptance criteria,
               launch timing from the product side.

The EM decides: technical estimates, sprint capacity, task assignment,
               code quality standards, who works on what.

The VP Engineering decides: long-term technical direction, hiring,
                            architecture standards, upward escalation,
                            decisions spanning more than one team.

2. Separate “Requests” from “Decisions”

The PM may have requests to engineering — this is normal and should happen. What must not happen is the PM making unilateral technical decisions, or the EM making unilateral scope decisions.

Legitimate requests from the PM to the EM:
  ✓ "Can we finish this within this Sprint?"
  ✓ "What technical options do we have for this problem?"
  ✓ "If we have to cut scope, which part has the smallest
      technical impact?"

Decisions outside the PM's authority:
  ✗ "We'll use database X for this feature."
  ✗ "Engineer A will work on this task."
  ✗ "Testing can be skipped for this release."

Legitimate requests from the EM to the PM:
  ✓ "Of these two features, which matters more to users?"
  ✓ "What happens on the business side if we delay this by 1 Sprint?"
  ✓ "What are the acceptance criteria for this edge case?"

Decisions outside the EM's authority:
  ✗ "This feature doesn't need to be built."
  ✗ "We launch when the team feels ready."
  ✗ "This scope is too big, I'm cutting half of it."

3. Make Escalation a Process, Not a Weakness

In many teams, escalation is seen as a sign that someone can’t solve their own problems. This is a wrong culture that ultimately lets small problems grow large.

flowchart TD
    A[A conflict or difficult decision appears] --> B{Can it be resolved at this level?}
    B -- Yes --> C[Resolve it, document the decision]
    B -- No --> D{Who should escalate?}
    D -- PM and EM conflict --> E[Bring it to the VP Engineering together]
    D -- Large capacity issue --> F[EM escalates to the VP Engineering]
    D -- Strategic product issue --> G[PM escalates to the VP Engineering]
    E --> H[VP Engineering facilitates, not decides unilaterally]
    F --> H
    G --> H
    H --> I[Decision documented and communicated to the team]

A good VP Engineering doesn’t make escalation feel like punishment. When the EM or PM brings a conflict, the VP Engineering facilitates the resolution — not taking over the decision and giving a final answer without hearing all sides.

4. Retrospectives Aren’t Just for the Engineering Team

Cross-role dysfunction patterns almost never appear in daily standups or sprint reviews. They appear in retrospectives — but only if the retrospectives involve all relevant parties.

ANTI-PATTERN: retrospectives only for engineers

The EM leads the retrospective. The PM isn't invited. The VP Engineering
doesn't know the results. Collaboration problems are discussed among
engineers, but never reach the parties who could change them.

CORRECT: retrospectives with the right representation

Internal sprint retrospective (EM + Engineers):
- Focus: technical process, team dynamics, tech debt to address

Collaboration retrospective (EM + PM, once a month):
- Focus: how the collaboration is going, what needs to change

Strategic retrospective (VP Engineering + EM + PM, per quarter):
- Focus: is our way of working still appropriate for the scale and
         complexity that keeps growing?

Anti-Patterns to Avoid

// ✗ PM bypasses the EM, straight to engineers
PM asks an engineer directly to work on something without
the EM's knowledge. The engineer agrees because it's awkward to refuse.
The EM loses visibility. Sprint planning becomes inaccurate.
// ✓ All requests to engineers must go through the EM, even for small things.

// ✗ EM rejects requirements unilaterally
The EM decides a PM requirement isn't worth doing and
informs this decision directly to engineers without discussing
it with the PM first.
// ✓ Technical objections are given to the PM as input, not a final decision.
   If the two can't resolve it, escalate to the VP Engineering together.

// ✗ VP Engineering too deep in daily technical details
The VP Engineering attends code reviews, comments on specific implementations,
and dominates technical discussions that should be led by the EM.
// ✓ The VP Engineering sets standards and guardrails, then gives the EM room to
   manage their own technical details.

// ✗ VP Engineering doesn't provide strategic context to the EM and PM
The EM and PM execute without knowing why something is prioritized,
what's happening at the business level, or where the team is heading
in 6 months.
// ✓ The VP Engineering regularly shares strategic context — not just
   decisions, but the reasons behind them.

// ✗ PM provides technical solutions, not business problems
The PM comes with finished technical specifications and asks
engineering to implement them exactly as the PM designed.
// ✓ The PM brings a problem statement and desired outcome, then
   lets the EM and team find the best technical solution.

// ✗ Authority boundaries never defined
Everyone works based on assumptions about what they may and
may not decide, and each person's assumptions are inconsistent.
// ✓ Create a simple working agreement defining the decision
   domain of each role, and review it every 6 months.

Team Collaboration Structure Review Checklist

ROLE CLARITY:
  □ A written working agreement exists about each role's decision domain
  □ All team members (including engineers) know who to go to for different request types
  □ The VP Engineering, EM, and PM can explain their role differences without confusion

COMMUNICATION FLOW:
  □ All requests to engineers go through the EM first
  □ The PM doesn't make unilateral technical decisions
  □ The EM doesn't reject requirements without discussing with the PM
  □ The VP Engineering doesn't override EM decisions in front of the team

COLLABORATION RHYTHM:
  □ Regular alignment sessions exist between the EM and PM (at least per sprint)
  □ The VP Engineering has regular 1-on-1s with the EM
  □ An EM-PM collaboration retrospective exists at least once a month
  □ A strategic VP Engineering + EM + PM review exists per quarter

PROJECT INITIATION:
  □ New projects start with a problem brief from the PM, not a solution
  □ The EM is involved after the problem brief is solid, not before
  □ Scope, timeline, and trade-offs are documented before execution starts
  □ Acceptance criteria are available before engineering starts coding

DANGER SIGNS — FOLLOW UP IMMEDIATELY IF:
  □ Engineers don't know who to listen to
  □ The EM is always "catching up" on what their team has already promised
  □ Sprint velocity can't be predicted and nobody knows why
  □ An EM resigns or shows significant signs of disengagement
  □ The PM complains engineering is unresponsive; the EM complains the PM is unpredictable

Summary

• The VP Engineering, EM, and PM have different, complementary orientations — the VP Engineering upward and outward, the EM into the team, the PM toward product and business. This difference is design, not a source of conflict.
• The VP Engineering functions as a buffer, not a technical problem-solver — their job is protecting the team from top pressure, providing strategic context, and solving systemic problems, not individual technical ones.
• The EM is the only one who accurately knows team capacity — valid estimates can only come from the EM, not from the PM or VP Engineering who lack visibility into the team’s actual condition.
• The PM brings problems, not technical solutions — a good problem statement opens space for the best solution; technical specs from the PM close that space.
• All requests to engineers must go through the EM — even the smallest bypass damages the EM’s authority and their visibility into team capacity, leading to unpredictable sprints.
• Authority boundaries must be explicit, not assumed — a simple working agreement about who decides what is worth more than hundreds of alignment meetings.
• Escalation is a process, not a weakness — a conflict between the EM and PM brought to the VP Engineering is a sign of a healthy team, not a sign of failure.
• Without a VP Product, the VP Engineering steps up — this must be consciously recognized, because otherwise the “what and why” vacuum is filled by chaos, not by anyone structured.
• Collaboration retrospectives need to involve all layers — cross-role problems will never be resolved if only discussed within a single role.