Engineering burnout rarely comes from the hard problems. Hard problems are why people become engineers in the first place. It comes from everything around them: the deployment that only works from one person's laptop, the pipeline nobody dares to touch, the late-evening message to the one colleague who still remembers how staging was set up on a project from three years ago.

None of that work shows up in a sprint. It is not estimated, it is not in the story points, and it rarely comes up in a retro. But it drains a team more reliably than any deadline, because it never ends and nobody gets credit for it.

I have been the person who gets that message. This piece is about what we learned standardising how software gets from a developer's branch to production, and what I would tell a CTO at a scale-up or a corporate innovation team who is wondering whether an internal developer platform is the answer to a team that is quietly running out of energy.

Where The Burnout Actually Comes From

An agency is a good place to see this problem, because it amplifies it. We have been building software since 2013. Over that time, a lot of projects were set up by whoever started them, with whatever that year's preferences were: a different deploy script here, a different environment variable convention there, a hosting choice made because it was quick at the time. Each decision was reasonable on its own. Together they meant a developer moving between two client projects in the same week was also switching between two entirely different ways of shipping.

That pattern produces burnout through a few predictable routes:

• Cognitive load that never shows up on a board. Every bespoke setup is something a developer has to hold in their head before they can do the actual work. Multiply that by every project they touch and the "real" task is often the smallest part of the day.

• Knowledge concentrates in one or two people. Whoever set up the pipeline becomes its permanent owner by default. Their holidays are not really holidays, and everyone else learns to route around the thing instead of understanding it.

• Toil is invisible, so it is never prioritised. Fixing a flaky deploy, rotating a credential by hand, chasing a full disk: none of it is on the roadmap, so it happens in the margins, usually in the evening.

• Fear turns deploys into events. When the pipeline is fragile, people deploy less often. Changes pile up, releases get bigger, incidents get bigger with them, and the whole team starts treating production as something to be nervous about.

Scale-ups tend to hit this somewhere between twenty and forty engineers, when "just ask Sam" stops scaling. Corporate innovation teams hit it from the other direction: each team inherits slightly different conventions from central IT, and nobody owns the gap between them.

The Incident That Made It Concrete For Us

The clearest example we had was not dramatic, which is exactly why it is instructive.

"Our GitLab CI runners kept their build cache on the local disk of the CI server, shared across every project. The disk filled up. Pipelines across client projects stopped, all at once, for a reason that had nothing to do with any of those projects." Guido van Beek, CTO & Co-founder, Lizard Global

The fix itself was not hard. We moved the runner cache to object storage on DigitalOcean Spaces and put a 14-day lifecycle rule on it, so it cleans itself up instead of waiting for someone to notice. What mattered was what the incident revealed: a single piece of shared infrastructure that every team depended on, that nobody owned as a product, and that only got attention when it broke. It landed with me, which is itself part of the problem.

That is what a platform looks like when you do not have a platform. You already have one. It is just undesigned, unowned, and held together by whoever is awake.

What An IDP Is, and What It Is Not

The term has become crowded, so it is worth being precise.

-

An IDP is not a portal. Developer portals like Backstage are a front door. They are useful, but the platform is what sits behind the door. A lot of teams start with the portal and end up with a well-organised catalogue of the same inconsistency they had before.

• An IDP is a set of paved paths. Concretely: the route from "I need a new service" to "it is running in production, observable, and compliant" that a developer can walk on their own, without asking anyone, and without having to make a dozen infrastructure decisions along the way.

• It includes context, not just infrastructure. A pipeline tells you how code gets to production. It does not tell you why the code looks the way it does. For a long time that second part lived only in people's heads, and it is the part that makes someone indispensable. More on that below, because it has changed more for us than anything on the infrastructure side.

• For most organisations, it should be thin. Under roughly a hundred engineers, the right platform is usually a handful of project templates, one shared pipeline definition, a consistent environment model, and documentation people actually read. Not a dedicated team of eight building an internal product nobody asked for. Build the thinnest thing that removes the most repeated pain, then grow it when the pain moves.

Designing The Paved Road

