Why your best engineers are doing the wrong work

The quiet crisis playing out inside many Managed Service Providers (MSPs) is getting louder now. Engineers are caught in an endless loop of provisioning, patching, and firefighting, while the strategic work, which includes things like consulting, roadmap conversations, and architecture reviews, is getting pushed back week after week.

The root cause isn't headcount, it's complexity and, specifically, the kind of complexity that comes from managing multi-cloud environments at scale without a coherent operational framework underneath. Every client becomes a bespoke project, and the best engineers are spending their time being skilled laborers when they should be trusted advisors.

Platform engineering has emerged as the discipline that can break this cycle, not just for hyperscalers and Fortune 500 internal IT teams, but increasingly for the channel partners serving organizations that face the same infrastructure challenges with a fraction of the resource base.

From enterprise niche to channel imperative

Platform engineering used to be a conversation reserved for companies large enough to have internal developer platform (IDP) teams like Google, Netflix, or Spotify. The idea being that instead of every development team reinventing the wheel on infrastructure, you build a curated, self-service platform that lets engineers consume what they need, governed by defaults and guardrails.

That same logic now maps almost perfectly onto the MSP model, who are, in effect, the internal platform team for multiple clients simultaneously. The question is whether these teams are delivering a service reactively by responding to tickets and building one-off solutions or more proactively, with a repeatable, scalable platform layer that abstracts complexity for customers while giving the MSP team operational advantages.

The tipping point has arrived with multi-cloud. When most clients ran a single cloud, a bespoke approach was manageable. Now, the average organization might have workloads spread across AWS, Azure, and Google Cloud, in addition to a legacy on-prem footprint, SaaS dependencies, and compliance requirements that cover all of the above.

What an IDP looks like in practice

An IDP, in the context of an MSP, isn't a single product that can be bought off the shelf. It's a framework that sits between a customer and the underlying infrastructure, providing self-service access to approved, pre-configured resources. Essentially, the building blocks and guardrails to go ahead and do what they need to do.

In practice, that means a few things are working simultaneously. Firstly, a self-service portal which provides a clean interface that allows customers or their developers to spin up environments, request resources, and manage their own configurations without logging a ticket or waiting for the MSP team to action it manually. Secondly, infrastructure templates, which are pre-approved, tested, policy-compliant blueprints for common workloads. These can include a Kubernetes cluster, a three-tier web application, or a disaster recovery setup, which can be built once by the best engineers and then consumed repeatedly across the client base.

Finally, and this is where it gets impactful for SMB-focused MSPs specifically, built-in FinOps controls that can deliver cost visibility at the resource level, budget alerts, automatic rightsizing recommendations, and tagging policies that make chargeback workable. In a world where cloud expenditure is one of the top concerns for SMB finance directors, the ability to show very clear, attributable cost data is a meaningful differentiator.

The AI-readiness angle

The ability to integrate AI tooling, run inference workloads, and make data accessible for machine learning pipelines isn't a separate initiative. AI-readiness is now more of an infrastructure question, and it's one that a highly complex, bespoke multi-cloud environment is badly positioned to answer.

SMBs looking to leverage AI need a consistent, well-governed infrastructure underneath. They need to know where their data lives, how it's classified, and how it moves between systems, which is pretty dirty work, but it's the foundation without which AI projects stall at the proof-of-concept stage.

MSPs that can offer clients a platform-engineered environment are the ones who will credibly lead in these all-important AI conversations. The ones that can't are likely to be spending the next two years explaining to clients why their AI projects keep running into infrastructure problems.

Build vs buy

Once an MSP commits to a platform engineering approach, the decision then is whether to build tooling in-house or leverage existing platforms. Both paths have merit, and the right answer depends on team size, technical depth, and the diversity of the customer base.

The build argument is straightforward in that it offers maximum flexibility, control, and customized integration within specific customer environments. The challenge is the engineering investment required (not just to build the platform but to maintain and evolve it) as cloud providers continuously update APIs, compliance requirements shift, and client needs change. For lean MSP teams, this can rapidly become a full-time engineering commitment that eats away at the capacity you were trying to free up in the first place.

The buy argument is increasingly compelling. Platform engineering tools are now emerging that let MSPs approach the deployment of consistent, multi-cloud IDP layers without starting from scratch. The better platforms in this space are designed to provide the core scaffolding, such as self-service portals, template libraries, or FinOps dashboards, that enable the building of custom modules and workflows on top.

Selling an outcome, not the architecture

To be clear, Platform Engineering as a Service (PEaaS) is not a product that can simply be added to a price list and bought on its own. It's an operational upgrade that changes what an MSP can offer and how efficiently it can deliver it. The commercial case has to be made through outcomes, which include faster time-to-environment for new workloads; measurable reduction in cloud spend through better rightsizing and tagging discipline; consistent compliance across a customer’s estate; and fewer incidents caused by configuration drift. These are where the important conversations need to happen with customers, and they're more compelling than a technical deep dive on IDP architecture.

The MSPs who position this well are not fielding tickets about why a VM wasn't provisioned on time but, instead, are in quarterly business reviews discussing cloud strategy and digital transformation roadmaps.

Like managed security or cloud migration services, PEaaS will eventually become table stakes. The MSPs who move early will build institutional knowledge, refine their templates, and develop stronger customer relationships. Multi-cloud is the new normal, and AI workloads are arriving whilst compliance requirements are continuing to tighten. The question is whether MSPs meet that complexity with a scalable platform model or absorb it manually, ticket by ticket, until the margin erodes and engineers burn out.