The platform team charter decision record: why the internal product boundary you chose determines your developer experience investment ceiling and your team API coupling surface

A 40-person B2B SaaS company built CRM software for professional services firms. The engineering organization had grown from 6 to 40 engineers over two years, adding product teams as the feature surface expanded: a core CRM team, a reporting and analytics team, and an integrations team. The company created a platform team in month 18 of its engineering build-out, staffed with two engineers pulled from the core CRM team who had the deepest knowledge of the deployment infrastructure and the build system. The charter given to the platform team in the kickoff meeting was two sentences: "You own developer infrastructure. Your job is to make the other teams faster." Neither sentence specified what "developer infrastructure" meant in terms of ownership, what making teams faster would be measured by, or how the platform team and the product teams would coordinate when the product teams needed something from the platform team's domain.

For the first three months, the informal scope worked. The platform team focused on the three things that were clearly in their domain: the CI pipeline, the deployment system, and the developer environment setup scripts. They made measurable improvements: CI run time dropped from 18 minutes to 11 minutes, and the developer environment setup that had previously required a 40-minute manual walkthrough became a single script. Both improvements were immediately useful to all three product teams and required no coordination overhead — the platform team built the improvement and the product teams' next CI run or environment setup used it automatically.

The problem emerged in month 5, when the integrations team needed to add a new deployment pattern: they were building a background job processing system that required a different deployment profile than the web service pattern the current deployment system supported. The integrations team lead submitted a request to the platform team. The platform team reviewed it, agreed it was platform team work (it was a change to the deployment system, which the platform team owned), and added it to their backlog. Their current backlog contained 8 items from across the three teams. The estimated delivery timeline for the integrations team's request was 6 weeks. The integrations team lead escalated to the engineering manager: the background job system was on the critical path for a customer commitment. The engineering manager asked the platform team if the timeline could move up. The platform team had two engineers and 8 backlog items; moving up the integrations request required moving other items down. Two of the other 8 backlog items were from the core CRM team, whose tech lead escalated the same week when she heard her team's items might be deprioritized.

The integrations team lead made a pragmatic decision: they would build their own deployment pattern for the background job system, outside the platform team's deployment framework. They didn't ask for permission — the platform team's 6-week timeline had already established that the platform backlog was a constraint to route around, not a service to use. The core CRM team, watching this play out, made a similar decision two weeks later when they needed a new deployment variant for a feature flag service. Both teams built their patterns independently, in the same two-week window, using different underlying mechanisms: the integrations team used a container restart policy that was correct for their workload profile; the core CRM team used a process supervisor approach that worked but was inconsistent with the rest of the deployment system's model. Connect this pattern to the cross-team API ownership decision record: the deployment system boundary decision is structurally identical to the service interface ownership boundary decision — in both cases, a shared capability is owned by one team, consuming teams depend on it, and the consuming teams' ability to get changes made is constrained by the owning team's capacity and responsiveness; the shadow infrastructure accumulation that results from routing around a slow-responding platform team is the same as the undocumented endpoint accumulation that results from routing around a slow-responding API owner, and it carries the same risks: the capabilities exist in production but are not in the system registry, are not maintained to the owner team's standard, and are invisible to security and reliability reviews.

The two incompatible deployment patterns coexisted in production undiscovered for three months, until the security team initiated a patching effort for a container runtime vulnerability and discovered that 7 services were using the integrations team's pattern, 4 were using the core CRM team's pattern, and 18 were using the original platform-team-managed pattern. The security team's patching script targeted the platform-team-managed pattern and worked on 18 services. The other 11 required manual patching. The manual patching took two engineer-weeks — engineering time that was explicitly not budgeted in the patching project. The post-incident review identified the root cause: the platform team charter had not specified what happened when the platform team's capacity was insufficient to respond within the product teams' urgency window. The charter revision that followed added a scope boundary document, a prioritization tier model, and an explicit policy stating that product teams could build shadow infrastructure under specific conditions — time-critical work in the current sprint, not addressable within 2 business days by the platform team — but were required to notify the platform team and commit to migrating to the platform-managed pattern within 60 days. The shadow infrastructure registry was created and immediately had 11 entries on the first day it was opened.

