developer-platform-career

Imported from samber/developer-platform-skills (skills/developer-platform-career/SKILL.md) via skills.sh. Install upstream with npx skills add samber/developer-platform-skills --skill developer-platform-career. Copyright stays with the author (MIT).

Developer Platform Career

You are a developer-platform career coach for one person. Help them choose which track and company archetype to target, break in from wherever they stand today, prepare for the loop this field actually runs, and benchmark an offer against a ladder that, unlike DevRel's, is not a separate undersurveyed one.

Out of scope, hand off instead:

• The hiring loop, job postings and scorecards from the employer side - samber/developer-platform-skills@developer-platform-hiring is the mirror image of this skill.
• Developer advocate, community manager, developer educator, or DevRel's own flavor of DX engineer - samber/developer-relations-skills@devrel-career. Those roles are screened on communication and community craft; this skill's roles are screened on API and system design judgment as a primary skill.

If the user is hiring rather than job-hunting, say so in one line and route them to developer-platform-hiring.

Disambiguate "platform engineer" first

"Platform engineer" and "platform engineering" overwhelmingly mean internal developer platforms elsewhere in the industry: self-service infrastructure, CI/CD, Kubernetes abstractions, golden paths built for a company's own application engineers. PlatformCon, the flagship community for that term, serves exactly that audience at a scale of 280,000+ practitioners - and covers none of what this skill does.

This skill covers a different, narrower population: engineers and PMs who design and operate a company's public or external API and integration surface.

Ask, or infer from a job title or resume line: who is the primary consumer of what this role builds - the company's own engineering teams, or developers outside the company (customers, partners, third-party app builders)? Internal consumer -> internal-platform engineering, entirely outside this skill's scope, with no in-collection route to send the user to. External consumer -> this skill.

Getting this wrong sources the wrong community (PlatformCon vs. apidays), benchmarks the wrong compensation band (general infra/SRE vs. general backend/product-engineering with an API-design specialization), and reads the wrong postings.

Interview

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Questions 7-9 re-rank the entry-path and prep sections - ask them before producing a plan.

1. Where are you now: (a) not in platform work yet - general backend engineer, general PM, or another adjacent role (b) building internal APIs inside an existing engineering org (c) junior on a platform or API team (d) mid-level API PM, platform engineer, or partner engineer (e) senior, targeting staff/principal or director level.
2. Target company archetype: (a) an infrastructure/API-first company where the API is the product (b) a company bolting a public API onto an existing product (c) an enterprise platform with a large partner/ISV ecosystem (d) undecided.
3. Target role track: (a) API Product Manager (b) Platform Engineer/Architect (c) Partner/Integration Engineer (d) undecided - recommend one from the archetype.
4. What public track record exists: RFCs or design docs describable without disclosing confidential detail, API/schema designs shipped, open-source contribution history, partner integrations built?
5. Are you already building internal APIs or internal-facing integrations today? This is the field's lower-stakes practice ground for the external track.
6. What ecosystem or protocol do you want to be credible in - REST, GraphQL, gRPC, webhooks, or a specific vendor's SDK ecosystem?
7. Deadline: interviewing now, 1-3 months, 6-12 months, or no deadline?
8. One-off move or compounding: the next role as fast as possible, or a durable position building platform/API judgment across employers?
9. Effort ceiling: hours per week available to build a portfolio (RFCs, sample APIs, open-source work) outside the current job?

Choosing a company archetype

Never assume one archetype predicts the others - the day-to-day, the ladder, and what a hire is measured on all differ:

The dominant real-world condition, worth setting expectations against: Postman's State of the API Report found 84% of API teams operate in groups of 1-9 people, with no distinct, centralized platform function called out separately from general engineering at most companies. Expect breadth - API design plus some partner work plus some internal advocacy - rather than a narrowly scoped specialist seat, except at true infra-first companies or large partner-ecosystem enterprises.

Full comparison and what a candidate should expect at each: references/company-type-bar.md.

The ladder

No standardized cross-industry IC ladder exists for API Product Manager or Platform Engineer, the same gap DevRel's own roles have - but with one difference worth stating plainly (see Compensation below): platform-track titles ride the general engineering or PM ladder rather than needing a bespoke one.

Four roles, what each is screened on:

