Platform Engineering Is Service to Others

What does it mean to build a platform for other engineers?

Platform engineering is the practice of building internal tools and abstractions that allow product teams to ship software without needing to understand the full complexity of the underlying infrastructure.

The Stoics had a word for duty: kathēkon. It translates roughly as “appropriate action,” the thing that is fitting for a person to do given their role and circumstances. For a parent, the kathēkon is to raise children with care. For a citizen, it is to contribute to the common good. For a platform engineer, it is to make other engineers’ work easier, faster, and safer.

This framing matters because it distinguishes platform engineering from empire building. I have seen platform teams that optimized for their own technical elegance, building beautiful internal tools that nobody used because they did not solve the problems product teams actually had. The kathēkon of platform engineering is not to build impressive infrastructure. It is to reduce the cognitive burden on the people who depend on you.

Why is cognitive load the right metric for platform success?

Cognitive load determines how much of a developer’s mental bandwidth goes to solving business problems versus fighting infrastructure, and the best platforms maximize the former by minimizing the latter.

Team Topologies, the framework by Skelton and Pais, identifies 3 types of cognitive load: intrinsic (the inherent complexity of the problem domain), extraneous (the unnecessary complexity imposed by tools and processes), and germane (the productive effort of learning and problem-solving). Platform teams exist to eliminate extraneous cognitive load.

Consider what a developer must know to deploy a new service at a typical enterprise without a platform team: container configuration, Kubernetes manifests, CI/CD pipeline syntax, secrets management, DNS configuration, TLS certificate provisioning, logging setup, metrics instrumentation, alerting rules, and IAM policies. That is 10 distinct knowledge domains before writing a single line of business logic. At an organization I consulted with in 2024, a senior engineer estimated that 34% of their working time went to infrastructure tasks unrelated to their product domain.

A well-designed platform reduces that list to: write code, push to main, and let the platform handle the rest. Spotify’s Backstage, for example, provides a single interface for creating new services from templates, with all infrastructure concerns pre-configured. Their internal data shows that the median time from “I want a new service” to “it’s running in production” dropped from 3 weeks to 4 hours after Backstage adoption.

How does a platform team practice duty without becoming a bottleneck?

The platform must be self-service. If product teams need to file a ticket and wait for the platform team to provision their infrastructure, you have not built a platform. You have built a ticket queue with extra steps.

The distinction between a platform and a shared services team is autonomy. A shared services team does things for you. A platform team gives you the tools to do things for yourself. The Stoic concept of kathēkon is not about doing everything for others. It is about enabling others to act appropriately within their own domain.

I designed a platform for a logistics company with 120 engineers split across 8 product teams. The platform provided 4 core capabilities as self-service: service creation from templates (with observability, CI/CD, and security pre-configured), database provisioning (PostgreSQL or Redis with standardized backup policies), feature flag management, and environment promotion (staging to production with automated canary analysis). Each capability was exposed through a CLI tool and a web interface. No tickets. No waiting.

The result after 9 months: the platform team of 6 engineers supported 8 product teams totaling 114 engineers. New service creation dropped from 12 days average to 45 minutes. Production incidents related to misconfigured infrastructure decreased by 73%. Developer satisfaction, measured by quarterly surveys on a 1 to 10 scale, rose from 5.8 to 8.4.

What are the tradeoffs of platform engineering?

Platforms trade flexibility for consistency, and this tradeoff is only worth making when the consistency benefits outweigh the innovation costs.

• Golden paths constrain choice: When you provide a paved road for deploying services, teams that need something different must either fight the platform or go around it. I build escape hatches into every platform: documented procedures for deviating from the golden path when justified. Approximately 15% of teams need these escape hatches for legitimate technical reasons.
• Platform teams need product thinking: The platform is an internal product. It needs user research (talking to product teams about their pain points), roadmap prioritization (fixing the highest-impact friction first), and usage analytics (measuring adoption rates and drop-off points). Platform teams staffed entirely with infrastructure engineers and no product sensibility build technically excellent tools that nobody adopts.
• Maintenance is ongoing: A platform is not a project with a completion date. It is a living service that must evolve with the organization. I budget 40% of platform team capacity for maintenance and 60% for new capabilities. Teams that allocate less than 30% to maintenance see platform reliability degrade within 6 months.
• Premature platforming is wasteful: If your organization has fewer than 4 product teams, the overhead of a dedicated platform team likely exceeds its benefits. The threshold, based on my observations across 14 organizations, is approximately 30 to 40 total engineers. Below that, shared conventions and documentation serve the same purpose at lower cost.

What makes the philosophy of service relevant to infrastructure work?

Platform engineering is one of the few engineering roles where your primary customer is another engineer, and this inverts the usual relationship between builder and user in a way that demands genuine empathy.

Epictetus taught that the quality of your life is determined by the quality of your attention to the things within your control. For a platform engineer, the things within your control are the tools, templates, documentation, and golden paths you provide. The things outside your control are whether product teams adopt them, whether leadership funds the work, and whether the organization values internal infrastructure investment.

The Stoic response is to focus entirely on the quality of what you build and the clarity with which you communicate it. I have found that the single highest-impact investment a platform team can make is documentation. Not the platform itself, but the documentation of the platform. A well-documented platform with average tooling outperforms a brilliantly engineered platform with poor documentation every time. The ratio is not even close. In one A/B test I ran across 2 product teams given access to the same platform features with different documentation quality, the well-documented team adopted 4 new platform capabilities in a quarter versus 1 for the poorly documented team.

The philosopher serves the polis by making wisdom accessible. The platform engineer serves the organization by making infrastructure invisible. Both practices require the same fundamental orientation: your work exists not for its own sake but for the benefit of others who should never need to understand how hard it was to build.