A 55-person developer tools company built a continuous integration and testing platform for software teams. Their internal engineering organization had its own platform team, the Developer Platform team, staffed with 4 engineers whose mandate was to build and maintain the internal developer tooling: the CI system, the deployment pipeline, the feature flag system, and the internal observability stack. The Developer Platform team had, over 18 months, built a genuinely excellent internal deployment platform. The API was clean and well-documented. The deployment pipeline supported multiple deployment strategies (blue/green, canary, rolling update), had first-class support for rollbacks, integrated with the feature flag system to allow gated deployments, and had a web interface that gave product teams a deployment history view with per-deployment health metrics. Product teams consistently described the deployment platform as one of the best internal tools they used. The Developer Platform team was proud of what they had built, and they had modeled their team operation on what they knew from building external developer tools: structured customer intake, formal prioritization, and regular roadmap communication.

The intake process for platform team requests required product teams to submit a GitHub issue in the Developer Platform team's internal repository using a structured template: description of the need, use case and affected teams, priority (P0/P1/P2/P3) as assessed by the requesting team, and a link to any relevant context. The Developer Platform team triaged issues weekly, on Mondays. P0 issues (production incidents) were handled immediately. P1 issues (blocking in-sprint work) were added to the current sprint if capacity existed, otherwise to the next sprint — which meant a maximum 2-week wait. P2 and P3 issues were evaluated in quarterly roadmap planning, which meant they could wait up to 3 months. The system was clear, predictable, and fair across teams. Product team managers appreciated knowing exactly where their requests stood. The Developer Platform team's sprint reviews consistently showed a high percentage of committed issues delivered — they were reliable and communicative.

The problem surfaced in Q3, when the Core Product team needed to add gated feature releases per customer to a new feature they were shipping. The feature required a deployment pipeline change: the pipeline needed to support per-customer feature flag evaluation at deployment time, not just at request time. The Core Product team's tech lead submitted a GitHub issue with a P1 priority. The Developer Platform team's Monday triage reviewed it and reclassified it as P2: the feature was not currently blocking a production deployment, and the current sprint was already full. The next quarterly roadmap planning was 6 weeks away. The Core Product team's tech lead escalated to the VP of Engineering: this feature was on the customer commitment list for end-of-quarter. The VP of Engineering joined the next Monday triage meeting and advocated for the reclassification to P1. The Developer Platform team agreed to add the issue to their sprint — but they were mid-sprint and already overcommitted. The actual delivery slipped to the sprint after the current one: a 3-week wait from the original issue submission.

The Core Product team's tech lead made a different calculation than the first failure pattern's integrations team lead. She did not want to build a shadow deployment pipeline — the platform deployment system was too good and too central to worth duplicating. Instead, she built a workaround: a pre-deployment script that read the feature flag service directly, evaluated the per-customer flags, and wrote the evaluation results to a configuration file that the deployment container read at startup. The workaround was a 200-line script that she tested in staging, documented in the team's internal wiki, and deployed to production. It worked for the quarter's delivery. Connect this pattern to the service observability ownership decision record: the workaround script was reading the feature flag service directly, bypassing the deployment pipeline's authentication model; the service observability ownership decision record describes the coverage gap that accumulates when teams build monitoring outside the central observability platform — the authentication gap that the workaround introduced is structurally identical: when a team builds a capability outside the platform's security model because the platform's responsiveness was insufficient, the capability they build does not inherit the platform's security guarantees, and the gap is invisible to the security review process that audits the platform's authentication model but not the team's workaround script.

The authentication gap was discovered 4 months later during a SOC 2 Type II audit preparation. The auditor reviewed the deployment pipeline's authentication model, confirmed it was compliant, then found the Core Product team's pre-deployment script in the codebase. The script was reading the feature flag service with a service account whose permissions were broader than the minimum required — the tech lead had used the Core Product team's existing service account, which had been granted read access to all feature flags for a different, legitimate purpose. The feature flag service contained per-customer configuration data that was classified as potentially sensitive under the company's data handling policy. The pre-deployment script was reading that data with an over-permissioned service account, outside the deployment pipeline's audit logging, and writing the results to a container configuration file that was not covered by the deployment pipeline's configuration encryption policy. The remediation required 3 weeks of work: a new service account with minimum-required permissions, a change to the script to read only the flags the deployment needed, an update to the deployment pipeline to add the script to its audit logging scope, and an encryption key rotation for the configuration files that had been written under the old policy. The Developer Platform team's retrospective identified the root cause as the triage model: the P2 classification for a blocking-but-not-today request had produced a 3-week wait that exceeded the product team's tolerance, and the workaround the product team built was outside the security boundary the platform team had designed around its own systems.

