• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Platform capabilities include clear boundaries of responsibility

Purpose and Strategic Importance

This standard ensures each platform capability defines clear boundaries of responsibility—what it owns, how it’s used, and where teams maintain control. It streamlines collaboration and fosters autonomy.

Aligned to our "Empower Teams to Self-Serve" policy, this standard avoids confusion, reduces misaligned dependencies, and accelerates delivery. Without it, overlaps and gaps in accountability slow progress and create unnecessary friction.

Strategic Impact

  • Clearer collaboration between platform and product teams
  • More efficient onboarding and use of platform capabilities
  • Faster resolution of issues and fewer unnecessary escalations
  • Greater team autonomy, with confidence in what is supported and what is owned
  • Strengthened platform-as-a-product mindset

Risks of Not Having This Standard

  • Unclear ownership leading to support gaps and misaligned dependencies
  • Repeated rework or blocked deliveries due to misunderstood responsibilities
  • Friction between platform and consuming teams
  • Inability to scale the platform effectively as demand grows

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Platform teams are reactive and siloed.
Consumers are uncertain who to ask or what is owned.
Process & Governance No ownership boundaries exist.
Support and expectations vary widely between capabilities.
Technology & Tools Interfaces and contracts are undocumented or unclear.
Adoption relies on trial and error.
Measurement & Metrics No measurement of adoption friction or ownership confusion.

Level 2 – Managed

Category Description
People & Culture Platform teams begin describing scope in conversations.
Boundaries are inconsistently understood across teams.
Process & Governance Some capabilities have partial documentation or “how to” guides.
Support is reliant on known individuals.
Technology & Tools Usage is informally guided by examples or Slack messages.
Platform catalogue is emerging but incomplete.
Measurement & Metrics Support requests begin to be tracked manually.
Patterns of friction or confusion are visible but not analysed.

Level 3 – Defined

Category Description
People & Culture Platform and product teams co-create and share responsibility boundaries.
Ownership is clearly defined and understood.
Process & Governance Capabilities come with published documentation, support expectations, and onboarding guidance.
Teams can self-serve confidently.
Technology & Tools A platform catalogue or portal clearly describes each capability, its APIs, and team responsibilities.
Measurement & Metrics Platform usage, support requests, and onboarding feedback are measured to refine boundaries.

Level 4 – Quantitatively Managed

Category Description
People & Culture Boundary feedback is part of platform retrospectives.
Teams use telemetry to surface gaps in understanding or support.
Process & Governance Boundaries are reviewed regularly with consumers and evolve through iteration.
Platform roadmaps reflect consumer pain points.
Technology & Tools API documentation, SLAs, and service maturity indicators are visible and versioned.
Self-service usage patterns are tracked.
Measurement & Metrics Platform discoverability, time-to-onboard, and volume of support escalations are tracked and improved.

Level 5 – Optimising

Category Description
People & Culture Platform teams behave as product teams.
Consumers are treated as users whose feedback drives platform evolution.
Process & Governance Responsibility boundaries adapt dynamically to support evolving team needs.
Clear feedback loops reinforce continuous improvement.
Technology & Tools Context-aware service documentation and intelligent onboarding guidance are embedded into developer tools.
Measurement & Metrics Metrics drive prioritisation and investment in capability clarity.
Gaps in responsibility are proactively resolved before becoming friction.

Key Measures

  • % of platform capabilities with documented boundaries and SLAs
  • Time to onboard or integrate with platform capabilities
  • Number of support escalations due to unclear responsibilities
  • Platform satisfaction or Net Promoter Score (NPS) from consuming teams
  • Frequency of boundary-related issues raised in retros or tickets
Associated Policies
  • Empower Teams to Self-Serve
Associated Practices
  • Domain-Driven Design (DDD)
  • Modular Monoliths
  • GraphQL-first APIs
  • CQRS (Command Query Responsibility Segregation)
  • Strangler Fig Pattern
  • Hexagonal (Ports & Adapters) Architecture
  • Event-Driven Architecture (EDA)
  • Microservices Architecture

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering