A company is a network of services, each consuming demand from upstream and generating output for downstream consumers. An engineering squad consumes design work and ships features. A platform team consumes infrastructure requests and provides stable environments. The route a work item takes through this network depends on its type — a production incident escalates directly; a new feature works its way through several services.
The constraint is whichever service most consistently receives more demand than it can clear. That service sets the effective throughput of the whole network, regardless of how fast the teams around it are moving.
STATIK is a structured process for understanding and designing a single service within that network. It starts with the customer: who uses the service and what they need. From there it works inward to the board design. Click through the eight steps below using a Platform Engineering team as a worked example.
Takeaways
- — Start with fitness for purpose. The customer’s definition of good service sets the target; the team’s assumptions about it are not a substitute.
- — Understand demand before capability. The types and rates of work arriving shape everything downstream. Analysing capability first risks designing a system optimised for the wrong workload.
- — Classes of service make commitments explicit. Differentiating work by urgency and risk lets the team make specific, negotiable promises rather than treating every request as equally urgent.
- — The board is the last thing you design. STATIK works from purpose to demand to flow to system; the kanban board emerges at the end of that process.