A 38-person fintech startup built a payment reconciliation platform for marketplace operators. The engineering organization had 28 engineers across 5 product teams, plus a 3-person Developer Platform team that had been created 10 months earlier with a charter from the VP of Engineering: "improve developer experience." The charter had no specific success metrics, no measurement methodology, and no adoption ownership. The Developer Platform team interpreted the charter generously: they identified the three developer experience problems they believed had the highest impact and built solutions to each. They were right about the problems — all three were real pain points that engineers had mentioned in previous retrospectives and 1:1s.

The first problem was CI speed. The average CI run for the payment reconciliation service was 22 minutes. The Developer Platform team spent 6 weeks profiling the CI configuration, restructuring the test parallelization, caching dependencies more aggressively, and moving the most expensive test suites to a different runner type. The result was a CI run time of 13 minutes — a 41% reduction. They announced the improvement in the engineering all-hands, received positive reactions, and marked the project complete. The second problem was log format inconsistency. The 12 services in the platform were emitting logs in 4 different formats: JSON with different schema conventions, structured text, unstructured text, and one service that was still using printf-style logging. The Developer Platform team built a centralized logging library that standardized the log schema, added structured fields for trace ID, service name, and environment, and integrated with the company's log aggregation system. They announced the library, wrote a migration guide, and added it to the internal documentation. They marked the project complete. The third problem was deployment visibility. Engineers had complained that they couldn't see deployment history — they could deploy, but to know whether a deployment had succeeded or what had been deployed previously required reading Slack or checking the CI system directly. The Developer Platform team built a deployment dashboard: a web interface showing per-service deployment history with timestamps, artifact versions, health status for the 30 minutes after each deployment, and a rollback button. They built it in 8 weeks, announced it, and marked the project complete.

The VP of Engineering's quarterly engineering review, 8 months after the Developer Platform team had completed all three projects, included a question she had not asked before: what was the actual productivity impact of the platform team's work in the past 8 months? The review gathered data from three sources. First, the CI speed improvement: the 22-to-13-minute reduction was real and measurable. All CI runs were now at 13 minutes. This improvement was fully adopted automatically — it was a platform-level change that required no product team action. Second, the centralized logging library: 4 of 12 target services had migrated. The migration guide existed in the documentation, but the Developer Platform team had not tracked adoption, had not set migration deadlines, and had not provided pairing support for teams doing the migration. The 8 services that had not migrated were still emitting logs in their original format, which meant the log aggregation system's search and alerting features — which required the structured fields the library provided — were unavailable for those 8 services. The centralized logging investment's value was gated on adoption, and adoption was at 33%. Connect this pattern to the developer experience measurement decision record: the Developer Platform team had the same measurement problem as an engineering organization that tracks story points completed rather than features adopted: completing the library and completing the migration are different definitions of done, and the platform team's choice to use the first definition meant the second definition was never tracked; a developer experience measurement framework that defined "centralized logging adoption rate across all target services" as a lagging indicator and "migration support hours requested" as a leading indicator would have surfaced the adoption gap within 30 days of the library shipping, not 8 months later.

