Skip to main content

Fast flow

What the platform changed​

The platform engineering team produced the largest measurable improvement in the Tier-1 bank's DevSecOps transformation.

At the outset, every delivery team built and maintained its own CI/CD pipeline, its own deployment scripts, its own monitoring stack, and its own approach to security scanning. Teams spent thirty to forty percent of their capacity on undifferentiated infrastructure work, solving the same problems differently and often poorly. Cognitive load was crushing. Teams that should have been building differentiated banking products were debugging Kubernetes networking, writing custom Terraform modules from scratch, and fighting with certificate management. Matthew Skelton and Manuel Pais describe this failure mode in "Team Topologies" (2019): when every team must be an expert in every layer of the stack, cognitive load exceeds capacity, flow collapses, and delivery performance degrades. The solution is to organize teams around the flow of value and build platform capabilities that absorb the complexity that would otherwise be distributed across every team.

A platform engineering team was formed with a simple mission: make it straightforward for any delivery team to build, test, secure, deploy, and operate their services. The platform team did not write the applications. They built the golden paths, the shared infrastructure, the self-service capabilities, and the observability stack that every team consumed. Within a year, delivery teams reduced their infrastructure overhead from thirty-five percent of capacity to under ten percent, and the freed capacity went directly into product development and security improvement. Deployment frequency across the organization tripled. Lead time dropped by seventy percent. Don Reinertsen's "The Principles of Product Development Flow" (2009) establishes that flow efficiency is determined by the ratio of value-adding time to total time. Platform engineering is the discipline of minimizing the non-value-adding time.

Components​

Fast flow depends on continuous delivery (automating the build, test, and deployment process for frequent and reliable releases), working in small batches, streamlined change approval, flexible infrastructure, team structures organized around the flow of value (Team Topologies), and platform engineering: internal platforms that abstract away complexity and provide self-service capabilities to stream-aligned teams.

Team Topologies and flow​

Skelton and Pais identify four team types that enable fast flow.

Stream-aligned teams​

Stream-aligned teams are organized around a single valuable stream of work: a product, a service, a set of features, or a user journey. They have end to end ownership and can deliver value independently without waiting for other teams.

At the bank, the organization moved from component-based teams (a "database team," a "middleware team," a "frontend team") to stream-aligned teams organized around banking capabilities: payments, account management, lending, fraud detection. Each stream-aligned team owned their services end to end, from code to production. This reorganization eliminated the handoff queues that had been the largest source of lead time waste. A change that previously required coordination across four teams now required coordination within a single team.

Platform teams​

Platform teams build and maintain the internal platform that stream-aligned teams consume. The platform reduces cognitive load by abstracting away infrastructure complexity and providing self-service capabilities.

The platform built at the bank included golden path pipeline templates (pre-configured CI/CD pipelines with security scanning, testing, and deployment built in); self-service infrastructure (Terraform modules and Kubernetes namespaces that teams could provision through a portal without filing tickets); an observability stack (centralized logging, metrics, tracing, and alerting that teams adopted by adding a single configuration file); secret management (HashiCorp Vault integration consumed through a simple API, with no Vault infrastructure for teams to manage); and compliance automation (policy-as-code enforcement and automated evidence generation embedded in the platform).

The platform team treated stream-aligned teams as their customers. They ran product discovery, collected feedback, measured adoption, and iterated on their offerings. The platform was not mandated. Teams adopted it because it was easier and better than the alternative.

Gartner projects that by 2026, 80% of software engineering organisations will establish platform teams. Some platform teams now provide agent golden paths: approved routes for deploying and operating agents with the same controls used for other production software. The bank's platform investment can support those workflows as well as conventional delivery.

The June 2026 agentic software research makes this platform role more specific. An agent golden path must provide approved tools, repository-aware retrieval, memory provenance, trajectory logging, bounded reasoning budgets, model routing, and AI-serving SLOs by default. Without that platform layer, every stream-aligned team has to rediscover how to keep agents useful, auditable, and safe. That is cognitive load, and cognitive load is the enemy of flow.

Concretely, this site's recommended agent golden path is Claude Code: a shared CLAUDE.md for conventions, hooks for the deterministic controls (lint, format, secret scan) rather than relying on every team to remember them, permission policies and sandboxing for the approved-tools boundary, and plugins so a working configuration is installable rather than rediscovered per team (see AI-powered SDLC with Claude Code). A platform team standing up an agent golden path from scratch is redoing work Anthropic and AWS Labs' AI-DLC v2 have already done well.

Enabling teams​

Enabling teams help stream-aligned teams acquire new capabilities. They do not build the software for the stream-aligned teams; they coach, teach, and facilitate skill development.

