Platform Adoption and Developer Support

Six months after launch, a platform team has eleven teams on the platform and forty that are not. The engineering leadership offers to help: from next quarter, using the platform will be a condition of production release. Adoption reaches 100% in two quarters. The platform team’s support queue triples, two teams build a shadow pipeline anyway, and nobody can tell whether the platform is good. (The situation is illustrative; the research and documentation quoted below are not.)

The CNCF platform engineering maturity model distinguishes erratic use, externally encouraged use, adoption driven by perceived value, and participation through contributions. These are ways to examine how and why people use a platform. They do not establish whether a particular mandate was justified or whether the platform works well.

The opening scenario needs evidence about the user experience as well as usage. Required adoption can achieve coverage while leaving difficult tasks unresolved. Voluntary adoption can reveal preference, but only within the choices users actually had. Onboarding, support, migration, and feedback make either arrangement usable and give the platform team evidence for improving it.

What adoption tells you

The model considers both use and motivation. Users may consume shared capabilities without recognizing them as one platform, so define the capability, eligible population, and activity counted before reporting an adoption rate. The table summarizes the model’s adoption aspect; its descriptions are prompts for investigation, not causal diagnoses.

Rung	Why people use it	The tell
Erratic	Local needs and informal discovery	Teams find and assemble capabilities inconsistently
Extrinsic push	Incentives or required use	Investigate discovery, learning support, and unmet requirements
Intrinsic pull	Perceived value relative to available alternatives	Users select internal capabilities for their work
Participatory	Value from using and improving shared capabilities	Users contribute fixes, features, or feedback

A slow start can reflect discovery and transition costs, but it can also reflect poor fit. The model’s growth illustration is not a forecast. DORA also describes a possible J-curve as platforms evolve; neither an initial dip nor a later recovery is inevitable. Agree review points and compare observed outcomes with the reasons given for the investment.

For example, a team might obtain a cloud account through a colleague, reuse another team’s provisioning script, and separately arrange monitoring and secrets. This illustrates the work left to users when the route is fragmented. It does not tell us how many organizations operate this way or whether every informal arrangement needs centralization.

If engineers expect external tools to work better, ask which capability they mean, what they compared, and whether they found the internal option. The answer may expose poor fit, missing discovery, or an earlier experience that no longer describes the service. Assess capabilities and user groups separately: an effective pipeline offering can coexist with an experimental database service.

What a mandate buys, and what it charges you

A requirement can increase use or establish a common control. It does not show that the work became easier. Keep the reason for the requirement separate from evidence about its implementation.

When extending required use, examine the work it creates for users and providers.

• Support demand. Estimate request volume, manual intervention rate, and effort per intervention. New users may need help, but a mandate does not remove their motivation to learn, and support effort need not grow in direct proportion to usage. Compare available capacity with the promised service level.
• Consumption scope. Using one capability does not establish interest in every offering. Partial consumption may be deliberate and useful. Ask whether teams cannot find other capabilities, do not need them, or need an approved alternative.
• Unmet requirements. Identify workloads the supported path does not serve. State how teams request an extension, propose an alternative, or obtain a decision with reasons.
• Participation. Low attendance in a forum can reflect its relevance, timing, workload, or trust. Required platform use alone does not explain whether people will exchange knowledge.

The maturity model illustrates a deployment standard that some teams cannot adapt to their needs. DORA likewise warns about rigid offerings designed without users. These are risks to investigate: an unclear or closed extension route can encourage workarounds, but it does not establish the cause of every duplicated tool.

The CNCF white paper and Bottcher both argue for a platform that offers value beyond a mandate. That is a reason to investigate friction even after usage targets have been reached.

Some controls and implementations can legitimately be mandatory. State their scope and rationale, distinguish recommendations from requirements, and provide a route for unmet needs. An alternative needs the control owner’s validation and agreement on compatibility, cost, and support. Enabling constraints concerns how limits help teams work effectively; it does not require every implementation to be optional. Adjust scope, automation, or staffing when measured demand exceeds capacity while maintaining existing service commitments.

How pull actually starts

A useful first offering solves a defined task for users who can help test it. The maturity model illustrates repeat adoption with a team whose successful database experience encourages it to consider an internal queue service.

The database route in the example is understandable, waiting is short, and backup and monitoring cover the operational needs. Before applying that experience to another workload, assess its onboarding, waiting, and operating requirements. The example illustrates how these conditions support adoption; it provides neither a controlled comparison nor a universal checklist.

Use the example to ask what a particular task requires for success. A team may accept a slower start in exchange for reliability or lower maintenance effort. Another may need a capability the internal offering cannot provide. Observe which conditions matter to the users you intend to serve.

A successful experience can make another internal capability worth investigating. That transfer of confidence still depends on the next capability’s fit and delivery; reputation does not guarantee another adoption.

DORA recommends improving a common user journey through a golden path and learning from it before expanding. Pipelines, databases, and observability are candidates when they address shared needs. Prioritize by demand, reuse, risk, and expected value rather than breadth alone; an uncommon but critical task may deserve attention first.