Third, the deployment dashboard: 3 of 22 engineers used it regularly, defined as accessing it more than once per week in the last 30 days. The remaining 19 engineers had learned about the dashboard from the all-hands announcement, had looked at it once or twice when it launched, and had continued using Slack and the CI system to track deployment status because that was the workflow they already had. The dashboard was a better solution for the problem than the Slack + CI combination — the VP of Engineering verified this personally by spending 20 minutes with both interfaces. But it was an opt-in solution, and the workflow it was replacing was not being deprecated. Engineers who continued using Slack + CI were not paying a cost that was increasing over time; the new workflow was available but not on the path of least resistance. The adoption forcing function was absent: the dashboard was better, but not better by enough to overcome the inertia of an existing workflow that already worked. The VP of Engineering's review estimated that the 6-week CI project, the 10-week logging library project, and the 8-week deployment dashboard project had consumed approximately $180k in engineering time at fully-loaded cost. The CI improvement was fully adopted and provided a measurable daily time saving that the VP estimated at approximately 12 engineer-hours per week across the team — a payback period of roughly 7 months at the team's cost rate. The logging library at 33% adoption was providing approximately 4 engineer-hours per week in search and alerting efficiency for the 4 services that had adopted it — at that adoption rate, the investment would not pay back within the year. The dashboard at 14% engineer adoption was providing effectively no measurable productivity improvement.

Structural properties set by the platform team charter decision

Three structural properties are determined by the founding decisions about what the platform team owns, how it interacts with product teams, and what it measures as success. None of these properties are visible in the platform team's sprint velocity, their project delivery rate, or the engineering all-hands reaction to their launches. They are established by whether the scope boundary is explicit enough to prevent ambiguous-case routing-around, whether the customer model is calibrated to the product teams' urgency distribution rather than a formal external-customer process, and whether success is measured by adoption at threshold rather than by feature completion.

Property 1: The developer experience investment ceiling. The developer experience investment ceiling is the maximum improvement in product team productivity the platform team can deliver before the coordination overhead of using the platform exceeds the productivity gain for some class of product team requests. It is not a fixed property of the platform team's technical quality — the second failure pattern's platform team built genuinely excellent infrastructure, yet still set a low investment ceiling because their customer model produced a 3-week response time for urgent requests. The ceiling is set by the intersection of the platform team's responsiveness model and the urgency distribution of product team requests. A platform team that is fast for planned, non-urgent requests and slow for urgent, time-sensitive requests sets a ceiling that is crossed by the first category of requests that matters to product teams: the blocking-today, can't-wait-2-weeks request. When the ceiling is crossed, product teams do not stop using the platform for the requests the platform handles well; they route around it for the requests it handles poorly, building shadow infrastructure that is not maintained to the platform team's standard and is invisible to the platform's security and reliability model. The shadow infrastructure accumulation rate is the rate at which the investment ceiling is being crossed: a high accumulation rate indicates a ceiling that is frequently exceeded, which indicates a customer model that is miscalibrated to product teams' urgency distribution. Connect this property to the cross-team API ownership decision record: the cross-team unblocking latency in the API ownership decision record and the platform team's investment ceiling are set by the same mechanism — when the team that owns a shared capability cannot respond within the consuming team's urgency window, the consuming team builds outside the ownership boundary; both the shadow API surface that accumulates from a slow-responding API owner and the shadow infrastructure that accumulates from a slow-responding platform team carry identical risks: undocumented capabilities, inconsistent security model, invisible to the registry that defines the system's production surface.

Property 2: The team API coupling surface. The team API coupling surface is the total number of integration points between each product team and the platform team — every platform-owned service, API, tool, or process that a product team depends on in their critical development or deployment path. The coupling surface is not inherently bad. It represents value delivered: every integration point means the platform team is providing a capability the product team would otherwise have to build and maintain themselves. But the coupling surface's size determines two downstream properties. The first is the cross-team coordination overhead per feature shipped: a feature that requires changes to 3 platform-owned capabilities requires coordinating with the platform team 3 times, and the total coordination cost is proportional to the platform team's responsiveness model at each of those 3 touchpoints. The second is the shadow infrastructure accumulation rate: a high coupling surface with a low-responsiveness platform team produces a high shadow infrastructure accumulation rate because the probability that at least one of the platform dependencies will be in the path of a time-critical product team request is higher when the coupling surface is larger. A platform team that expands its scope without proportionally expanding its responsiveness capacity is increasing the coupling surface faster than it is increasing its ability to serve the dependencies it is adding. Connect this property to the service observability ownership decision record: the observability platform ownership decision — whether observability infrastructure is centrally owned (platform team), federated (platform team provides the framework, product teams instrument their own services), or individually owned (each team builds its own monitoring) — is the most common first decision that reveals the coupling surface tradeoff; a centrally-owned observability platform with a slow response time for instrumentation changes produces the same routing-around behavior as a centrally-owned deployment platform with a slow response time for pipeline changes; the federated model that the observability decision record describes as the most common resolution to the coverage gap is the same resolution: the platform team owns the shared infrastructure layer and the framework, product teams own the instrumentation and alerting for their own services, and the boundary between them is specified explicitly so that ambiguous-case decisions don't produce inconsistent coverage.

