Three Pillars of Platform Engineering: A Virtuous Cycle

A lot of internal platform conversations end up framed as a trade-off: do you want a platform that's reliable or one that's easy to use? Pratik Agarwal, a senior engineer at Figma, argues in this InfoQ article that this is a false dichotomy. Reliability and ergonomics aren't opposites — they actively reinforce each other. When all three of his proposed pillars (automated reliability, developer ergonomics, and operator ergonomics) are healthy, you get a virtuous cycle. When any one of them rots, you get a doom loop where everyone burns out and the platform regresses.

The Problem: Platforms That Hit a Wall

Modern platform engineering centers on the Internal Developer Platform (IDP) — an opinionated layer that hides cloud and infrastructure complexity so product teams can focus on business value. Done well, this is transformative. Done poorly, it tends to fail in one of two predictable ways:

• Leaky abstraction. The platform pretends complexity is gone, but developers still need to understand the underlying systems to debug or extend their services. The "abstraction" mostly adds a translation layer to learn.
• Overly rigid. The platform is so prescriptive that legitimate use cases get blocked, and the very speed it was supposed to enable disappears.

Both failure modes share a root cause: the platform treats reliability and developer experience as opposing concerns to be balanced, rather than as components of a single system.

Pillar 1 — Automated Reliability

Agarwal frames reliability not as a property of operators but as a property of the platform's state-management code. At small scale, you can rely on humans to react. At large scale, you can't.

The platform needs a control plane that continuously reconciles desired state with actual state — handling placement, self-healing, rebalancing, capacity, and failure recovery. The canonical example here is Kubernetes, whose control loop runs constantly to bring the cluster toward its declared state. Reliability in this model is a function of the platform's logic, not the speed of the on-call engineer.

A useful heuristic from the article: when a workaround starts appearing in multiple teams' codebases, that's a signal it should be absorbed into the platform as a safe default. Platforms grow most healthily by promoting community-discovered patterns into first-class primitives.

Pillar 2 — Developer Ergonomics

The second pillar is the developer's interaction surface — the SDKs, CLIs, templates, and abstractions they use to interact with the platform. Agarwal makes the under-appreciated point that ergonomics directly drive reliability. Confusing or manual interfaces produce human error, and human error degrades production.

The good practice patterns he highlights:

• SDKs with safe defaults baked in. Exponential backoff, circuit breakers, environment-aware configuration, sensible timeouts — all on by default. Developers should have to opt out of safety, not opt in.
• Pattern-based abstractions. Common workflows — blue-green deploys, canary rollouts, schema migrations — should be encoded so they're easy to do correctly and hard to do wrong.
• Opinionated, not infinitely configurable. Surface only the knobs people actually need; everything else stays internal.

A diagnostic signal: if developers are routinely using "escape hatches" to bypass the platform, that's the platform telling you it's not ergonomic enough. Each escape-hatch usage is a backlog item.

Pillar 3 — Operator Ergonomics

The third pillar — and the one most often skipped — is the experience of the people running the platform itself. Operators deserve the same care developers get.

Key components:

• Declarative, idempotent tools. An operator should be able to run an action twice without fear of doing damage. Imperative one-shots are how outages start.
• Layered observability. The system should let an investigator answer "is something wrong?" → "where is it wrong?" → "why is it wrong?" in that order, with each layer of detail accessible without context-switching tools.
• Encoded tribal knowledge. Playbooks, runbooks, and operational guidance baked into the tooling so that a first-time on-call engineer can resolve common incidents about as quickly as a veteran.
• Safe-by-default CLIs. Dangerous actions should require explicit confirmation, dry-run modes, and visible blast-radius previews.

If your senior on-call engineers are heroes who hold the system together with informal knowledge, that knowledge is a liability — the platform must absorb it.

The Virtuous Cycle in Action

Where the article really earns its title is in showing how the three pillars reinforce each other:

flowchart LR
    A[Automated reliability] --> B[Predictable system behavior]
    B --> C[Less operator firefighting]
    C --> D[Operators have time to improve platform]
    D --> E[Better dev & operator ergonomics]
    E --> F[Fewer human errors, smoother traffic]
    F --> A

Each pillar feeds the next:

• Automated reliability produces predictable, well-shaped traffic and behavior.
• That predictability reduces operator load.
• Less-burdened operators have time to invest in platform improvements.
• Better ergonomics mean fewer human errors — which improves reliability further.

The negative version is just as real, and just as compounding. Poor tooling causes incidents → operators fight fires → no one has time to improve the platform → ergonomics degrade → incidents multiply. This is the doom loop most struggling platform teams are stuck in.

Patterns and Frameworks Worth Stealing

A few practical patterns surface throughout:

• Absorb recurring patterns into the platform rather than asking every team to reinvent them.
• Continuous reconciliation beats human intervention at scale; design control loops, not procedures.
• Design incident response for novices. If only your seniors can resolve common incidents, your tooling is broken.
• Prefer declarative over imperative for both developers and operators — desired-state APIs that are safe to retry.

Summary at a Glance

The Takeaway

Reliability and ergonomics are the same investment from different angles. A platform that is reliable but painful to use will produce just as many outages as a platform that is delightful but flaky — they just produce them through different vectors. The goal of platform engineering is not to balance these concerns but to recognize that human-centric design is reliability engineering, and to set the virtuous cycle spinning.

If you lead or contribute to a platform team, an honest audit using these three pillars is a useful exercise. Where is the cycle compounding? Where is it breaking down? Whichever pillar you're weakest on is almost certainly where your next investment will pay off the most.

Reference: Three Pillars of Platform Engineering: A Virtuous Cycle