Platform engineering is a hot topic right now. Platform is a product with self-service features, providing the right infrastructure, tools, and processes that enable efficient, scalable software development, deployment, and management. A 2025 Google Cloud/ESG research report found that 55% of global organizations have adopted platform engineering, with 90% of those planning to expand it further. In the majority of companies (85%), developers already rely on the platform.
Gartner predicted that by 2026, 80% of large software engineering organizations would have dedicated teams. Mature adopters report cutting time to market in half, with 71% of leading adopters significantly accelerating delivery compared to just 28% of less mature ones. CIOs now track platform initiatives as key business drivers. Platform engineering is absorbing roles like operations, database administration, security, and SRE into a unified layer — fewer engineers supporting more developers.
Dilhan Manawadu, Ph.D., is a Senior Director at Sysco Corporation, leading global platform engineering. He has 18+ years of experience driving enterprise digital transformation, software development, and resilience engineering for high-transaction environments. He holds a Ph.D. in ICT and an MBA in International Business.
2Digital: Platform engineering is a hot topic in 2026. But the concept isn’t entirely new — why is it trending right now?
Dr. Manawadu: The catalyst is the Agentic SDLC, which fundamentally re-engineers the Software Development Life Cycle for the AI era. Adding AI to legacy processes results in only limited automation. Real transformation demands a structural overhaul, such as reducing a ten-step customer journey to four integrated stages. This efficiency is the central promise of agentic AI.
This approach directly impacts software engineering. Traditional phases such as planning, requirements, design, testing, and deployment require fundamental redesign. When the SDLC is built for agents, syntax and coding become secondary challenges, and the system itself drives delivery.
Today, most legacy developer tasks are automated. We refer to this as “shifting down,” where operational complexities are moved deep into the stack and become invisible to developers. By abstracting these requirements, we reduce cognitive load and significantly improve the developer experience. This seamless abstraction defines modern platform engineering.
Although the concept emerged around 2010, pioneered by companies like Google, it remained a niche internal strategy. When Gartner recognized platform engineering in its 2023 Hype Cycle, implementation issues persisted. Developers continued to handle most operational tasks, resulting in bottlenecks and fragmented workflows. Instead of “shifting down” to a supportive foundation, they were “shifting left” into additional work. As a result, adoption lagged as engineers relied on their own custom solutions.
The key change in 2026 is the integration of autonomous agents that manage development with unmatched speed and scale. Success depends on orchestration; instead of assigning agents many unrelated tasks, we manage complexity within the platform itself. Modern platform engineering starts with the Agentic SDLC, positioning the platform as the essential foundation. This shift has made the field both mission-critical and among the most highly compensated in technology.
2Digital: What was wrong with team-specific tools and pipelines?
Dr. Manawadu: The main issues are standardization, security, and developer cognitive load.
When each team creates its own infrastructure, developers can lose 30 to 40 percent of their capacity to managing infrastructure instead of focusing on business logic. This inefficiency slows progress. Customers are interested in business outcomes, not your CI/CD provider or cloud vendor. If engineers spend time on infrastructure rather than delivering results, you risk losing your competitive advantage.
2Digital: When you offload so much work to an agent, does security get better?
Dr. Manawadu: On the contrary, security becomes significantly more important. Humans naturally review, test, and exercise judgment, which limits risk. While a human team may handle a thousand deployments each month, agents can perform millions daily without fatigue or hesitation. As a result, failures can occur rapidly and at a much larger scale.
This is why platform engineering must deliver a strong security foundation. We are implementing zero-trust architectures and strict guardrails to address the unpredictable nature of AI. While informal coding may be acceptable for prototypes, enterprise delivery requires a platform that enforces consistency. This approach is essential to prevent systems from failing rapidly at scale.
2Digital: Does every company need to think about building a platform? Even one with just three developers?
Dr. Manawadu: Not every company needs to build a platform.
This is a gradual process. Startups should use agents for rapid deployment and focus on achieving Product-Market Fit. Avoid investing in a platform team until your product has demonstrated it addresses a real need.
Scaling typically becomes necessary at the 1,000 to 2,000 user threshold. At this stage, Kubernetes and cloud-native complexities require a formal infrastructure to support growth. For enterprises with custom microservices or internal AI agents, a platform foundation is essential for orchestration.
If you operate within SaaS ecosystems such as Salesforce, SAP, or Oracle, the infrastructure is already managed. There is no need to duplicate what is provided. The key consideration is not whether you need platform engineering, but whether your development model warrants the investment.
2Digital: Say you’re a business owner. Everyone’s talking about platform engineering, so you built one. Everything looks flashy and nice. How do you actually know if it’s working?
Dr. Manawadu: It’s a unique challenge because your platform’s true customer is the developer, not the end user.
Consumer product users focus on completing tasks and are generally satisfied if the experience is functional. Developers, however, are more discerning. As “power users,” they build systems professionally and recognize what defines a world-class platform.
The primary KPI should be organic adoption. If developers use the platform seamlessly, without friction or manual workarounds, it is effective. Like a preferred IDE or observability tool, successful platforms become part of daily routines.
Most importantly, measure developer satisfaction. This behavioral indicator is the ultimate test of success. If developers find the daily experience frustrating, the platform fails regardless of its technical strengths. Technical depth matters, but prioritizing developer experience (DX) is essential.
2Digital: So you need good developers to be credible judges of your own platform. But for the business side — what does this actually cost? In headcount, in time, in distraction to the rest of the teams?
Dr. Manawadu: The answer depends on your organization’s size, but a helpful guideline is to allocate 5 to 10 percent of your development team to a dedicated platform group if you have around 100 developers. Without this, teams often duplicate efforts on infrastructure, security, and CI/CD challenges. Establishing clear ‘golden pathways’ allows developers to focus on delivering features rather than repeatedly solving the same problems.
However, this ratio may change as organizations adopt smaller teams supported by AI agents for specific tasks. This evolution increases the importance of platform engineering. Platforms must manage context and organizational knowledge to support these agents effectively. While 5 to 10 percent is the current standard, investment in platforms will likely grow as agent-driven development becomes more prevalent.
Success relies on addressing the “complexity inflection point” early. Delaying until developers face significant infrastructure debt or agents lack context is too late. The objective is to establish a strong foundation before complexity becomes unmanageable. In the agent-driven era, this means building your platform during the growth phase to support both engineers and autonomous agents as you scale.
2Digital: Most platform teams start by building a portal — a nice interface to show leadership and get buy-in. At your organization, you did the opposite: you built the back-end first, with no UI at all. Why?
Dr. Manawadu: A portal is just a framework. Although it can help abstract complexity, particularly for future agentic systems, it is ineffective without solid underlying services. When developers are the main users, starting with a portal is usually not suitable. Engineers prefer command-line interfaces, APIs, and configuration files because these allow direct system configuration rather than filling out forms.
We focused on building robust orchestration using APIs and command-line tools. This approach has proven effective, giving developers meaningful control. With a strong foundation, we can now add a user-friendly interface for those who prefer less technical complexity. By prioritizing substance, we avoided retrofitting support for a superficial interface.
2Digital: In an organization with nearly 100 development teams, each with its own priorities and sense of urgency, how do you decide which use case to address first? How do you determine where to focus before expanding to other areas?
Dr. Manawadu: Start with the primary revenue generators and areas with the greatest customer impact. Prioritize high-throughput teams.
Assess your core enterprise capabilities, such as order management, order-to-cash, or finance reporting. Focus on areas with the highest transaction volumes and customer reach. High-throughput systems are typically outward-facing and internet-exposed, requiring you to address performance, security, and scalability from the start. External customers provide immediate feedback and are less tolerant of latency than internal users.
After validating the platform in these high-stakes areas, expand to lower-risk internal systems with less demanding requirements. Starting with low-stakes tools often leads to costly rework when scaling. Begin where the stakes are highest, demonstrate success, and then broaden your focus.
2Digital: What about platform decay — is it an issue today?
Dr. Manawadu: Yes, many platforms designed for previous environments now hinder developer productivity.
A legacy CI/CD pipeline is a clear example. What was once a solution has become an inflexible, outdated constraint. We favor open-source platforms for their long-term flexibility, but they also carry risks. If maintainers stop supporting a project, the tool deteriorates. Performance declines, community contributions cease, and you inherit an unplanned problem. Developers are left using unsupported tools with no available assistance.
Platform decay is an ongoing challenge that requires proactive management rather than passive monitoring.
2Digital: How far out are you planning? Months? Years?
Dr. Manawadu: We’ve moved from quarterly planning to cycles much shorter than three months, and this timeframe continues to decrease.
The rapid pace of AI means even a two-week development cycle can be outdated by the time a project is delivered. As a result, we have shifted from two-week sprints to one-week cycles for agentic infusion initiatives, and sometimes move even faster. Our strategic planning horizon has also shortened. Quarterly planning is no longer a fixed point; it is now a flexible and continually shrinking process. This reflects the fundamental reality of our current environment.