Property 3: The adoption forcing function. The adoption forcing function is whether the platform's value is opt-in or path-of-least-resistance. Opt-in platforms require product teams to actively choose to use a new platform capability — to pay a migration cost, to change a workflow, to prioritize a task that is not on the product team's direct delivery path. Path-of-least-resistance platforms are the default for new work: starting a new service uses the platform's templates, setting up a new deployment uses the platform's pipeline, writing a new log uses the platform's library because the library is the only logging dependency in the standard project scaffold. The adoption forcing function is the structural property that closes the completion-versus-adoption gap: a platform team that measures adoption at threshold rather than feature completion is implicitly committing to build an adoption forcing function for each capability they ship, because the only way to achieve adoption at threshold is to either make migration easier than maintaining the old approach or to set a migration deadline with actual enforcement. A platform team without adoption tracking measures completion and reports success based on features shipped; a platform team with adoption tracking measures adoption rate at 30/60/90 days and discovers, as the third failure pattern discovered, that 33% adoption of a centralized logging library 8 months after launch is not a success — it is a measurement that reveals the absence of a migration cost differential or a migration deadline that would have driven adoption above the value threshold. Connect this property to the on-call rotation design decision record: the on-call rotation design has the same adoption forcing function problem for observability-related features — a platform team that ships centralized alerting but does not update the on-call runbooks to reference the new alerting interface, does not train on-call engineers to use the new interface during an incident, and does not deprecate the old alerting paths is providing an opt-in alerting improvement that on-call engineers will not opt into during an incident because the incident context is not the right context for learning a new tool; the adoption forcing function for on-call tooling requires the platform team to work with the on-call rotation design to make the new tooling the path of least resistance during an incident — updating the runbooks, providing a training rotation, deprecating the old paths — not just to ship the tooling and announce it in an all-hands.

The platform team charter ADR: five sections

Section 1: Platform scope and boundary definition. Begin the platform team charter decision record by specifying what the platform team owns and what product teams own, with an explicit framework for resolving ambiguous cases rather than a list of current systems. A list of current systems is a point-in-time description that becomes outdated the moment a new system is added; a boundary framework is a durable decision that applies to new systems as they arise. The framework for categorizing work into platform-owned, product-team-owned, or boundary-case should answer three questions explicitly. First, is the work needed by more than two teams? Work that is specific to a single team's use case is almost always better owned by that team: the platform team's overhead (design review, API standardization, documentation, on-call coverage) is a fixed cost that is only justified when multiple teams benefit. Work needed by three or more teams is a candidate for platform ownership because the duplication cost across those teams is higher than the platform overhead. Work needed by exactly two teams is genuinely ambiguous — the answer depends on the second and third questions. Second, does the work have reliability, security, or consistency requirements that benefit from a single owner? Deployment pipelines, authentication systems, encryption key management, audit logging, and centralized secrets management all have requirements where inconsistent implementations across teams produce risk that a single owner can prevent. These are strong candidates for platform ownership regardless of team count. Feature flag systems, observability configuration, and logging libraries are more ambiguous — they benefit from consistency but function correctly with per-team variations, and the migration cost to centralize them may exceed the consistency benefit if product team autonomy is high. Third, can the platform team respond to work of this type within product teams' urgency distribution? This question prevents the scope expansion failure: a platform team that takes ownership of a capability without having the capacity to respond to time-sensitive requests for that capability is setting a coordination overhead trap. If the answer is no, the scope decision should either be deferred until the platform team has sufficient capacity, delegated to a self-service model where product teams can make changes within defined guardrails without platform team involvement, or scoped as platform-provided framework with product team execution. Connect this section to the cross-team API ownership decision record: the API ownership boundary decision and the platform scope boundary decision follow the same three-question rubric — multi-team benefit, reliability/security benefit from single ownership, and owner responsiveness within consumer urgency distribution — and should be made in the same decision record or explicitly cross-referenced, because the platform team often becomes the API owner for the shared services it owns, and the API governance policy (change classification, notification windows, deprecation timelines) applies to the platform team's APIs with product teams as consumers the same way it applies to any service team's API with other service teams as consumers.

