Over the last few weeks I’ve been laying out how platform engineering grew out of DevOps practice, and what actually separates the two once you stop treating them as synonyms. This post is smaller than either of those, and more personal. It’s not an argument about where the industry is heading. It’s about a question I noticed I’d started asking myself before any other question, and what changed once I did.
The old question was: how do I get this into production with less effort than last time. The new one is: who else has to live inside this, and would they choose to use it if they had another option. Same job, mostly — Technical Team Lead at Ebucks (FirstRand Group) from 2019, Cloud Architect there since 2024 — but the first question I ask about a design changed underneath the title, and I only really noticed it after the fact.
The DevOps-engineer question: how do I ship faster#
DevOps-engineer thinking, especially the tool-first version of it I came up through, optimises for your own path to production. You automate the step that annoyed you yesterday. You write the pipeline that removes your own toil, cuts your own lead time, gives you your own green checkmark. That’s not a criticism — it’s most of what good DevOps practice actually is, and it’s genuinely valuable work. It’s also, not coincidentally, most of what a homelab lets you do without ever having to answer to anyone else.
My own GitOps pipeline is a fair example of that mode running at full tilt. Build, scan, promotion gate, automated verification, one deliberate human decision to cut traffic — I designed every step of it for an audience of one. The build WorkflowTemplate has this blog’s Dockerfile path, its SonarQube project key, and its image tag format hardcoded straight into the manifest, because no other build has ever needed those strings to mean anything beyond what I typed into them. If I decide the tag format’s wrong and change it tomorrow, that’s a commit and a rebuild — nobody files a ticket, because nobody else was depending on that pipeline behaving a particular way by Tuesday morning. I could change the shape of my own contract with myself at 11pm and nobody would notice or care.
That’s the whole affordance of a homelab, and it’s a real one. Build it, run it, break it, fix it, no support ticket, no second team pointing at your interface and asking why it changed. There is no user research step for a system with one user.
The platform-engineer question: who’s the user#
A platform decision at Ebucks doesn’t work that way, and it took me a while to stop instinctively reaching for the homelab habit when I was really doing the other job. Owning landing zone design and IAM governance across AWS and Azure at group level, or writing the reference architecture other engineering teams are expected to build against rather than reinvent, means the decision isn’t mine to live with alone. It’s a decision every team that adopts the golden path has to live inside, under POPIA and PCI-DSS constraints they didn’t choose and can’t opt out of. If the security gate every image has to clear before it touches any environment is too slow, too opaque, or too easy to get wrong, that’s not friction I absorb — it’s friction every team downstream of me absorbs, on every release, whether they ever hear my name or not.
That’s the actual shift. Not “do more automation,” not “learn a new tool.” A different first question: if I built this as a product, who’s the user, what’s the interface I’m handing them, and — genuinely — would they choose to use it if there were an easier way round it. A golden path nobody adopts because the escape hatch is faster isn’t a golden path, it’s a diagram.
The bottom-right box is the whole difference. In the homelab loop, “if it’s wrong, I fix it whenever suits me” is true because I am the only consumer of my own decisions. In the platform loop, that box doesn’t exist any more. Once another team has built against your interface, you’ve taken on an obligation you didn’t have the day before — and that obligation doesn’t go away because you were busy, or because a better tool came out, or because the old approach embarrasses you now.
An interface is a contract, not a preference#
I’ve said this before in a completely different context — API design — and I’ve come to think it’s the same rule wearing a different hat. Never break a published contract. You extend it, you version it, or you deprecate it with a timeline and tell people. A REST API and an internal deployment golden path aren’t the same artefact, but they fail the same way when you treat them as your own preference rather than someone else’s dependency: a field gets renamed without warning, a promotion annotation format changes, a default flips, and every consumer downstream finds out by breaking.
The banking context makes this concrete rather than theoretical, because the cost of a broken contract isn’t “an annoyed colleague,” it’s an audit finding or a regulatory conversation nobody wants to have. A reference architecture that other teams have already built compliance evidence against is a contract whether or not anyone wrote the word “contract” on it. Changing it without a migration path doesn’t just cost me time — it puts someone else’s audit trail in a state they can’t explain, which is precisely the failure mode I’ve written about wanting to avoid even in my own homelab, where the stakes are a personal blog rather than a regulator.
Summary: the moment someone else depends on your interface, “I’ll just change it” stops being a decision you’re allowed to make alone.
Turning a repeated request into a self-service path#
The most concrete version of product thinking I’ve found, day to day, isn’t a framework or a workshop. It’s noticing when I’ve personally answered the same request for the third or fourth time and treating that repetition as a signal rather than an interruption. The DevOps-engineer instinct is to just do the thing again, faster than last time, because you’ve automated your half of it. The platform-engineer instinct is to stop and ask why a team is still asking a person instead of using a documented, self-service path — and if the honest answer is “because the path doesn’t exist, or exists but nobody trusts it,” that’s the actual backlog item, not the individual request.
That reframing is uncomfortable in a specific way DevOps optimisation isn’t: it means some of the fastest, most satisfying work I could do — solving someone’s problem for them, personally, right now — is the wrong move if it happens twice. Product thinking asks you to build the thing that makes you unnecessary for that request, which is a strange goal to aim at if you’ve spent a career being the person who fixes things quickly.
The metric changes too#
DevOps collaboration culture gets measured on flow — lead time, deployment frequency, how smoothly work moves from commit to production. Those are still real numbers and I still care about them. But they’re not the number that tells you whether a platform decision succeeded, once other teams are the consumers rather than you. The number that matters there is closer to: did teams actually choose the self-service path over the escape hatch, and did they choose it without me standing next to them explaining how. A golden path with low adoption isn’t underperforming on flow metrics — it’s failing the only test a product actually has to pass, which is whether people who don’t have to use it use it anyway.
That’s the part I didn’t expect when the question in my head changed. It’s not that platform-engineer thinking is more work than DevOps-engineer thinking — plenty of days it’s less, because you’re not the one fixing the same request a fifth time. It’s that the definition of “done” stops being under your control. A homelab pipeline is done when it works for me. A platform is done when the people I built it for would defend it if I weren’t in the room.
Next week closes this series out with the concrete case for platform engineering on a regulated platform specifically — what actually changes, in practice, when the golden path has to survive an auditor as well as a developer.