Bottcher’s comparison includes both consuming a platform capability and building and maintaining an alternative. Make the cost and operating commitments visible over a comparable lifetime. An internal chargeback records cost allocation; it demonstrates preference only when the team had a meaningful, affordable choice. Budget rules and mandatory use can produce the same payment.

DORA warns against building from assumptions without user research or validation. Test the proposed journey with intended users, including workloads that may not fit, before treating a working implementation as a useful product.

Onboarding is the product’s first impression

Onboarding exposes the steps users must complete before they receive value. Missing permissions, unclear instructions, and unexplained failures can turn a small task into a sequence of requests to other teams.

The CNCF white paper recommends documentation, examples, and tools that help users start projects. Bottcher also emphasizes a quick, inexpensive entry path. Include prerequisites, an achievable first task, expected results, and a route for help.

Spotify’s 2020 account connects its golden-path tutorials with new-engineer onboarding and an Engineering Bootcamp. Using the documented route during real work brought feedback about both the instructions and the underlying platform. That is a useful way to test a journey rather than reviewing its prose in isolation.

Observe both new hires and existing staff trying an unfamiliar capability. Choose a first successful task appropriate to their roles; production deployment is unsuitable for people without that responsibility or permission. Define the start and completion events, cohort, prerequisites, and observation period. Separate approval or work-assignment delays from friction in the supported path, and record where people stop. Instrumentation and analysis take time, so budget for them instead of assuming these measures are free.

Make the route findable where users begin work. A service catalog can identify the offering and owner; a developer portal can expose instructions and actions. Check whether intended users actually find and complete the route. A directory’s existence does not establish discovery or successful fulfillment.

Support is a capability, not an interruption

Bottcher includes documentation, consulting, training, and support in the platform offering. Plan these activities alongside software delivery, because they require time and affect whether users can complete their work.

Support helps current users complete their work and turns recurring problems into improvements. Task feedback, clear incident response and assigned adoption work make that responsibility actionable.

• Investigate recurring requests. Sort questions by task, user cohort, and effort. A team may ask twice because a colleague left or a task happens rarely. Newcomers stopping at one step may face missing permissions, a failing account request, an unhelpful backend error, or unclear instructions. Ask what answer they sought, where they looked, and what happens when you reproduce the step. Questions per active team can help, but task volume and experience may be better denominators for a particular service. Google’s SRE treatment of toil distinguishes recurring operational work from novel diagnosis; repeated judgment can also be a redesign candidate. Compare the work avoided with implementation and maintenance cost. Some recurring support can reasonably remain.
• Make task outcomes understandable. DORA associates clear feedback with a positive platform experience. Actionable errors, status, and diagnostics help users resolve supported cases themselves. They complement a route for failures users cannot diagnose or repair.
• Separate advice from incident response. Office hours can serve guidance and teaching within a stated scope. A failed or degraded capability needs its agreed response and escalation route, including severity and service hours. A blocked release may require urgent attention under that contract; it should not silently wait for the next teaching session. Choose coverage from business impact and commitments, and keep those commitments while changing support capacity.
• Assign adoption work. The CNCF white paper includes communication and advocacy among platform responsibilities. Give demonstrations, education, user research, and follow-up an owner and capacity. Developer advocacy connects those activities with the teams using the platform; it does not replace product or engineering decision authority.

A community of practice can distribute knowledge and peer help. Bottcher includes an internal user community among a platform’s useful attributes. Its participants still spend time answering, learning, and maintaining shared material. In an illustrative channel with two hundred members and four regular answerers, membership growth alone says little about capacity. Budget for facilitation and curation, and measure central support effort separately from organization-wide effort. Documentation and automation can also reduce repeated handling. Define when a question leaves peer discussion and enters the provider’s support path.

Migrating what already exists

Existing services bring state, dependencies, and commitments that a new project does not. An adoption plan must account for that work rather than counting only newly created services.

The CNCF white paper suggests starting with engaged application teams whose feedback helps improve the experience and whose later recommendations can help other users. Include representative constraints in the pilot; enthusiastic early users may not expose every migration problem.

The following migration practices are recommendations for making that transition observable and fundable.

• Learn with service owners. Work alongside initial teams where useful, and combine that experience with interviews, observation, and a dependency inventory. Identify undocumented steps, target readiness, and the people authorized to execute and approve changes.
• State the expected benefit and required deadline. Compare total effort, risk, reliability, and support over the relevant lifetime. A security or end-of-support migration can be justified even if the new path is no easier initially. Explain that reason and the remaining user burden.
• Plan the transition and recovery. Avoid unnecessary repeated moves, but allow an intermediate path when security deadlines or staged delivery justify it. Record why it is needed and its exit condition. Define compatibility checks, validation of state and dependent services, rollback or another recovery route, and completion evidence. Provide notice, overlap where feasible, and automation for repeatable steps. Planned internal changes as well as external changes can be necessary.
• Fund and schedule the work. Agree which team implements, approves, validates, and operates each part. Reserve capacity across affected backlogs and resolve conflicts against other priorities. Track unfinished migrations and exceptions; a published guide does not allocate the time to follow it.