At the bank, the security champions program functioned as a distributed enabling capability. Security engineers rotated through stream-aligned teams for two-week engagements, pairing with developers on threat modeling, secure coding practices, and security test development. After the engagement, the stream-aligned team could sustain the practice independently. This is the enabling team pattern from Team Topologies applied to security.

Complicated-subsystem teams​

Complicated-subsystem teams own components that require deep specialist knowledge, such as cryptographic services, regulatory calculation engines, or machine learning model serving infrastructure.

At the bank, the cryptographic services team was a complicated-subsystem team. They maintained the HSM integration, key management infrastructure, and encryption libraries that every stream-aligned team consumed. Stream-aligned teams did not need to understand key rotation or FIPS 140-2 compliance; they consumed the cryptographic services through well-documented APIs provided by the specialist team.

Practices and examples​

Continuous delivery​

Continuous delivery means automating the build, test, and deployment process so that releases are frequent and reliable. The core practices are automated builds (tools like Jenkins or GitHub Actions), automated tests that verify code changes, frequent deployments to reduce integration risk, and multi-stage deployment pipelines with automatic quality and security gates.

Humble and Farley's "Continuous Delivery" (2010) defines the deployment pipeline as the central artifact of continuous delivery: an automated manifestation of your process for getting software from version control into the hands of your users. Every organization has a process for this. The question is whether that process is automated, repeatable, and auditable, or manual, error-prone, and opaque.

Example: Automated builds​

At the bank, the golden path pipeline executed the following stages automatically on every pull request:

  1. Compile and build: source code compilation and artifact generation.
  2. Unit tests: execution of the team's unit test suite with coverage enforcement.
  3. SAST scan: static application security testing against OWASP Top 10 vulnerability classes.
  4. SCA scan: software composition analysis for dependency vulnerabilities.
  5. Container image build: Docker image construction from hardened base images.
  6. Container scan: image scanning against CIS Benchmarks.
  7. Integration tests: execution against a transient test environment.
  8. Policy check: Open Policy Agent evaluation of deployment policies.

The entire pipeline completed in under twelve minutes for most services. Teams that built their own pipelines typically took thirty to forty-five minutes and missed several of these stages.

Working in small batches​

Working in small batches means breaking work into smaller units to reduce risk and improve flow: developing features incrementally, committing frequently to catch issues early, and integrating changes often so they work together.

Reinertsen's "The Principles of Product Development Flow" provides the mathematical foundation for why small batches outperform large batches. Transaction costs in software delivery (build time, test time, deployment time) have decreased dramatically due to automation, while holding costs (the cost of unreleased work, integration risk, and delayed feedback) remain high. When transaction costs are low and holding costs are high, the economically optimal batch size is small. This is arithmetic, not a philosophical preference.

Example: Incremental development​

At the bank, teams were coached to break down features into increments that could be merged and deployed independently within one to three days. A new payment feature that might have been specified as a single three-month project was decomposed into dozens of independently deployable increments: API endpoint scaffolding, database schema migration, business logic for each payment type, validation rules, error handling, monitoring instrumentation, and feature toggle configuration. Each increment delivered value (or at least reduced risk) independently, and the full feature was assembled incrementally in production behind a feature toggle.

Streamlining change approval​

Streamlining change approval means building change management processes that minimize delays: automated approval workflows, peer reviews for code quality, continuous feedback to developers, and pre-approval for change types that follow established, automated processes.

Example: Automated approval workflows​

At the bank, the change approval process was the single largest source of lead time waste before the transformation. Changes required manual approval from a change advisory board that met weekly. If you missed the meeting, you waited another week. Emergency changes required phone calls to multiple approvers. This was replaced with the tiered model described in the software delivery section: standard changes (golden path, all checks passing) were pre-approved and deployed automatically, while normal and emergency changes followed streamlined, asynchronous approval workflows. This reduced change approval lead time from an average of five days to under two hours.

Flexible infrastructure​

Flexible infrastructure is infrastructure that can be provisioned and scaled to meet changing demands: infrastructure as code for consistency and repeatability, containers for consistent packaging across environments, the ability to scale with workload, and self-service provisioning so teams do not file tickets or wait for a central team.

Example: Infrastructure as code (IaC)​

Self-service infrastructure removed a major delay at the bank. Before the platform, a new environment required a ticket and a wait of two to four weeks, and the result did not always match the specification. The portal reduced provisioning of a production Kubernetes namespace to under five minutes, with networking, logging, monitoring, secrets, and security policies included. Average onboarding time for a new microservice fell from six weeks to two days.

Reducing cognitive load​

Skelton and Pais argue that cognitive load is the primary constraint on team effectiveness. When teams must understand too many things (the domain they serve, the programming languages they use, the infrastructure they deploy to, the security controls they must implement, the compliance evidence they must generate) they slow down, make mistakes, and burn out.