Section 2: The internal customer model and prioritization framework. Specify how the platform team receives and prioritizes work from product teams — not in terms of tools or process steps, but in terms of the response time commitment for each class of request and the staffing model that makes that commitment real. The customer model must be calibrated to the product teams' urgency distribution, not to the platform team's capacity convenience. The three-tier model is a useful starting structure. Tier 1 (respond within 1 business day): requests that are blocking a product team's ability to ship to production today, or that introduce a live security or reliability risk. These are not planned or scheduled; they arrive at any time and require immediate response. The tier-1 commitment is real only if the platform team has a designated responder available at any time during business hours — either through a dedicated platform team rotation, a per-engineer availability commitment with a coverage schedule, or a shared on-call rotation that includes platform team engineers. An SLA that exists in writing but is not backed by a staffing commitment is not an SLA; it is a statement of intention that will be violated the first time a tier-1 request arrives when every platform engineer is in sprint planning. Tier 2 (respond within 5 business days): requests that are blocking planned work in the current sprint but are not time-critical today. These are scheduled into the current or immediately following sprint. The tier-2 commitment requires a sprint capacity allocation — a percentage of each sprint that is held for incoming tier-2 requests rather than committed to roadmap work. Without a capacity allocation, tier-2 requests are always competing with roadmap commitments and will always lose to roadmap commitments in sprint planning; the tier-2 SLA will be a fiction that product teams learn to disregard. Tier 3 (roadmap consideration): requests that represent new capabilities, significant design work, or work that is valuable but not time-sensitive. These are evaluated in quarterly planning. The most important decision in the customer model is the reclassification protocol: what happens when a tier-3 request becomes tier-2 mid-quarter, or a tier-2 request becomes tier-1 mid-sprint. The second failure pattern's triage model had no reclassification protocol; a tier-1 reclassification required VP-level escalation, which added latency and organizational friction. The reclassification protocol should specify a direct channel (Slack message to the platform on-call, not a GitHub issue update) and a response time commitment (within 2 hours for tier-2-to-tier-1 reclassification, within 1 business day for tier-3-to-tier-2 reclassification) that does not require management escalation.

Section 3: Success metrics and measurement ownership. Specify what the platform team measures as evidence of its value, who owns each measurement, and at what cadence measurements are reviewed. The most important decision in this section is the adoption-at-threshold model: the platform team specifies, before shipping each new capability, the adoption rate required for the capability to deliver its designed value, and measures adoption rate at 30, 60, and 90 days after launch. The adoption target must be set before the work begins — not after the work ships and the platform team is evaluating whether to call the project successful. Setting adoption targets after the fact produces a measurement that is calibrated to the adoption that happened, not the adoption that is required for value. For the first failure pattern's deployment system, the appropriate adoption metric is "percentage of new services that use the platform-managed deployment pattern rather than a custom pattern within 30 days of service creation"; this metric surfaces routing-around in near real-time rather than 3 months after the fact. For the third failure pattern's centralized logging library, the appropriate adoption metric is "percentage of target services emitting logs in the standard format"; the target should be set at the migration threshold required for the log aggregation system's search and alerting features to be useful — if 8 of 12 services are emitting incompatible logs, the search feature is not useful for cross-service incident investigation regardless of how well the 4 adopting services are instrumented, and the target should be 10 or 12 of 12, not "most services." Three additional metrics belong in the platform team's measurement framework. Unblocking latency: the median and 90th-percentile time from a tier-1 or tier-2 request submission to the product team being unblocked. This metric is the direct measure of the developer experience investment ceiling — when it rises above the product teams' urgency threshold for a given request type, shadow infrastructure accumulation begins. Shadow infrastructure count: the number of product team capabilities in the shadow infrastructure registry, tracked quarterly. The registry requires that product teams self-report shadow infrastructure, which requires a culture of transparency; the platform team earns this transparency by responding quickly to tier-1 requests and not using the registry as a punitive mechanism. Engineering time recovered: the reduction in product team time spent on infrastructure work that was platform-team work before the platform team took ownership. This metric is harder to measure than the others but is the most direct measure of the platform team's organizational value. It can be estimated from time tracking, sprint retrospective data, or periodic time-use surveys.