The layers below are where we have put our effort, roughly in the order they pay back.

Standardise the stack before the pipeline. You cannot have one pipeline pattern for ten different runtimes. TypeScript is the common thread across almost everything we build: Next.js and PayloadCMS on the web, React Native and Expo on mobile, Vendure for ecommerce, and our microservices. That single language is what makes a shared pipeline realistic instead of aspirational. If your organisation runs five languages for historical reasons, the first platform decision is which ones new work is allowed to start in.

-

Start every project from a template. A new repository should arrive with linting, tests, a container build, environment handling, and a health endpoint already wired in. The first commit a developer makes should be product code, not plumbing.

• Share pipeline definitions instead of copying them. Projects should include a versioned pipeline template rather than carrying their own copy of the YAML. When the template improves, every project benefits on its next run. Versioning matters: a project can pin to a known version and upgrade deliberately, so a platform change never surprises a team mid-release.

• Use the sameenvironment model everywhere. The same environment names, the same promotion path, the same way of getting a preview of a merge request. The question "how does this project deploy?" should have one answer across the whole organisation.

• Keep secrets in the pipeline, not on laptops. Production credentials belong to the deployment process, not to individual developers. This removes an entire category of risk and an entire category of "can you run the deploy for me, I don't have access."

• Wire observability in by default. Logging, error tracking, and uptime checks should come with the template. The first time someone looks for monitoring should not be during an incident.

• Turn infrastructure choices into tiers, not debates. We built a hosting cost estimator around four tiers mapped to a project's compliance level, so the question of where something runs becomes a lookup rather than a meeting. It mirrors how we structure our managed services: the level a project needs follows from its obligations, not from whoever happens to be in the room.

The Context Layer: When The Repository Explains Itself

Everything above standardises how code moves. The bigger shift for us has been standardising how knowledge about the code is kept.

"The way we now build software is AI-assisted end to end, and a structured process sits underneath it. A side effect of that process is an enormous amount of context living inside every project: requirements, architecture notes, and decision logs, all as markdown files next to the code." Guido van Beek, CTO & Co-founder, Lizard Global

Nobody on the team sits down to write these as a chore. They are produced as part of how the work gets done, which is exactly why they stay current. Documentation that depends on someone finding time to write it goes stale. Documentation that is a byproduct of the process does not.

The result is that a repository no longer just contains code. It contains the reasoning behind the code: what was decided, what alternatives were rejected, and why. Tools like Graphify go a step further. It maps an entire project, code and documentation alike, into a knowledge graph an agent can query instead of grepping through files.

The code itself is parsed locally and deterministically, so nothing leaves the machine, and every connection in the graph is marked as either read directly from the source or inferred. That distinction matters when you are about to change something you did not build. The question "where does this actually happen, and what else depends on it?" gets answered in seconds rather than by reading files for an afternoon.

I would argue this is an internal developer platform in its own right. It is the layer that removes the most personal kind of dependency: the one on the person who remembers.

Here is what that looks like in practice. The lead developer on a client project is on leave. The client needs a small change, and it turns out to matter a great deal to them. In the past, the honest answer was that we "managed" it: we reassured the client, bought some time, and waited until the one person who understood the project was back. Nobody enjoyed that conversation, least of all the developer who came back to an urgent ticket on their first morning.

Now I pull the project, have an agent analyse the codebase, go through the decision log, and within minutes I understand what is going on and why it was built that way. I make the change, test the build, commit, push, and the pipeline does its work. Done.

Neither half works on its own. Context without a standardised pipeline means I understand the change but still have to work out how this particular project gets deployed. A standardised pipeline without context means I can ship, but I am guessing at what I might break. Together, anyone on the team can safely pick up any project, and the person on leave actually gets to be on leave.

That is where most of the burnout relief comes from. Not from faster builds, but from nobody being the only one who can help.

CTO Recommended Reads:

