At PlatformCon 2024, Kelsey Hightower and Kaspar von Grünberg hosted a live Q&A session. This session was packed with wisdom, and I find myself rewatching it from time to time. One of Kelsey’s answers really stuck with me. He didn’t literally say, “master the basics first before jumping on to the next thing.” But that’s how I interpreted his message:
Make things elementary. Finish something. Only then move on to the next step.
Abstractions always build on layers.
This idea may sound simple, but in practice, it’s often ignored. Many organizations (and engineers) try to do everything at once. They chase the latest hype without mastering what’s already on their plate.
I notice this especially when speaking with younger engineers or companies just starting their journey. It often creates the impression that you either have to do everything or nothing. They feel overwhelmed, want to master all disciplines right away, and sometimes forget the basics.
From cars to software: The airbag analogy
Let me illustrate this with cars.
My grandfather drove a Lada VAZ-2101, also known as Schiguli. Think of it as the Soviet equivalent of a VW Beetle or a Chevy Chevette : simple, reliable, but with almost no comfort or safety features. No power steering, no adaptive cruise control, no AI parking assistant. Not even airbags. Just the bare minimum: engine, brakes, wheels, windshield wipers.
When the airbag first appeared, it was a premium feature. For decades you had to pay extra. Later it became standard. Today, no one would consider buying a car without it.
This is exactly what the Kano Model explains:
- Must-be (basics): If missing, people are frustrated. If present, nobody notices. Example: brakes.
- Performance: The better it is, the happier the user. Example: fuel consumption.
- Attractive (delighters): Unexpected extras that make you smile. If missing, nobody cares. Example: a heated steering wheel
The lesson: delighters turn into standards over time. The airbag moved from a “wow-feature” to a “must-have.”
From airbags to platforms: My cloud native journey
The same happens in software and platform engineering.
My own journey looked like this:
- Must-be: Linux, then Docker and containers.
- Performance: Kubernetes and GitOps for reliable deployments.
- Exciters: Realizing that GitOps also made disaster recovery much easier.
What felt like a “wow-factor” at the beginning (disaster recovery without extra effort!) has since become expected. GitOps is now my personal standard. But there are still many companies that only have it on their roadmap or are just getting started. I noticed this during the short conversations at the book signings, and that is completely fine.
But here’s the thing: there isn’t just one type of standard.
- There’s the market standard: what the industry considers elementary.
- There’s your personal standard: depending on your own journey and maturity as an engineer.
- And there’s the enterprise standard: shaped by legacy systems, slower adoption cycles, and organizational realities.
Moving features from “delighter” to “must-be” is often just a matter of raising automation and maturity step by step. That’s how value is created.
Why hype won’t save you
It’s tempting to jump on the latest trend - in AI, GenAI with MCP, A2A…, whatever the buzzword(s) of the year are. Startups might experiment faster, but enterprises will never match that pace. And they don’t need to.
What enterprises must do is:
- Document what you have. Even if it’s chaotic, it’s your starting point.
- Close education gaps. Without shared knowledge, automation efforts collapse.
- Increase automation. The more you automate, the more today’s delighter becomes tomorrow’s must-be.
That’s how you create value. Not by skipping ahead, but by finishing one thing at a time. A good starting point is Infrastructure as Code. And despite the constant chatter that “IaC is dead” or “Terraform is obsolete,” the reality looks different. Around 70% of teams are still relying on Terraform today. Basics don’t disappear just because the hype cycle moves on.
Closing thoughts: Experience is not expertise
It sounds banal, but even after 10–15 years in IT:
If you don’t master the basics, you cannot build real expertise.
And here’s the key difference:
Experience is not expertise.
Many companies confuse the two when hiring. They look for “experienced” people, only to realize later that those people never mastered the fundamentals in the specific area that actually matters.
So, whether you’re an individual engineer or an enterprise building platforms:
- Make the basics elementary.
- Finish one thing before starting the next.
- Don’t get blinded by the hype.
Because in the end, a Ferrari won’t help if you never learned to drive a Lada. A Ferrari also has four wheels and a steering wheel, but that does not mean you can handle it without the basics. I still don’t know how to drive a Ferrari, but what I learned at five years old, sitting on my grandfather’s lap in a Lada, has stayed with me until today.