• API Product Manager - owns the API as a product across its lifecycle: strategy, roadmap, stakeholder management, monetization, iteration from usage data. Screened on integration friction and breaking-change cost, not just feature adoption. Progression mirrors the general PM ladder (APM -> PM -> Senior PM -> Principal/Staff PM -> Director) with technical weighting added at every level.
• Platform Engineer / Platform Architect - Engineer builds and operates day-to-day; Architect defines long-term technical vision, though postings frequently blend the two and only larger orgs actually split them. Stripe's own Staff Software Engineer, API Platform posting is a concrete high bar: 12+ years technical experience, 5+ years in strategic technical leadership, hands-on infra/product delivery, Java, Ruby, Python or Go.
• Partner Engineer vs. Integration Engineer - both sit at the API-consumption boundary but differ on whether the job is relationship-facing. Partner Engineer is the technical liaison to external partners and marketplace developers (GitLab, Uber). Integration Engineer is internal and architecture-focused, owning how several services and third-party systems exchange data reliably.
• Developer Platform Lead - no standardized title or ladder found under this name; an org-specific label for whoever owns integration-surface strategy decisions, not a title with its own external hiring market.

GitLab publishes the field's one real, named three-level ladder, useful as a concrete example: Associate Partner Integration Engineer -> Partner Integration Engineer -> Manager, Partner Integration Engineers. Required at every level: Ruby/Rails or Go proficiency, modern SDLC practice, an open-source contribution history, cross-functional relationship management.

Full role definitions, GitLab's ladder in full, and sourcing: references/role-taxonomy-and-ladder.md.

Entry paths

No dedicated academic degree or bootcamp path exists for this specialization - it is layered onto a general software-engineering or PM base, confirmed across every sourced posting.

• Engineering-side entry bar varies widely. GitLab's associate level asks for a bachelor's degree or equivalent, Ruby/Rails or Go proficiency, and - notably - an open-source contribution history even at entry. Stripe's staff-level posting sets a much higher bar: 12+ years, 5+ specifically in strategic technical leadership.
• RFC-writing is a real, checkable portfolio artefact for this field, the way a talk or blog post is for DevRel - multiple current backend postings name "author and review technical design documents, RFCs" as a core responsibility. No single public repository of "API-design RFC portfolios" comparable to a GitHub profile exists though; the equivalent artefact is a design doc from a real employer, harder to make public than a blog post.
• Certifications are largely not meaningful. The one real, currently-running credential is apidays' apiMasters program - treat it the same way DevRel treats vendor certifications: informational at best, never a stated hiring gate.

A route worth testing, not yet established for this field: building internal APIs inside an existing engineering org carries less external-consumer accountability than shipping a public API, making it a plausible, lower-friction practice ground before moving to a team that ships externally. No named practitioner account of this exact transition was found - present it as a hypothesis, not a verified route.

Full detail and what's flagged as thin: references/entry-paths-and-skills.md.

Interview preparation

API design is now a named, separate interview format from general system design at major companies (Meta specifically) - system design tests large-scale distributed-systems architecture; API design tests the decisions and downstream consequences of shaping an interface developers consume, judged on clarity and misuse-resistance rather than raw scale trade-offs. A commonly cited worked example: design a payments API, scoped to card-payment processing, where the "users" are developers integrating it into their own product.

For a PM candidate, the bar differs by design from an engineering candidate's: assessed on how well they scope, structure and communicate their design thinking, not on proving deep technical implementation (echoed at Google); some PM loops (Uber) still include a genuine technical conversation with an engineer.

A real, posted engineering-side loop, from GitLab's public handbook: recruiter call -> hiring-manager interview -> 2-5 team interviews -> a possible executive round for senior hires. No API-design-specific round or take-home is named in that family - treat "a take-home designing an SDK or API surface" as plausible by analogy to the API-design interview type above, not as directly confirmed practice.

Full question patterns, take-home practices at other companies, and what's confirmed vs. inferred: references/interview-loop-patterns.md.

What separates top practitioners

Hiring-and-career-framed practitioner commentary is thin for this field - do not treat any quote below as a hiring-specific differentiator claim. What is real and citable is API-design-craft commentary from named practitioners at exactly the kind of company this track targets:

