Skills Matrix
A skills matrix maps what a platform engineer can do at each level, from junior through staff, across the competencies that actually matter on a Kubernetes platform.
//
Search across all documentation pages
A skills matrix maps what a platform engineer can do at each level, from junior through staff, across the competencies that actually matter on a Kubernetes platform.
Use it for hiring calibration, growth conversations, and deciding who is ready to hold production access.
Read each competency as a ladder, not a checklist - each level assumes everything below it.
Rate honestly against observed behavior, not familiarity. Having read about Karpenter is not the same as having tuned a NodePool during an incident.
Nobody is uniform across all seven competencies, and that is expected. Senior engineers typically sit at senior in four or five and mid in the rest.
The level is the mode, not the maximum. One staff-level spike does not make a staff engineer.
For onboarding, use it to pick the first three gaps to close rather than to grade the whole person.
COPY vs ADD, and why apt-get update alone busts the cache. Uses docker compose up for local dev.buildx.kubectl describe output and finds a crash reason.livenessProbe that duplicates the readiness check causes restart storms, and what a PodDisruptionBudget protects during drains.svc.namespace.svc.cluster.local.ndots, MTU, conntrack exhaustion. Owns Gateway, listeners, and TLS termination.CrashLoopBackOff, ImagePullBackOff, OOMKilled, and Pending from first principles rather than by pattern-matching. Understands rolling update surge and unavailability.kubectl apply something they have not read.restricted, writes namespace-scoped RBAC, and uses External Secrets rather than hand-managed Secret objects.latest breaks reconciliation.You should be able to point at any engineer and name their two weakest competencies without hedging.
Each of those gaps should map to a concrete next assignment - not a course, but a piece of real work with a reviewer attached.
You should also see the platform team's collective shape. Seven competencies with only one senior-plus engineer each is a bus-factor problem, not a staffing plan.
If everyone is strong in A through D and weak in E through G, you have an operations team, not a platform team.
How often should this be re-scored? Twice a year is enough. Scoring it quarterly turns it into performance theater.
Should app developers be scored on this? No. This is a platform-engineer ladder. App devs need a narrower cut - roughly A, B, and the junior-to-mid rungs of D.
Does a staff engineer need staff-level depth everywhere? No. Staff level is about scope and judgment, typically with two or three deep spikes and credible breadth elsewhere.
Where does cloud expertise fit? Inside each competency rather than beside it - node autoscaling with Karpenter lands in D, workload identity in E, load balancer provisioning in C.
Can this drive compensation? Use it to inform level, not to compute it. A matrix that decides pay gets gamed within one cycle.
What if someone is senior in G but junior in A? That is an engineering manager or an architect, and mislabeling them as a platform engineer helps nobody.
Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).
Reviewed by Chris St. John·Last updated Jul 16, 2026