The most misunderstood thing about moving from system administration to platform engineering is that people treat it as a tool list. Learn Kubernetes, learn Terraform, build a CI pipeline, change your title. What actually changes is not the tooling — it is the definition of the sentence "the work is done." As a sysadmin, the work is done when the request is closed. On the platform side, the work is done when that same request never reaches you again.
Noticing that distinction can take years. Closing tickets feels good — it is measurable, visible, and it earns gratitude. A road you pave is silent; when it works correctly, nobody says your name.
The real cost of a ticket desk
Microsoft's platform engineering guide sums up why organizations slow down as they grow: as the need for governance increases, controls multiply, and those controls usually start out manual. In the guide's own words, "whether driven through service desk requests, review meetings, or periodic manual audits, manual steps introduce friction into the software delivery lifecycle" — and that friction erodes not only velocity but the morale of both developers and the operations team.
Note the word: friction. A request form is not a security control, it is a form of friction. A great many things we sell as security controls are exactly this. "New environment provisioning comes to me" does not guarantee the standard; it only guarantees that the standard lives inside one person's head.
I read this backwards for a long time. When the request came to me, I felt necessary in the process, and telling the difference between being necessary and being useful is not easy at all.
Calling toil by its name
The definition of toil in Google's SRE book turned out to be the sharpest tool I had during this transition. Toil is not defined there in a single sentence; it is described as a behavioral profile: work that is manual, repetitive, automatable, tactical (that is, born of interrupts rather than strategy), devoid of enduring value, and that scales linearly as the service grows. The book frames this not as a definition but as an intuition test: if "your service remains in the same state after you have finished a task, the task was probably toil."
That last attribute is the cruelest one. The practical way to tell whether a piece of work is toil is this: if the system doubles, does this work double too? If it does, it does not matter how skillfully you do it — that work will catch you from behind.
This is why Google's SRE organization sets an explicit target: operational work, meaning toil, should stay below 50% of each SRE's time, and conversely at least half of that time should go to engineering project work. Read that ratio not as a rule but as an alarm threshold. In traditional system administration the ratio usually runs the other way, and the culture rewards it; the person who gets up at night to clean a disk is a hero, while the person who makes sure that disk never fills again looks like they "didn't do much last sprint." I covered the practical side of budgeting toil separately in toil budget and managing operational debt.
The first step of the transition is not installing a tool. It is counting your own week with these eyes and writing the number down. The number will be embarrassing. Embarrassing is good news, because it means you have found something you can budget.
Installing Kubernetes is not building a platform
This was the trap I fell into most often: standing up the infrastructure layer and thinking "we built the platform." Kubernetes' own documentation is unexpectedly honest here. Under "What Kubernetes is not," it plainly states that Kubernetes "is not a traditional, all-inclusive PaaS (Platform as a Service) system"; it notes that because Kubernetes operates at the container level it offers some features common to PaaS offerings, but that those default solutions are optional and pluggable.
The rest is blunter still. Kubernetes does not build or deploy your source code; it says CI/CD workflows are determined by organizational culture and preferences. It does not provide application-level services — message buses, databases, caches — as built-in services. It does not dictate a logging, monitoring, or alerting solution. In other words, the entire answer to your team's question "as a developer, how do I get a new service into production?" sits in the place where you will write it. The cluster is only the ground beneath that answer.
Microsoft's guide calls the thing platform engineering produces an internal developer platform, and draws a nice analogy: paths often start out as dirt trails, and as more people use them they get paved. A paved path — a golden path — guides developers through critical requirements and standards without sacrificing their velocity. The point the guide underlines is this: a fully paved, golden path reduces cognitive load for everyone involved. I looked at how those paths get designed at enterprise scale in golden path design.
Notice the difference: on the platform path the control does not disappear, it moves. It shifts from human approval to an executable gate. Removing controls is not platform engineering; that is just a mess.
A platform you are forced to use is not a platform
One of Microsoft's principles always struck me as overly optimistic, until I watched something I had built myself go unused by choice: "Customers should want to use your platform, but not be mandated to use it."
The sentence sounds like product marketing, but it is actually a very practical diagnostic. If your platform needs a management directive to get used, what you have is not a platform but a tax. People find ways around taxes — a script on the side, a "just this once" exception requested over Slack. And after a while, those exceptions become your real platform.
The guide's product mindset page describes it this way: the platform team should think of itself as the product owner of the internal developer platform, with developers as the end customer. This was the hardest part of the transition for me, because system administration teaches the opposite reflex. There, the user is the party with the potential to break the system. Here, the user is the party you have to win over.
There is an encouraging detail too: the guide's landing page notes it is not uncommon for teams of fewer than 20 people to support thousands of developers and hundreds of projects. That is the most concrete sentence describing platform work as leverage work. The leverage points the same way in a two-person infrastructure team, by the way; what changes is how many paths you can pave at once, not whether paving is worth it.
Starting from the thinnest viable platform
The classic mistake teams make when they set out on this transition is to begin with a roadmap meeting. A six-month "platform program" gets defined, layered diagrams are drawn, and at the end of the sixth month something very tidy that nobody uses comes out.
Microsoft's guide gives clear advice here: it does not recommend a big bang approach or a top-down driven effort; instead it suggests starting from core building blocks you assemble over time, building something with enough value that development teams become its advocates. The term the guide uses is a good one: thinnest viable platform — the minimum viable product of your platform.
I walked through how to pick that first path and how to build the safe default in self-service infrastructure design, so I will not repeat it here. The one thing I want to add is a warning.
The discipline here is that the first path must be complete. A half-paved road strands the developer midway and they will not try again; first impressions are not cheap. I learned this in reverse on my own pipeline: during the period when I had automated the publishing step but left the validation step manual, the pipeline looked "automatic" yet still came through me on every publish. Automating a chain halfway does not speed the chain up; it merely relocates the bottleneck.
A small-scale rehearsal: my own pipeline
I would rather illustrate this transition with an enterprise case, but my most honest example is the repository of the very blog you are reading. It holds eighteen separate GitHub Actions workflow files, and not one of them contains a "Mustafa logs into the server" step. Modest in scale; in mindset, exactly what I described above.
It has three parts, and all three map one-to-one onto their counterparts in an enterprise platform.
Self-service. The publishing flow sits there as a manually triggerable workflow. When a new article goes live, the thing to do is not to log into the server but to run the pipeline. Knowing what is on that server is still my job; going in there every single time no longer is.
Gates. The automated content pipeline has a validator you cannot get past: it tests every link in an article's sources section both against an allowlist and against live HTTP status, and if one fails the workflow stops there. The beauty of a gate is that it works independently of my mood; it applies the same threshold when I am tired. But let me be honest about a gap: the content policy tests are still a command I run locally, not a gate embedded in the publishing path. So part of my pipeline is paved and part of it is still a dirt trail — and I noticed that while writing this very article.
Blast radius. There is a separate workflow that proves the runner itself, and it deliberately uses a different label so it cannot touch the live publishing pipeline. If you want to carry this habit to the enterprise side, GitHub's own security reference is a good starting point. It says self-hosted runners "should almost never be used for public repositories," and asks you to be cautious on private and internal repositories too, because anyone who can fork the repository and open a pull request — generally anyone with read access — can compromise the runner environment. To draw boundaries it describes restricting which organizations and repositories can access runner groups, and keeping sensitive data on the machine, such as private SSH keys and API access tokens, to a minimum.
Taken together, the pipeline works correctly without me. That is also the emotionally strangest part of the transition.
The cost of no longer being the bottleneck
Nobody talks about this part. In system administration your value is measured by your access — the passwords you know, the machines you can log into, the work that does not move without you. When you cross over to the platform side, you have to willingly demolish that definition of value. Black boxes spend their worst nights without telling anyone; but as long as the only key to that box is yours, you are a partner in those nights even on holiday.
The most common resistance I have seen in this transition is not technical, it is this. People are not resisting learning Terraform; they are resisting building the thing that makes them unnecessary. I find that fear entirely understandable, and if you take it lightly the transition stalls halfway.
My own answer became this: the thing being made unnecessary is not me, it is the work I do by hand. Those are not the same thing. When you hand off the manual work, the space that opens fills with the questions nobody in the organization had been looking at — cost, recovery time, whether the standards are genuinely being applied. Those questions make you more visible, not less. I poked at the identity side of this transition in the move from VMs to containers as well; the unease there is the same unease. And I mapped how that same resistance shows up at team scale in mapping resistance in platform migrations.
The platform itself is a production service
Everything I have described has a side effect, and skipping it would be dishonest: toil does not disappear, it changes type. When you close the ticket desk, the requests do not vanish; when the paved road breaks, the person called is now you — and this time it is not one server but the road everyone travels on. Standing up a platform team without discussing its on-call rotation is the fastest way to make the load invisible. If you do not start measuring your own 50% threshold for the platform's own operations, six months later you will have a more elegant bottleneck and nothing else.
The second open question is regulation. "Move the control from human approval to an executable gate" does not hold as written in environments where the approver's name is a legal requirement; where separation of duties demands a named approver, you cannot delete that signature. But I think we ask the wrong question. What the auditor wants is usually not waiting, it is evidence. Even when you cannot remove the approval, you can automate everything in front of it — the checklist, the evidence gathering, the scope of the change. Putting a finished file in front of the approver is a different thing from waiting for the approver, and it usually halves the elapsed time.
What you measure determines what you become
In system administration, measurement usually means uptime and the number of tickets closed. On the platform side both metrics pull you in the wrong direction; a single person can improve either one alone, and by working harder at that.
Microsoft's guide proposes three axes: speed (time to deliver business value), product quality, and the platform's ease of use. The third is critical, because a platform can be technically flawless and abandoned in practice. The guide also suggests measuring not just whether internal customers are satisfied, but whether they are thriving.
I add a check question of my own: in the last month, how many people shipped something to production without asking me? If the number is zero, then whatever you have built, you are still a ticket desk.
Are you ready to move: a short checklist
- Have you broken last week down into hours and written out your toil ratio? Do not start without it.
- Can you name the most repeated request on your team in one sentence? That is the first road to pave.
- Can you turn the controls at the end of that road into an executable gate that needs no human approval?
- Can someone who does not use your platform still get their work done? If not, what you have is not a platform but an obligation.
- When something breaks, does the developer get the answer from you or from the pipeline?
- Do you have a single number showing whether the thing you built is actually being used?
- And the hardest one: when it runs without you, can you count that as output rather than loss?
If you answer "no" to four of these seven, the problem is not your ability but the definition of the job. The good news is that changing the definition is something you can learn.
Which question do you answer
The only thing that genuinely changes in this transition is which question you answer. System administration answers "why is this system not working?" and a good sysadmin finds that answer faster than anyone. Platform engineering answers "what should be built so this system never breaks this way again?" — and the return on that answer is not immediate, it earns no applause, and most of the time it accumulates quietly.
None of your sysadmin years are wasted, by the way; quite the opposite. The people who know where a road should be paved are the ones who walked those routes while they were still mud. What is missing in platform engineering is rarely tool knowledge. What is missing is the patience of someone who remembers the mud.
