Platform engineering emerged because developers were spending too much time dealing with infrastructure instead of building software.
Internal developer platforms promised a better approach by standardizing workflows, automating common tasks and giving teams self-service access to the resources they needed.
That mission remains largely unchanged, but what’s changed is the environment in which developers operate.
Cloud-native architectures, software supply chain requirements, compliance mandates, security controls and AI tools have dramatically expanded the number of systems developers interact with daily.
As organizations have worked to manage that complexity, many internal platforms have grown into sophisticated ecosystems of their own.
The result is a growing recognition that platform engineering success is not simply about what a platform can do, but how much mental effort developers must expend to use it effectively.
Platform Complexity is Replacing Infrastructure Complexity
Platform engineering was intended to simplify software delivery, but in some organizations, the platform itself has become another system developers must learn to navigate.
Armando Franco, senior director of cloud and platform modernization at TEKsystems Global Services, says many platform initiatives drifted away from their original purpose.
“Platform engineering started as a way to reduce friction, but in many organizations it became another layer of tooling, governance and handoffs,” Franco says. “The intent was simple, but the outcome was often centralization without enough attention to the developer experience.”
In many cases, platform teams successfully standardized infrastructure management while introducing new approval processes, workflow requirements and operational dependencies.
Developers may no longer be provisioning infrastructure directly, but they are still spending time navigating systems, understanding policies and determining how work moves through the organization.
“The complexity was not eliminated but ended up being redistributed,” Franco says.
That distinction is becoming increasingly important as platform teams continue adding capabilities designed to support security, compliance, observability and AI-driven development.
Fragmentation is Driving Cognitive Load
The primary source of developer frustration is not necessarily the number of tools they use, but the lack of cohesion between them.
Developers increasingly work across cloud platforms, AI services, security controls, compliance frameworks and software delivery pipelines that often operate independently of one another.
Each tool may solve a specific problem, but collectively they can create an environment where developers spend significant time determining where information resides, which policies apply and how systems interact.
“The biggest issue is fragmentation,” Franco says. “Developers are being asked to work across cloud, AI, security and compliance tools that often do not feel connected to one another.”
That creates constant context switching and a lot of time spent figuring out which system to use, which policy applies and how to move work forward safely.
Organizations often focus on whether developers have access to the right tools, but Franco notes the more difficult question is whether those tools function as part of a coherent developer experience.
Measuring What Developers Actually Experience
One of the reasons cognitive load has become a growing concern is that traditional platform metrics often fail to capture it.
Platform teams typically measure adoption, deployment frequency, infrastructure utilization and service reliability. Those metrics provide useful operational data, but they reveal little about how much effort developers expend to complete routine tasks.
According to Franco, organizations need to look more closely at whether platforms are reducing friction in practice.
“The real test is whether developers can move faster with less friction,” he says.
That requires examining how much time developers spend on setup activities, approvals, troubleshooting and administrative work. It also means paying attention to behaviors.
“If developers still need to route around the platform to get work done, then complexity has simply shifted somewhere else,” Franco says.
Measures such as time to value, support requests, onboarding effort and the number of required handoffs may provide a clearer picture of platform effectiveness than infrastructure-focused metrics alone.
Treating Platform Engineering Like Product Development
As platform engineering matures, many organizations are beginning to view internal platforms less as infrastructure projects and more as products serving a defined customer base– the developer community.
Franco says he believes organizations sometimes become too focused on platform capabilities and not focused enough on usability.
“Companies can get very excited about what a platform can do and forget to ask how easy it is to use,” he says.
However, powerful capabilities alone do not guarantee adoption. Developers faced with confusing interfaces, excessive workflow requirements or unclear governance processes will often seek alternative paths to accomplish their work.
“If the experience is clunky, slow or confusing, developers will not embrace a platform just because it is powerful and will find a way to work around it,” Franco says. “That is why platform engineering has to be treated like a product rather than an infrastructure discipline.”
Deployment frequency, utilization rates and operational efficiency will remain important measures of platform success.
But as platform teams take on greater responsibility for developer experience, another question is becoming equally important: how much effort does it take for developers to get work done?
Franco notes cognitive load is becoming a more important signal because it gets closer to the real question: Can people do their best work without unnecessary friction?
“If platform engineering is mature, the focus should be on making developers more effective rather than building the most powerful stack at the cost of more friction,” he says.