Conformance can make a service eligible for shared upgrade automation, but eligibility also depends on versions, supported combinations, state, dependencies, permissions, and recovery conditions. Some changes still require service-owner validation or action. Explain the support and lifecycle contract users receive, including mandatory updates and approved alternatives.

Feedback people believe in

Collecting feedback creates a responsibility to examine it and explain decisions. Users cannot tell whether their evidence mattered if the decision remains invisible.

The maturity model describes declining participation when users do not see how feedback was considered. That is a risk rather than a guaranteed response to one unanswered survey. Keep core questions stable where comparison matters, while adding clearly distinguished exploratory questions as needs change.

Its feedback example reserves 20% of a team’s time for user-defined features and involves requesters during design and adoption. The percentage is an illustration, not a recommended quota for every platform. Set capacity against existing commitments and the value of the work.

Make the loop visible: record the request and evidence, review it, communicate a decision and reasons, and follow up on the outcome. Acceptance may lead to design collaboration and a release; a reasoned rejection, deferral, or explanation of an existing capability can also close the loop. State what would trigger reconsideration. Users need evidence of consideration, not a promise that every request will ship.

Choose interviews, surveys, issue tracking, observation, or workshops for the question being investigated. Each has collection and analysis costs, and excessive requests can exhaust participants. DORA recommends product management focused on developer experience. Treating the platform as a product includes deciding priorities and explaining tradeoffs, as well as gathering opinions.

Contribution and the remaining dependencies

The maturity model’s participatory level describes users contributing improvements and new capabilities. A documented contribution route lets user teams propose work that central implementers cannot currently prioritize.

Its alternative-backup example shows a team implementing a low-reuse requirement within the platform framework. The offering can begin as alpha and meet agreed criteria before promotion. This is a possible route around the central implementation queue; design approval, review, release, and support still need capacity.

Inner source applies open-source collaboration practices within an organization. The InnerSource Commons introduces it through a consumer team contributing a change to a host team’s project. It addresses backlog coupling by changing who can implement the work, while preserving an agreed acceptance process.

Check the guest and host separately. The guest needs people, codebase familiarity, and time to implement; the host needs design, review, security, release, and support capacity. Review can cost more than implementation for a difficult change. Contribution is an additional delivery option, not proof that a bottleneck has disappeared. Compare total effort and elapsed time on both sides.

Agree the approach before implementation and allocate review time explicitly. Separate acceptance from operation: before core promotion, name the capability provider, support scope, lifecycle, change policy, retirement conditions, and migration responsibilities. The provider may be another team. Promotion establishes those commitments; it does not promise operation forever.

DORA recommends extensibility so specialist teams can contribute through a defined model. This can distribute implementation while maintaining shared interfaces and controls. It still requires someone to make acceptance and operating decisions.

Maintain build and test instructions, versioning, and a route for discussing changes. Record decisions asynchronously so contributors can proceed across schedules; a design meeting or pairing session may still resolve uncertainty more effectively. Early conversations with product teams can reveal both existing capabilities and new requirements.

If adoption has stalled

Use these questions to choose an investigation. Their priority and effort depend on the service and the evidence already available.

• Can intended users find the route? Observe a small sample attempting discovery, then broaden the sample if needed. Difficulty is evidence about those journeys, not proof that resistance or poor fit is absent.
• Can they complete the supported task? Examine prerequisites, waiting, failures, and operational readiness. Choose completion criteria for that task rather than treating the model’s database example as a universal checklist.
• What makes the available alternatives attractive? Compare setup, operation, constraints, switching cost, and required controls. Investigate reasons for use even when the internal route is slower.
• How are unusual requirements handled? Trace a request through extension, exception, alternative, or refusal, including decision authority and support responsibility.
• Did users receive a decision about their feedback? Check whether the reason, subsequent result, or reconsideration condition reached them. Shipping is one possible outcome.

The maturity model treats levels as contextual and calls attention to their investment costs. A small organization may not need a broad contribution program, but a useful specialist contribution can still justify one. Choose the arrangement from actual demand, risk, and available capacity rather than a service-count threshold.

In the opening example, the mandate increased reported coverage. The support queue and workarounds call for investigation into task success, unmet requirements, and capacity. Improving a supported journey, learning with initial users, and explaining decisions can help whether use is optional or required.

Report adoption with its eligible population, counted activity, observation period, and freedom of choice. Trials are different from sustained use. Voluntary choices can reflect budgets, vendor withdrawal, approval rules, or switching costs as well as platform quality. Required-use figures still reveal coverage and utilization; combine them with task success, elapsed time, reliability, support effort, and user feedback to assess the experience.

References

• CNCF — Platform Engineering Maturity Model
• CNCF TAG App Delivery — Platforms White Paper
• Evan Bottcher — What I Talk About When I Talk About Platforms (2018)
• Gary Niemen, Spotify Engineering — How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (2020)
• DORA — Platform engineering
• InnerSource Commons — Introduction to InnerSource
• Google SRE — Eliminating Toil