Pattern: Service Unit

Specs Lab
,
1

Name

Service Unit

Purpose

To provide reusable services, infrastructure, and tools that other units can rely on, reducing duplication of effort and enabling Flow Units and Domain Units to focus on delivering value.

Also Known As

  • Platform Team (Team Topologies)

  • Platform Crew (unFIX model)

  • Role or Circle (Holacracy)

Introduction

Not every unit should reinvent infrastructure, pipelines, or shared services. By consolidating these functions into Service Units, organizations empower Flow Units to concentrate on customer-facing work while benefiting from stable, reusable services. Service Units treat other units as their customers, offering “platforms as products” designed to improve speed, reliability, and consistency across the organization.

Context

As organizations scale, each Flow Unit building its own infrastructure leads to waste, inconsistency, and reliability issues. On the other hand, central IT or “command-and-control” shared services often stifle agility. The Service Unit pattern balances efficiency with autonomy by providing shared services with a product mindset.

Forces

  • Efficiency vs. autonomy: centralizing services drives reuse but risks creating bottlenecks.

  • Cognitive load: Flow Units cannot sustain deep expertise in infrastructure while focusing on value delivery.

  • Adoption vs. mandate: units should want to consume services, not be forced into them.

  • Standardization vs. flexibility: platforms must balance consistency with unit-specific needs.

  • Continuous evolution: services must improve alongside the needs of consuming units.

Problem

Without shared services, Flow Units duplicate effort, create inconsistencies, and slow down delivery. With overbearing shared services, units lose autonomy, become dependent on gatekeepers, and encounter bottlenecks. The challenge: How can teams benefit from shared services without sacrificing autonomy and speed?

Solution

Create Service Units that provide reusable services and infrastructure to other units, designed and delivered as products. These units focus on enabling self-service and reducing cognitive load for Flow Units. They succeed not by mandating adoption, but by offering reliable, easy-to-use services that units choose to adopt.

Rationale

Service Units ensure organizational efficiency while preserving the autonomy of Flow Units. By thinking in terms of products, they ensure their offerings evolve with the needs of their internal customers, fostering adoption and alignment instead of resistance.

Visuals

VSM - Holon
VSM - Holon2000×1414 139 KB

Participants

  • Service Unit members: infrastructure engineers, SREs, platform developers, API owners.

  • Consuming units: Flow Units, Domain Units.

  • Governance Unit: ensures investment and alignment with broader strategy.

  • AI agents/tools: increasingly embedded in monitoring, automation, and scaling.

Implementation

  • Define services as products, with clear APIs, documentation, and support.

  • Use product management practices (roadmaps, metrics, customer feedback).

  • Provide self-service capabilities to minimize bottlenecks.

  • Foster a “service mindset” over command-and-control.

  • Measure success through adoption, reliability, and developer experience.

Variants

  • Infrastructure Service Team: provides cloud, CI/CD, observability, networking.

  • Business Service Team: provides shared business functions (e.g., HR, finance APIs).

  • AI/ML Service Team: offers data pipelines, training environments, and MLops platforms.

  • Shared Services / System Teams: SAFe

  • Infrastructure Squads: Spotify model

Consequences

Positive:

  • Increased efficiency through reuse.

  • Reduced cognitive load for Flow Units.

  • Higher quality and consistency across systems.

Negative / Risks:

  • Risk of central bottlenecks if self-service is weak.

  • Teams may resist adoption if services don’t meet their needs.

  • Over-standardization can limit flexibility.

Related Patterns

  • Flow Unit: consumes services while focusing on customer value.

  • Domain Unit: may consume specialized services.

  • Support Unit: helps teams adopt Service Unit offerings effectively.

  • Orchestration Unit: may integrate Service Unit contributions into wider prioritization. (The Orchestration Unit and Service Unit both sit at VSM level 3. However, whereas the Service Unit exercises implicit control through delegation from Flow Units and Domain Units, a Orchestration Unit exercises explicit control, often on behalf of a Governance Unit.)

Classification

  • System: Primarily VSM System 3 (Optimization & Control), with links to System 1.

  • Core Pattern: Optional – only when shared services meaningfully reduce cognitive load.

Scope

Service Units exist fractally: as infrastructure teams inside a business unit, enterprise-wide platform organizations, or ecosystem-level providers. They scale with organizational needs but must always be justified by actual demand and adoption.

References

TO DO

(This document is offered with a Creative Commons 0 (CC0) license.)