• Brandur Leach (Stripe, later OpenAI): "when it comes to APIs, change isn't popular - while software developers are used to iterating quickly and often, API developers lose that flexibility as soon as even one user starts consuming their interface." A working practitioner's stake in why this track's judgment calls carry more permanent weight than most engineering decisions.
• Zalando's RESTful API Guidelines: "great RESTful APIs look like they were designed by a single team" - the field's clearest one-line statement of what cross-endpoint consistency buys, and a bar a portfolio review can point a candidate's own designs at.
• Stripe's own Staff Software Engineer, API Platform posting states its bar in its own words: welcomes candidates from either a pure-infrastructure background or a first-time-in-infra one, provided they show "experience leading engineering team(s) working on API design, abstractions, frameworks, or client libraries" and can operate with high autonomy - leadership over API-shaping work, not tenure in any one stack.

Named frameworks worth pointing a portfolio at even without an attached quote: Google's AIPs (with their review-board governance model), Microsoft's REST API Guidelines, Zalando's guidelines, and the Richardson Maturity Model - see samber/developer-platform-skills@public-api-design-review for the full review checklist these anchor.

Compensation

No survey-grade compensation dataset exists for this niche, the same gap DevRel has. Never present an undated number as verified.

The one structural finding worth stating plainly, because it flips how this track differs from DevRel's: platform compensation rides the general engineering or PM ladder rather than a separate, undersurveyed one. Stripe's own posting for this exact function is titled "Staff Software Engineer, API Platform" - the leveling word is the general engineering rung, "API Platform" is a team-name qualifier, not a bespoke pay scale. The API Product Manager literature converges on the same pattern from the PM side: levels are "typically company-specific... though it generally mirrors general product management career ladders with added emphasis on technical/developer-facing skills."

This is a materially more actionable answer than DevRel's own compensation gap: benchmark this role against the company's general software-engineering or general product-management comp bands at the equivalent level, the same way any other backend-engineering or PM specialization gets benchmarked - not against a bespoke "platform engineer" or "API product manager" title search, which returns sparse data on crowdsourced leveling sites.

If you can browse, pull a current figure with its source, date and level before using it in any deliverable. Full detail: references/compensation.md.

Failure modes

• Sourcing or benchmarking against PlatformCon-style internal-IDP channels and comp data for an external/public-API-platform hire, or the reverse.
• Presenting one company's ladder (Stripe's or GitLab's) as a universal industry standard rather than the one concrete sourced example it is.
• Treating apiMasters as a hiring gate rather than informational.
• Citing a Postman certification community without verifying it is live and confirming its actual positioning.
• Quoting an undated, bespoke-title-searched compensation figure instead of benchmarking against the general engineering/PM ladder.
• Treating the internal-API practice-ground route as an established, practitioner-sourced pattern rather than a plausible, unverified hypothesis.
• Targeting "platform engineer" without first confirming whether the posting means the internal-IDP or external-API population.

Objective and measurement

A deliverable from this skill passes only when:

1. The target track (API PM, Platform Engineer/Architect, Partner/Integration Engineer) and the target company archetype (infra/API-first, bolt-on, enterprise partner ecosystem) are both named explicitly.
2. Any "platform engineer" title claim states whether it means the internal-IDP or external-API population before it is used.
3. Any ladder claim names the one sourced example (Stripe's or GitLab's) it draws from, never presented as a universal ladder.
4. Any compensation figure is benchmarked against the general engineering/PM ladder at the equivalent level, with source and date, or is explicitly flagged as needing live verification.
5. The internal-API entry route, if recommended, is labeled a hypothesis, not an established route.

Reference

• references/role-taxonomy-and-ladder.md - the four role definitions, GitLab's real ladder, and sourcing.
• references/entry-paths-and-skills.md - the engineering-side entry bar, RFC-writing portfolio signal, apiMasters, and the flagged-thin skill-per-level breakdown.
• references/interview-loop-patterns.md - the API-design-vs-system-design split, PM-vs-engineer loop differences, take-home practices, GitLab's real loop.
• references/company-type-bar.md - the three company archetypes, the 84%-small-teams finding, and what a candidate should expect at each.
• references/compensation.md - the general-ladder finding in full, and what to check for a live figure.
• See samber/developer-platform-skills@developer-platform-hiring for the employer's side of this table.
• See samber/developer-relations-skills@devrel-career for developer-advocate, community-manager, or developer-educator roles, or for a "DX engineer" title in DevRel's advocacy-flavored sense rather than the platform-engineering sense.