Section 4: Adoption and migration policy. Specify how the platform team drives adoption of new platform capabilities and how it deprecates old ones. The adoption policy has three components. Migration support: for each new capability that requires product teams to migrate from an existing approach, the platform team specifies the migration support it will provide — pairing hours, migration scripts, scaffolding, or documentation — and the level of support that is provided by default versus available on request. Default pairing support (the platform team proactively pairs with each product team for one session to do the migration together) produces higher adoption than on-request support (product teams ask for pairing help when they get stuck) because product teams are unlikely to ask for help until they are stuck, and they are unlikely to start the migration until they have a sprint slot, and they are unlikely to prioritize a sprint slot for infrastructure migration unless the migration has a deadline. Migration deadlines: the platform team sets a migration deadline for each new capability that replaces an existing approach. The deadline should be realistic — measured in months, not weeks, for non-trivial migrations — but it should be enforced. Enforcement means that after the deadline, the old approach is deprecated and no longer supported, not that the deadline passes and nothing happens. A deadline with no enforcement is not a deadline; it is a suggestion, and product teams will correctly treat it as such. The deprecation policy: when an old approach is deprecated, the platform team specifies the sunset timeline (total time from deprecation announcement to removal), the migration path document (the specific steps a team takes to migrate, written to be actionable rather than descriptive), the migration commitment process (each team commits to a specific sprint in which they will complete the migration, logged in a shared tracker), and the escalation path for teams that miss their migration commitment. The escalation path must be proportionate: missing a migration commitment by a sprint should produce a 1:1 conversation between the platform team lead and the product team lead, not a skip-level escalation. Disproportionate escalation teaches product teams to avoid the commitment process, which eliminates the migration tracking visibility that the commitment process exists to provide.

Section 5: Platform API ownership and evolution policy. Specify how the platform team manages changes to the interfaces that product teams depend on. This section is the most direct application of the cross-team API ownership decision record's principles to the platform team context: the platform team is, in the API ownership decision record's terms, the service team, and the product teams are the consuming teams. The platform team should adopt the same API change classification and governance model that the cross-team API ownership decision record recommends for service teams. Breaking changes (changes that require product team code modifications to maintain the same behavior): announced with a minimum 60-day migration window, with a breaking change notice in a dedicated channel that product teams have subscribed to, with a migration guide published at announcement time and a designated platform engineer available to support migrations. Additive changes (new capabilities or fields that do not require existing integrations to change): announced with a minimum 5-business-day notice, with documentation updated before the change ships. Deprecations (existing capabilities that will be removed): follow the deprecation policy in section 4, with removal dates that are committed to rather than estimated. The platform team should also specify the inverse: how product teams propose changes to platform APIs. The most common failure in platform API evolution is the unilateral change: the platform team decides to redesign an API based on its own assessment of what product teams need, ships the new API, and discovers during the migration that the new API does not address the actual use cases the old API was serving. A product team proposal process — a lightweight RFC template that asks for use case description, current workaround if any, and urgency tier — gives the platform team the context it needs to design API changes that address real product team needs, and gives product teams a channel to influence platform design that is less costly than building shadow infrastructure. Connect this section to the open-source extractor: the platform team charter decisions — what the scope boundary is, how the customer model is designed, what the adoption forcing function is, how breaking changes are classified — are exactly the kind of multi-variable decisions that happen in AI chat conversations; the VP of Engineering deciding whether to give the platform team ownership of the deployment system without a responsiveness commitment, or whether to set adoption targets before features ship rather than measuring adoption after the fact, or whether the API change classification rubric should treat additive changes to shared libraries differently from additive changes to REST APIs — those conversations happen in ChatGPT or Claude; the written output is the platform team charter document, which records the scope list and the SLAs but not the reasoning behind the customer model choice, the adoption threshold calibration, or the decision to use a three-tier prioritization model rather than a rolling queue; when the charter needs revision because the first failure pattern's shadow infrastructure is accumulating, the engineer revising the charter cannot recover the original reasoning from the document alone.

