Most engineering management writing assumes a PM partner. Platform, infra, security, and developer-tools teams often do not have one — or have a PM whose role is mostly intake and not strategy. EMs of these teams have to do the roadmapping themselves, with all the cross-functional discipline that requires. This guide is for that EM.
The fundamental difference
Product teams ship features for end-users; platform teams ship capabilities for other engineers. The “user research” is internal interviews; the “metrics” are developer velocity, reliability, and cost. The “PM” role is the EM’s job (or shared with a TL).
Identify your stakeholders
- Other engineering teams who consume your platform
- Their EMs and senior ICs
- The leadership chain that funds you
- Compliance, security, finance — depending on the platform
- Sometimes external — vendors, customers using your APIs
Write the list explicitly. You will refer to it when prioritizing.
Discovery: what do they need?
- Quarterly interviews with each stakeholder team’s EM and senior ICs
- Specific questions: what is slowing you down? What capability is missing? What would you build if we could not?
- Quantify when possible — “compile takes 12 minutes; we lose 2 hours/day per engineer”
- Watch for patterns — three independent teams asking for the same thing is a strong signal
Themes from the inputs
Group raw requests into themes:
- Reliability: reduce SEV count, improve MTTR
- Velocity: faster CI, better local-dev, less yak shaving
- Capability: new platform feature requested by multiple teams
- Cost: reduce infra spend with same throughput
- Compliance: security or regulatory commitments
3–5 themes per year is the right level of abstraction. Don’t roadmap features; roadmap themes with named outcomes.
Prioritization without a PM
The PM-equivalent rubric for platform work:
- Number of teams impacted
- Severity (is it a velocity tax, a reliability risk, a compliance gap?)
- Cost to ship (engineer-quarters)
- Strategic fit (does it align with stated company direction?)
- Reversibility (can we ship a partial version and iterate?)
Score, rank, and present. The act of writing it down lets stakeholders push back with specifics.
OKRs for platform teams
Platform OKRs are easier than product OKRs in one way (no growth metric required) and harder in another (the value is felt downstream). Examples that work:
- “Reduce p99 CI build time from 18 min to 8 min”
- “Onboard 3 new teams to the new auth library”
- “Reduce SEV-2 incidents in the data pipeline by 50%”
- “Cut infra spend on service X by 30% with no latency regression”
- “Ship the eval-as-a-service platform; 5 teams using it by EOQ”
The customer review
Once a quarter, present the roadmap to the consuming teams’ leads:
- Themes for the quarter
- What you are committing to
- What you are deprioritizing and why
- What you need from them (review time, beta participation, feedback)
This is the platform-team equivalent of a product launch review. Do it whether or not anyone asks for it.
Operational discipline
Platform teams own services that everything else depends on. The roadmap must include:
- On-call rotation and incident playbook
- Maintenance budget — % of time for upgrade, patching, deprecation
- Documentation budget — your platform is unusable without docs
- Onboarding budget — every new consuming team requires support
Skipping these makes the platform fragile. Bake them in at planning time.
Communicating across the gap
- Office hours: weekly drop-in for consuming teams
- Slack channel: real-time questions, with rotating coverage
- Quarterly newsletter: what shipped, what is coming, what is deprecated
- Release notes for platform changes — even small ones
The political game
Platform teams are political because they say no a lot. Strategies that work:
- Build credibility with one or two consuming teams who advocate for you
- Quantify your impact in their language (“we saved your team 8 person-weeks last quarter”)
- Frame your asks in terms of company outcomes, not platform aesthetics
- Be visible at planning sessions across the org
- Avoid the “platform team that says no to everything” reputation by saying yes selectively and well
What separates senior platform EMs from staff/director
Senior EMs run their team’s roadmap effectively. Staff/director-level platform EMs work the cross-team layer well — they shape consumer expectations, negotiate roadmap sequence with peer EMs, and influence company-wide architectural direction without owning a product.
Frequently Asked Questions
Should I push to get a PM assigned?
If your platform is large enough (say, 15+ engineers and 5+ consuming teams), yes. Below that, the EM-and-TL pair usually suffices.
How do I justify investment without revenue?
Tie to the consuming teams’ goals. “If reliability does not improve, the X launch slips a quarter; that is the cost of not investing.”
What metrics actually matter for platform teams?
Time-to-build, deployment frequency, MTTR, incident count, infra cost per unit work, satisfaction of consuming teams (annual survey). Lines of code never matters.