• We've Rebuilt How We Build Software. Here's What That Means for You
• Why We Built Our Entire Service Model Around Compliance
• Is Your Company Compliant with UU PDP? Current Status and Enforcement Reality
• Enterprise RAG Architecture: How To Securely Connect LLMs To Your Legacy CRM
• Types of AI Integration: Strategies To Assess Business Readiness Before Code Is Written
• Agentic AI Workflow Automation: Streamlining Enterprise Operations In The Netherlands

Golden Paths, Not Golden Cages

A platform that forbids everything it does not cover will be bypassed, and the bypasses become the next generation of snowflakes. The goal is for the paved path to be the easiest way to ship, not the only way.

That means treating developers as the platform's customers. When a team routes around the platform, that is feedback about the platform, not a discipline problem.

A few measures tell you more than any satisfaction survey:

• How long it takes to get a brand new repository to its first production deploy.
• How often people ask deployment or environment questions in chat, and who they ask.
• How many distinct pipeline variants exist across your repositories.

If the first number is falling, the second is shrinking, and the third is converging, the platform is doing its job.

The Compliance Dividend

This is the part most IDP articles skip, and for the clients we work with it is often the part that justifies the investment.

We have written before about building our service model around compliance, and about working towards ISO 27001. A standardised pipeline turns out to produce much of the evidence that work requires, as a byproduct rather than an extra task.

-

Change management becomes automatic. If every production change goes through a merge request, an approval, and a pipeline run, the change management log already exists: who approved what, what changed, when, and why.

• Access control becomes auditable. When the pipeline holds production credentials instead of individual developers, the access control register gets short and easy to defend.

• Decisions become traceable. The same decision logs that let a colleague pick up a project also answer the auditor's question of why a system is built the way it is, and when that changed.

• Monitoring becomes comparable. When every project emits the same signals in the same shape, you can report on them consistently. Our monthly Platform Health Report is generated by an agent-based system that pulls from monitoring, error tracking, and code quality tools. That only works because the inputs are standardised. An agent cannot write a coherent report across forty differently configured projects any better than a person can.

That last point connects to what I wrote about agentic automation: agents are only as useful as the structure they have to work with. A standardised platform is that structure for everything that happens after a merge.

If you want the detail on the compliance side, we covered it here.

What An IDP Will Not Fix

It would be dishonest to sell a platform as a cure for burnout in general.

If your team is exhausted because every sprint is overbooked, a better pipeline just lets them ship the overbooked sprint faster. Be clear with yourself about which problem you actually have.

"A good platform removes toil. It does not fix overcommitment, unclear priorities, or delivery dates promised before engineering ever saw the scope." ~ Guido van Beek, CTO & Co-founder, Lizard Global

A platform also needs an owner. Without one, it quietly becomes the next piece of shared infrastructure that only gets attention when it breaks, which is exactly where we started.

Where A CTO Should Start

If you are looking at this for your own organisation, my advice is to start smaller than feels ambitious:

-

Count your pipeline variants. The number is usually higher than anyone expects, and it is the simplest honest measure of how much invisible load your team is carrying.

• Find the question people ask most. Whatever deployment or environment question comes up most often in chat is your first paved path.

• Put one new project fully on the road. Migrate existing projects when they are next touched, not in a big-bang rewrite that competes with delivery.

• Make context part of the process, not a documentation task. If decisions and architecture notes are only written when someone has spare time, they will never be current. Build them into how work gets done, keep them in the repository, and test the result: can someone who has never seen the project make a safe change without asking anyone?

• Write requirements into the template, not a policy document. A security or compliance rule that lives in the default configuration gets followed. One that lives in a wiki gets remembered at audit time.

• Name an owner. Not a committee. A person whose job includes treating the platform as a product.

The best sign a platform is working is that nobody talks about it anymore. Deploys stop being events, new projects start with product code, any project can be picked up by anyone on the team, and the late-evening message to the one person who remembers how it all works simply stops arriving.

Ready to Eliminate Toil and Scale Your Platform Engineering?

Is hidden operational toil slowing down your team and burning out your best engineers?

👉 Schedule a free Platform Strategy Assessment with our engineering experts today to evaluate your current deployment pipelines, identify hidden friction points, and build a lightweight, paved path that scales your engineering organization.