The Pillars: What "Good" Looks Like
You cannot call something "under" performance without a written definition of "at" performance. • Score a coverage map, not a quiz.
Overview
The pillars are the heart of the system. They are the small set of things you actually evaluate — at hire and every review after. This part defines them for an infrastructure / platform / SRE-shaped role, but the shape generalizes: a technical group (the substance a person must know and operate) and an engineering-mindset group (how they apply it and operate at the seams). Adapt the technical list to your domain; keep the mindset list almost verbatim, because it is what actually separates levels.
The technical pillars are a coverage map
Do not score technical depth as a checklist of tools named. Score it as a map of coverage and judgment: real depth in several domains, working knowledge across most, and the taste to say where each domain is the wrong tool. For a platform role, twelve domains cover the ground:
| # | Domain | What "strong" sounds like |
|---|---|---|
| 01 | Container orchestration | Scheduling, runtime, networking, RBAC — and when not to reach for it |
| 02 | GitOps / continuous delivery | Declarative delivery, drift, safe rollback; the failure modes of auto-sync |
| 03 | Policy-as-code | Enforce vs audit, mutation vs validation; policy as guardrail, not theatre |
| 04 | Service mesh | mTLS, traffic splitting; when the mesh pays for itself vs native primitives |
| 05 | Observability | SLOs tied to user journeys; which dashboard lies; load-bearing vs vanity metrics |
| 06 | Secrets management | Rotation, blast radius of a leak, least-privilege issuance |
| 07 | Ingress / gateways | L7 routing, TLS, multi-tenant exposure |
| 08 | Multi-tenancy | Pooled vs siloed, noisy-neighbor control, per-tenant blast radius |
| 09 | Developer platforms | Golden paths, self-service, staying out of the flow; platform-as-product taste |
| 10 | Supply-chain security | Image provenance, signing, CI/CD trust boundaries |
| 11 | Infrastructure-as-code | Module design, state, drift, reversible changes |
| 12 | Autoscaling & cost | Event- and node-autoscaling, cost vs latency, scale-to-zero, bin-packing |
Reading the signal is the point: deep in four or five domains, fluent across most, and able to name where a domain is overrated reads as senior. Name-dropping all twelve with no tradeoff or consequence reads as junior. The domains are anchors for a conversation, not a trivia sheet.
The mindset pillars are what separate levels
These are scored on top of the technical work, in every round and every review. Two of them are through-line pillars, evaluated everywhere: autonomy and end-to-end ownership.
| Pillar | What "good" looks like |
|---|---|
| Engineering fluency | Came to the domain through writing code and still reads and writes it — ships tooling, not just configuration |
| First-principles reasoning | Starts from constraints, failure modes, tradeoffs; names non-goals; at the top, reframes the problem and names the binding constraint |
| Reversibility & blast radius | Writes the rollback before touching anything; speaks in canary, kill-threshold, failover |
| Debugging fluency | Works the layers in order with a hypothesis and expected evidence at each; cheapest decisive check first |
| Simplicity / via negativa | Removes toil, services, alerts before adding; can name a subtraction that made things better |
| AI in the workflow | Uses AI daily and verifies it; treats output as a hypothesis; can name what they would not trust it to do in production |
| Autonomy (through-line) | Sets direction without being told; makes reversible calls without asking; escalates the right ones |
| End-to-end ownership (through-line) | Owns something that broke in production — who got paged, what changed; closes loops and follow-ups |
| Decision-making | Evidence- and tradeoff-first; connects choices to revenue, velocity, and risk |
| Strategic/tactical balance | Many small reversible bets plus a few big high-conviction ones — nothing stuck in the timid middle |
| Cross-functional collaboration | Operates at the seams; resolves peer-team tension with evidence, not escalation |
The barbell, the via negativa, and the paged owner
Three mindset pillars deserve their own note because they are the ones people most often fake.
The barbell is a specific claim about risk-taking: the best operators make many small, cheap, reversible experiments and a few large, high-conviction bets, and almost nothing in the medium-risk middle. Ask for one of each. A person who only has medium-sized, hedged bets rarely moves anything.
Via negativa is the discipline of subtraction. The strongest engineers can point to a service they deleted, an alert they removed, a runbook they made unnecessary — and say what got better and whom they had to convince. Addition is easy; removal takes judgment and courage.
The paged owner is the ownership test: ask for a decision the person personally owned that later broke in production. Who got paged? What did they change? "We had an incident" is a story about a team. "I shipped the change that caused it, I got paged, and here is what I changed in how we deploy" is a story about an owner.
Write the "why it matters" next to each pillar
A pillar list that only says what you want reads as a demand. Next to each pillar, write one line of why it matters to the person's own growth. "Ownership — because the engineers who carry things end-to-end are the ones who get trusted with bigger things." This tiny addition turns the rubric from a stick into a development map, and it is the same document you will later hand someone whose ownership is slipping.