The platform engineering approach directly addresses cognitive load by absorbing complexity into the platform. At the bank, cognitive load was measured through team surveys and tracked as a leading indicator of delivery performance. Teams with high cognitive load scores had lower deployment frequency, higher change failure rates, and higher attrition. As platform adoption increased, cognitive load scores decreased and delivery metrics improved in lockstep.

The three types of cognitive load from Skelton and Pais map to specific platform investments. Intrinsic cognitive load (the complexity inherent in the problem domain) cannot be reduced by the platform, but it can be managed through team boundaries that limit the scope of the domain each team owns. Extraneous cognitive load (the complexity of the environment and tools) is directly reduced by platform capabilities that abstract away infrastructure, security, and compliance complexity. Germane cognitive load (the complexity of learning and improving) is supported by enabling teams, documentation, and communities of practice.

The goal of platform engineering is to minimize extraneous cognitive load so that teams can devote maximum capacity to intrinsic and germane cognitive load, the work that actually matters.

Measured benefits​

  • Reduced lead time for changes
  • Increased deployment frequency
  • Improved ability to respond to customer needs
  • Reduced cognitive load on stream-aligned teams
  • Higher developer satisfaction and retention
  • More consistent security and compliance posture across the organization

Faster response to customer needs​

At the bank, fast flow translated directly to competitive advantage. When a regulatory change required all payment services to implement a new validation rule within thirty days, teams on the golden path delivered the change in under a week. Teams that had not adopted the platform required the full thirty days. The difference was flow, not skill. Teams with fast flow had low lead times, automated testing, and deployment confidence. They could respond to urgent requirements quickly because their delivery infrastructure was not a bottleneck.

Tools for flow​

  • Jenkins: an open-source automation server for continuous integration and continuous delivery (CI/CD).
  • GitHub Actions: a CI/CD tool that lets you automate workflows directly from your GitHub repository.
  • Terraform: an open-source tool for defining and provisioning infrastructure as code.
  • Ansible: an open-source automation tool for managing and provisioning infrastructure.
  • Docker: a platform for developing, shipping, and running applications in containers.
  • Kubernetes: an open-source platform for automating the deployment, scaling, and management of containerized applications.
  • Backstage: an open-source developer portal for building internal developer platforms (originally created by Spotify).
  • Crossplane: a Kubernetes-native platform for building and consuming infrastructure through declarative APIs.
  • Argo CD: a declarative, GitOps continuous delivery tool for Kubernetes.

Flow metrics​

Beyond DORA metrics, Reinertsen's product development flow framework provides additional metrics for measuring and optimizing flow:

  • Flow efficiency is the ratio of active work time to total lead time. In most organizations, flow efficiency is below fifteen percent, meaning that work items spend over eighty-five percent of their time waiting in queues. At the bank, flow efficiency improved from twelve percent to thirty-eight percent through queue management, work-in-progress limits, and platform-provided automation.
  • Work in Progress (WIP) is the number of items actively being worked on. Reinertsen demonstrates that WIP is the primary driver of lead time (per Little's Law), so reducing WIP reduces lead time proportionally. WIP limits were implemented at the team level and the organizational level.
  • Queue length is the number of items waiting in queues between stages. Long queues indicate bottlenecks. Queue lengths were visualized in real time dashboards and used to trigger process improvements.
  • Cycle time distribution: rather than tracking average cycle time, which masks variability, the team tracked the full distribution and focused on reducing the tail, the items that took disproportionately long to deliver.

References​

  1. Skelton, M. and Pais, M. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.

  2. Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

  3. Humble, J. and Farley, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.

  4. Forsgren, N., Humble, J., and Kim, G. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018.

  5. Kim, G., Humble, J., Debois, P., and Willis, J. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

  6. Kim, G., Behr, K., and Spafford, G. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013.

  7. DORA State of DevOps Report 2024. Google Cloud, 2024. Available at: https://dora.dev/research/2024/dora-report/

  8. Little, J. D. C. "A Proof for the Queuing Formula: L = lambda W." Operations Research, Vol. 9, No. 3, 1961, pp. 383-387. (Mathematical foundation for the relationship between WIP and lead time.)

  9. Gartner. "Platform Engineering Predictions for 2026." Referenced in platformengineering.org. Available at: https://platformengineering.org/blog/10-platform-engineering-predictions-for-2026

  10. arXiv. (2026). "Agentic Software: How AI Agents Are Restructuring the Software Paradigm." arXiv:2606.05608. https://arxiv.org/abs/2606.05608

  11. arXiv. (2026). "CORE-Bench." arXiv:2606.11864. https://arxiv.org/abs/2606.11864