"I don't build just apps. I build the app-making experience." That reframe is the actual job description this entire series has been describing since Day 19, and today's article turns forty-five days of concepts into an actual roadmap for becoming the person who does this work. The six steps below map almost exactly onto the five phases this series has moved through — which isn't a coincidence, it's the natural order the discipline builds in.
Note
A platform engineer isn't defined by a specific tool or certification. You build the platform that developers use to build amazing products — developer productivity, self-service experience, secure by default, scalable and reliable, automated everything. Everything else is the specific skill set that lets you deliver on that definition.
The six-step roadmap
1. FOUNDATION → Linux, Networking, Cloud Basics, Containers, Git
2. CORE DEVOPS & SRE → CI/CD, Infrastructure as Code, Monitoring, Logging,
SRE Principles
3. PLATFORM FUNDAMENTALS → APIs, Internal Developer Platform (IDP), Observability,
Golden Paths, Self-Service
4. ADVANCED CAPABILITIES → GitOps, Policy as Code, Observability, Security & Compliance
5. REAL-WORLD EXPERIENCE → Work on platform team projects, solve developer pain
points, ship & iterate
6. GROWTH & LEADERSHIP → Think in systems, measure impact, mentor others,
stay curiousSteps 1 and 2 are this series' DevOps Foundations and SRE Foundations phases (Days 1–17). Step 3 is Platform Engineering Foundations (Days 19–27). Step 4 is Platform Engineering Architecture (Days 28–35). Steps 5 and 6 are what this series has been calling Advanced Platform Engineering since Day 36 — the part that can't be learned from articles alone, because it requires an actual platform, actual developers, and actual feedback.
The skills, mapped to what actually gets used daily
| Category | Tools and skills |
|---|---|
| Infrastructure as Code | Terraform, Pulumi, CloudFormation |
| Kubernetes | K8s, Helm, Operators |
| CI/CD & GitOps | GitHub Actions, Argo CD, Flux |
| Observability | Prometheus, Grafana, Loki, Tempo |
| Security | OPA, Vault, SAST, Policy |
| Internal Developer Platform | Backstage, Port, Compass |
| Cloud | AWS, Azure, GCP |
Every tool on this list has appeared somewhere in this series — not as an endorsement of any specific vendor, but because these are genuinely the categories a platform engineer needs fluency in, regardless of which specific product an organization has standardized on.
What the mindset actually looks like day to day
Developer First → empathize with developer pain, don't guess at it
Solve Real Problems → build what matters, not what's cool to build
Think Long-Term → design for scale, reliability, and security up front
Own the Outcome → you're responsible for developer success, not just uptime
Keep Learning → tools change constantly; fundamentals compoundA realistic day looks less glamorous than the job title suggests: checking platform health and developer feedback first thing, improving a self-service API mid-morning, unblocking a team at midday, analyzing usage and adoption metrics (Day 38's numbers) in the afternoon, automating and documenting before the day ends, and planning tomorrow. The recurring theme across the whole day is that most of it is spent looking outward at developers' actual friction, not inward at infrastructure for its own sake.
Projects worth actually building, not just reading about
Create a self-service portal. Build golden path templates. Automate infrastructure with Terraform. Set up GitOps for environments. Build an observability dashboard. Build in public, share what you learn, get feedback, and improve — the same feedback loop this series has described for platforms themselves, applied to your own skill development.
The success formula, and why it's additive, not sequential
"Strong fundamentals + practical experience + developer empathy + continuous learning = Platform Engineer." None of these four are optional, and none substitute for another — deep Kubernetes knowledge without developer empathy produces exactly the over-engineered platform Day 45 warned about; developer empathy without strong fundamentals produces good intentions with no way to execute on them.
"Start where you are. Build what helps others. Keep shipping. Keep learning." That's the actual takeaway, and it's worth noticing it doesn't require a specific starting point — a background in application development, operations, or infrastructure all lead here through slightly different versions of the same six steps. Tomorrow's article gives you the way to measure where you and your platform actually stand on this journey: the platform engineering maturity model.
