You have spent years moving data through pipelines, tuning Spark jobs, and arguing with schema drift. Now you keep seeing platform engineer roles paying well above what you bill today, and half the job description looks familiar: infrastructure, automation, reliability. The other half — Kubernetes operators, SLOs, on-call rotations — looks like a different career entirely.
It is not a different career. It is an adjacent one, and the overlap is bigger than most job posts admit. Data engineers already understand distributed systems, idempotency, and failure modes. What is missing is the operational layer: provisioning infrastructure as code, running workloads on Kubernetes, and being accountable for uptime instead of just data quality.
Ninety days will not make you a senior SRE. It will make you a credible platform engineering candidate for mid-level contract roles, with real artifacts to show for it. Here is the plan.
What Actually Changes: Data Engineer vs Platform Engineer
Before you study anything, understand the shift in mindset. This is the table version of the conversation you will have in every interview.
| Dimension | Data Engineer | Platform Engineer |
|---|---|---|
| Primary unit of work | Pipeline, dataset, transformation | Service, cluster, deployment |
| Success metric | Data freshness, accuracy, SLA on delivery | Uptime, latency, error budget |
| Core tooling | Airflow, dbt, Spark, warehouses | Terraform, Kubernetes, Helm, GitOps |
| Failure response | Backfill, reprocess, fix schema | Page, mitigate, postmortem, on-call rotation |
| Automation focus | Orchestration of jobs | Provisioning and self-service infrastructure |
The transferable skill underneath all of this: you already think in DAGs, dependencies, and idempotent operations. That is 70 percent of platform engineering thinking. The remaining 30 percent is infrastructure and operations, and that is what the next 90 days targets.
Weeks 1-3: Infrastructure as Code Foundations
Start where data engineering and platform engineering already touch: provisioning the infrastructure your pipelines have always run on, but now you own the definition, not just the consumption.
- Terraform basics. Providers, state, modules, plan/apply workflow. Build a module that provisions an S3 bucket, an IAM role, and a small EC2 instance or Lambda.
- Remote state and locking. Configure an S3 backend with DynamoDB locking. This is a question you will get asked in almost every platform engineering screen.
- HashiCorp Terraform Associate exam. Fee is $70.50 as of this writing, and the exam is multiple choice, proctored online. It will not get you hired alone, but it proves you can talk the vocabulary fluently.
If your current contract uses CloudFormation or Pulumi instead, learn Terraform anyway. It is the lingua franca most platform teams standardize on, and it reads clearly on a resume line.
Weeks 4-6: Kubernetes and Operators
This is the section that separates a resume tweak from an actual skill pivot. Data pipelines increasingly run on Kubernetes anyway — Airflow on K8s, Spark on K8s — so you are not starting from zero.
- Core objects first. Pods, deployments, services, ConfigMaps, secrets, namespaces. Run a local cluster with kind or minikube before touching a managed one.
- Helm charts. Package something you already understand — a small ETL job or a metrics exporter — as a Helm chart with configurable values.
- GitOps. Install ArgoCD or Flux against your local cluster. Push a change to a Git repo and watch it reconcile automatically. This single exercise demonstrates the self-service, declarative philosophy platform teams are hired to build.
- Operators, at a conceptual level. You do not need to write a custom operator in 90 days. You do need to explain what the operator pattern solves: encoding operational knowledge (backup, failover, scaling) into a controller instead of a runbook. Read the source of an existing operator you might already depend on, such as the Strimzi Kafka Operator or the Postgres Operator from Zalando.
- Certified Kubernetes Administrator (CKA), optional but strong. Cost is $395 and includes one free retake. It is a hands-on, terminal-based exam, not multiple choice, and it carries real weight with hiring managers because it cannot be bluffed.
Weeks 7-9: Observability and On-Call Practices
Data engineers monitor pipelines. Platform engineers monitor everything, and they get paged when it breaks at 2 a.m. This is the part of the transition candidates most often underweight, and interviewers probe it hardest.
- Metrics stack. Stand up Prometheus and Grafana against your Kubernetes cluster. Instrument a small service with custom metrics using a client library in Python or Go.
- Logging and tracing. Get comfortable with the vocabulary even if you do not master the tooling: structured logging, log aggregation (Loki or the ELK stack), and distributed tracing (OpenTelemetry).
- SLOs and error budgets. Read Google's Site Reliability Engineering book, specifically the chapters on service level objectives and error budgets. Practice writing one SLO for a service you have built, including the SLI it is measured against.
- On-call mechanics. Understand escalation policies, runbooks, and blameless postmortems, even without formal PagerDuty experience. If you can describe how you would structure a runbook for a service you built during this plan, you can speak credibly to on-call in an interview.
Weeks 10-12: Build the Portfolio Projects That Prove It
By now you have fragments. This phase assembles them into two or three projects you can actually walk through, live, on a screen share.
- Project 1: Self-service data pipeline platform. Take a pipeline you already understand and rebuild its infrastructure with Terraform, deploy it to Kubernetes via Helm, wire it into ArgoCD, and add Prometheus alerts for job failures. This project alone tells the whole story of your pivot.
- Project 2: Incident simulation. Deliberately break your own service (kill a pod, exhaust memory, introduce latency), capture what your alerts caught, and write a one-page postmortem. Hiring managers respond strongly to candidates who have practiced failure on purpose.
- Project 3 (optional): Cost and capacity note. Add a short writeup estimating infrastructure cost for your project at 10x scale. Platform engineers are expected to reason about cost, not just uptime.
How to Represent This on Your Resume Without Overclaiming
This is where candidates lose credibility fast. A 90-day plan does not make you a senior SRE, and claiming production on-call experience you have not had will surface in the first technical screen.
- Use accurate verbs: "built," "provisioned," "instrumented," "practiced" — not "operated," "led," or "managed" for things you only did in a personal lab.
- Frame it as a demonstrated transition, not a finished one: "Data engineer transitioning to platform engineering; built and deployed a self-service pipeline platform using Terraform, Kubernetes, and ArgoCD, with Prometheus-based alerting."
- List certifications earned with dates, not "in progress" unless you specify an exam date.
- In interviews, be direct about scope: "I have not run production on-call yet. I have simulated incidents and written postmortems, and here is how I'd approach a real rotation."
Recruiters and hiring managers on contract roles have seen inflated resumes before. Precise, honest scoping of what you built in 90 days reads as more senior than vague overclaiming ever will.
If you are weighing this pivot against your next contract search, the team at Josh Pros LLC works with consultants navigating exactly this kind of skill transition. Email contact@joshpros.com or visit https://joshpros.com if you would like to talk through how this plan maps to roles currently open in the market.
#PlatformEngineering #DataEngineering #SREcareer #Kubernetes #Terraform #DevOps #TechContracting #ITStaffing #CloudSkills #CareerPivot #InfrastructureAsCode #Observability #ContractConsultants #TechCareers
Talk to a real recruiter, not a bot.
We'll tell you the rate, the client, and the terms before you interview. And if we're not the right fit, we'll say so.
