Platform Engineer (Kubernetes)

This profile represents the platform shape growing teams reach for: an engineer who treats infrastructure as a product whose customers are the company’s own developers.

Background

Eight years across infrastructure and platform roles for SaaS and fintech companies. Started in classic DevOps, then moved toward platform engineering: building the paved path of CI, deployment, secrets, and observability that lets product engineers ship without filing tickets. Runs Kubernetes on AWS with everything defined in Terraform, and writes Go when the platform needs custom tooling or a small operator. The shift from DevOps to platform work usually happens when a company grows past the point where one team can hand-hold every deployment, and this archetype has lived that transition.

What the work actually covers

Cluster operations. Running EKS or self-managed Kubernetes as a production system: version upgrades on a schedule instead of under duress, node pools sized and autoscaled against real workload shape, resource requests and limits that are actually set, and pod disruption budgets so a routine node rotation never becomes an outage. Multi-environment layouts, usually separate clusters for production and everything else, kept identical through code rather than memory.

GitOps. Deployments driven by Argo CD or Flux, where the Git repository is the source of truth and the cluster converges to it. Rollback becomes a revert, drift becomes visible, and audit trails come for free, which fintech compliance teams notice. The senior version of this includes progressive delivery: canary or blue green rollouts wired to metrics so a bad release backs itself out.

Developer platform. The point of the job. Golden-path templates so a new service gets CI, deployment manifests, secrets, DNS, and dashboards from day one instead of a two-week scavenger hunt. Self-service preview environments per pull request. Sensible guardrails baked into the path, so security and cost policies are defaults rather than review-time arguments. Success is measured by how rarely product engineers need to open an infrastructure ticket.

Terraform underneath. The AWS layer under the clusters, VPCs, IAM, databases, and DNS, held in reviewable Terraform modules with remote state, planned in CI on every change. Platform engineers who skip this layer end up with reproducible clusters on hand-built foundations, and this archetype does not.

Go for tooling. Kubernetes and its ecosystem are written in Go, so the gaps get filled in Go: a small operator to automate a house-specific workflow, a CLI that wraps the golden path, a controller that reconciles some internal resource. Comfortable with client-go and the controller pattern, and disciplined enough to exhaust off-the-shelf options first, since every custom operator is a maintenance commitment.

Seniority signals

Eight years in platform work shows up as product judgment, not just Kubernetes trivia. Signals worth probing: they can name a platform feature they built that nobody used, and what they learned about asking developers before building. They have run cluster upgrades across multiple production environments and can describe the sequencing. They can argue against Kubernetes for a workload that does not need it. They talk about adoption and developer experience as readily as they talk about controllers. Juniors add tools to the platform; seniors remove steps from the workflow.

What to look for if you are hiring this archetype

In interviews, ask how a new service goes from empty repository to serving production traffic on their platform, step by step; the quality of the answer is the quality of the platform. Ask what happens when a deployment goes wrong at 2 a.m. and whether a product engineer can roll it back alone. Ask how they would introduce GitOps to a team currently deploying with kubectl from laptops. Strong candidates ask about your number of services and teams before proposing anything, since a platform for 6 services and one for 60 look different. Red flags: a service mesh or internal developer portal proposed before basics work, no answer for how developers get help, and platform decisions justified by resume value rather than team need.

Engagement fit

Best fit is a company of roughly 20 to 150 engineers that has outgrown ad hoc infrastructure: several product teams sharing clusters nobody fully owns, deployments that depend on specific people, or a compliance push that demands audit trails. Common shapes: a fixed-scope platform assessment, a GitOps migration with a defined end state, or a long-running embedded role as the first dedicated platform engineer. Smaller teams with a single product are often better served by the AWS DevOps and SRE archetype in this pool, since a full internal platform is overkill below a certain team size. Rates for this archetype typically land in the band shown on this card and move with seniority and region.

Typical engagement

Often starts by assessing and consolidating existing infrastructure, then stays on as the platform owner while the product team scales. UK hours with a full morning shared with Europe and afternoons overlapping US Eastern. Available now.

This is a representative sample of the vetted pool. Request it and we confirm real, current availability for a developer with this background.