• Home
  • BVSSH
  • Engineering Enablement
  • 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

  • Improved consistency and quality across teams
  • Reduced operational friction and delivery risks
  • Stronger ownership and autonomy in technical decision-making
  • More inclusive and sustainable engineering culture

Risks of Not Having This Standard

  • Slower time-to-value and increased rework
  • Accumulation of inconsistency and process debt
  • Reduced trust in engineering data, systems, or ownership
  • Loss of agility in the face of change or failure

CMMI Maturity Model

  • Level 1 – Initial: Platform responsibilities are unclear or undocumented. Teams are uncertain about what is owned, supported, or expected, resulting in confusion and delivery delays.

  • Level 2 – Managed: Some platform teams begin defining boundaries, but definitions are inconsistent or shared informally. Consumers rely on tribal knowledge or direct communication to navigate responsibilities.

  • Level 3 – Defined: Platform capabilities include clear, documented ownership boundaries, interfaces, and support models. Teams understand what the platform provides and what they’re responsible for.

  • Level 4 – Quantitatively Managed: Boundaries are governed through feedback loops and usage telemetry. Friction, handoffs, and support queries are tracked to improve the clarity and usability of platform capabilities.

  • Level 5 – Optimising: Platform boundaries evolve based on consumer feedback, delivery insights, and service maturity. The platform acts as a product, enabling seamless self-service and driving systemic delivery improvements.


Key Measures

  • Adoption rates and coverage across teams
  • Impact on delivery metrics, quality, or team health
  • Evidence of ownership, governance, or learning loops
Associated Policies
  • Empower Teams to Self-Serve
Associated Practices
  • CQRS (Command Query Responsibility Segregation)
  • Event-Driven Architecture (EDA)
  • GraphQL-first APIs
  • Hexagonal (Ports & Adapters) Architecture
  • Microservices Architecture
  • Modular Monoliths
  • Strangler Fig Pattern
  • Domain-Driven Design (DDD)

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

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