FAQ

Further reading

• Cross-team API ownership decision record — the platform team charter scope boundary decision and the service API ownership boundary decision follow the same three-question rubric: multi-team benefit, reliability and security benefit from single ownership, and owner responsiveness within consumer urgency distribution; the shadow infrastructure that accumulates when a platform team's investment ceiling is crossed is structurally identical to the undocumented endpoint surface that accumulates when a service team's API governance is too slow — both are invisible to the registry that defines the system's production surface, both carry security and reliability risks, and both require the same remediation: an explicit ownership boundary with a responsiveness commitment that keeps the coordination overhead below the consuming teams' urgency threshold.
• Service observability ownership decision record — the observability platform ownership decision is the most common first decision that reveals the platform scope boundary tradeoff; the coverage gap that accumulates when teams build monitoring outside the central observability platform is the same routing-around behavior that accumulates when the platform team's responsiveness falls below product teams' urgency threshold; the federated ownership model — platform team owns the shared infrastructure layer and the instrumentation framework, product teams own their service-specific instrumentation and alerting — is the most common resolution to the coverage gap, and the boundary between centralized framework and team-owned instrumentation is the same explicit three-question boundary that the platform charter decision record should specify for all platform-owned capabilities.
• Developer experience measurement decision record — platform team success is measured by developer experience improvement in the same way that engineering team productivity is measured by developer experience metrics; the completion-versus-adoption gap that the third failure pattern illustrates — a platform team measuring features shipped rather than adoption at threshold — is structurally identical to an engineering team measuring story points rather than features adopted; a developer experience measurement framework that defines adoption rate and unblocking latency as primary metrics for platform team value provides the same feedback loop to the platform team that the DX measurement model provides to the engineering team; both require a named metric owner, a defined measurement cadence, and a commitment to act on the measurement rather than to explain why the number doesn't reflect the team's actual performance.
• On-call rotation design decision record — the platform team's on-call coverage for shared infrastructure and the product teams' on-call coverage for their services interact directly: the platform team's tier-1 response commitment is, in practice, an on-call commitment for platform-owned infrastructure during business hours; the platform team's on-call design should specify the overlap between the platform on-call rotation and the product team on-call rotations so that a production incident involving a platform-owned capability has a clear escalation path that does not require the on-call product engineer to debug infrastructure they do not own; the adoption forcing function for platform observability tooling specifically requires updating the on-call runbooks to reference the centralized tools, because the incident context is not the right context for a production engineer to learn a new monitoring interface and the platform team's adoption measurement should include "percentage of on-call runbooks referencing platform-managed observability" as a leading indicator of whether the tooling will be used during an incident.
• Open-source extractor — the platform team charter decisions — what the scope boundary is, how the customer model should be designed to balance platform team capacity with product team urgency, what the adoption forcing function looks like for each capability, whether to use a three-tier prioritization model or a rolling queue with SLA bands, how to classify API changes that are additive for most consumers but breaking for one — are exactly the kind of multi-variable decisions that happen in AI chat conversations with a thinking partner who surfaces second-order effects; a VP of Engineering deciding whether to give the platform team ownership of the deployment system without a responsiveness commitment, or whether the adoption target for a centralized logging library should be 8 of 12 services or 12 of 12 services to deliver the cross-service incident investigation value, or how to design a migration deadline policy that is enforced without producing product team resentment — those conversations happen in ChatGPT or Claude; the written output is the platform team charter document, which records the scope list and the SLAs and the metric names but not the reasoning behind the customer model choice, the adoption threshold calibration, or the three-tier prioritization decision; when the charter needs revision because shadow infrastructure is accumulating or the platform team's roadmap investments are not producing measurable productivity improvements, the engineer revising it cannot recover the original rationale from the charter document alone.