The Platform Engineering Paradox: Why We're Building Bridges Instead of Highways

• Ezequiel Godoy
Platform Engineering

How to break out of reactive support tasks and drive lasting platform transformation

Imagine you’re a platform engineer who begins each week aiming to deliver transformative, scalable solutions such as a long-awaited self-service portal. Yet you constantly face a fundamental contradiction: your time is consumed by repetitive support tasks—debugging GitHub Actions, clarifying AWS IAM policies, and writing Dockerfiles for others. These continuous reactive tasks keep you stuck solving individual problems and distract you from your primary mission of building impactful, lasting solutions that enable your organization to thrive.

Sound familiar? You’re not alone. This post not only unpacks the ongoing struggle between strategic value and daily support but also outlines actionable strategies and mindset shifts that can help break this cycle.

The struggle between enabling long-term strategic value and getting mired in daily support defines the platform engineering paradox. While engineers aspire to build robust frameworks—the highways for developer productivity—they find themselves continually repairing individual bridges, treating symptoms rather than addressing underlying causes. The result: platform teams deliver less real value than they could.

The State of Platform Engineering: A Reality Check

The latest industry data paints a clear picture of platform engineering’s evolution and challenges. According to recent surveys and reports, platform teams are experiencing rapid growth but facing significant operational hurdles. Nearly 45% of platform teams report they “do not measure” their success at all [1], and 49% of respondents identify reducing reliance on repetitive tasks through better automation as their primary challenge [2].

The numbers tell a sobering story about what platform engineers are actually doing versus what they should be doing:

  • 88% of platform engineers use AI daily, yet struggle to turn experiments into strategic value [3]
  • 47% of platform engineers have over 11 years of experience, with 28% having 16+ years [1]
  • 55% of platform teams have existed for less than two years [1]
  • 80% of software engineering organizations are expected to establish platform teams by 2026 [4]. This statistic highlights a crucial future trend: platform engineering is rapidly becoming the foundation for agile and innovative IT operations. Failing to adapt to this shift poses a significant business risk, potentially leaving organizations without the competitive edge needed to thrive in a digital-first world.

Despite their experience and momentum, platform engineers face a recurring issue: ongoing daily support tasks prevent them from achieving lasting, meaningful platform transformation—the core purpose of platform teams.

The Toil Trap: When Platform Engineers Become Help Desk Heroes

Google’s Site Reliability Engineering research defines toil as “manual, repetitive, automatable, tactical work that lacks enduring value and scales linearly as a service grows.” The impact is significant: some teams spend up to 90% of their time on toil, far exceeding Google’s recommended maximum of 50%.

Here’s what toil looks like in platform engineering:

The Daily Reality Check

The Real Numbers Behind Platform Engineering Toil:

  • 43% of platform self-service capabilities focus on deployment automation [5]
  • 42% handle monitoring and security compliance [5]
  • Manual configuration changes: 3-5 times per day per team
  • Repeated questions: Same issues answered 5-10 times weekly
  • Context switching: Average of 15-20 interruptions daily
  • Documentation ignored: 70% of questions already answered in docs

Common toil patterns platform engineers face:

  • The Dockerfile Debugger: “Can you help me fix this container that won’t build?”
  • The AWS Whisperer: “What IAM permissions do I need for this?”
  • The Pipeline Plumber: “My GitHub Action is failing. Can you take a look?”
  • The Documentation Repeater: Answering the same questions because reading docs is apparently optional
  • The Context Switcher: Jumping between “urgent” requests that could be self-service

The Hidden Cost of Reactive Support

When platform engineers stay in reactive mode, several critical things don’t get done, leading to significant customer-facing effects that resonate with executives.

  1. Golden Paths remain unpaved, which means self-service capabilities never get built, resulting in delays for developers and ultimately leaving customers waiting for new features.
  2. Technical debt accumulates, making the platform increasingly fragile and leaving it vulnerable to outages, thereby affecting customer satisfaction and potentially leading to lost revenue.
  3. Innovation stagnates as new capabilities stay ‘on the roadmap,’ delaying upgrades and potentially causing customer churn.
  4. Developer trust erodes from inconsistent experiences, prompting some to use shadow IT, risking security, and creating inefficiencies that harm the organization’s reputation.
  5. Team morale declines as skilled engineers feel more like tech support than innovators, decreasing productivity and increasing turnover, which is costly to the company. [6]

What Platform Engineers Should Actually Be Doing

According to best practices, platform teams should focus on building ‘Golden Paths’: well-integrated, opinionated templates enabling developer self-service. These approaches provide standard ways to build and deploy software. For example, a critical outage occurred when a service was manually deployed outside the standards, resulting in downtime. With a Golden Path, the deployment would have met best practices, possibly preventing the incident and showing ROI. To implement Golden Paths, a phased approach is recommended:

  1. Identify common use cases and bottlenecks that frequently require support.

  2. Develop standardized templates and guides that incorporate best practices and security measures.

  3. Pilot the Golden Path with a small team to gather initial feedback and refine processes.

  4. Roll out the refined Golden Path to the wider developer community, accompanied by training and resources.

  5. Continuously collect feedback and enhance the paths based on real-world usage to ensure they remain effective and efficient.

The Platform as Product Mindset

The most successful platform teams treat their platform as a product, not a service. This means:

1. Building Self-Service Golden Paths

Self-service actions reduce unnecessary requests, ensure resources follow best practices, and enhance governance through auditable resource creation.

Instead of manually provisioning resources, create:

  • Service scaffolding templates that bootstrap new services with all best practices baked in.
  • Infrastructure-as-Code modules that developers can deploy without needing to understand Terraform intricacies.
  • Automated compliance checks that run before deployment, not after incidents.

2. Focusing on Developer Experience (DevEx)

Platform engineering should minimize time spent on repetitive tasks, reduce cognitive load, and create a positive developer experience. This means:

  • Abstracting complexity without hiding necessary controls.
  • Providing clear feedback loops with actionable error messages.
  • Creating intuitive interfaces that make the right thing the easy thing.

3. Measuring What Matters

Stop counting tickets closed and start measuring:

  • Time to first deployment for new developers.
  • Self-service adoption rate vs. support requests.
  • Mean time to recovery when things go wrong.
  • Developer satisfaction scores through regular surveys.
  • Platform reliability metrics (uptime, performance, error rates).

Cultural Shift: Setting Boundaries with Empathy

The Art of Saying “Not Yet”

Avoid becoming a perpetual help desk by establishing clear boundaries and fostering learning and independence. Begin by recognizing the value in each question, then enhance shared resources such as FAQs. This empowers developers and creates a culture of knowledge sharing and safety.

At the same time, it’s important not to discourage people from asking questions altogether. When team members feel hesitant to reach out—worried they’ll be seen as bothersome or blocked by rigid rules—they may struggle in silence or try risky workarounds. This can lead to unresolved issues, missed opportunities for documentation improvements, and a culture in which mistakes go unreported until they become bigger problems.

The healthiest teams make it clear that questions are welcome, especially when documentation or self-service paths fall short. Celebrate thoughtful questions as opportunities to improve your platform for everyone, and thank people for pointing out gaps in your resources.

  1. “That’s a great question! Let me add it to our FAQ and share the link.”
  • Builds documentation while helping
  1. “This seems like a common need. We’ll prioritize building a self-service solution for this in our next sprint.”
  • Acknowledges the need while setting expectations
  1. “Have you checked our golden path for [similar use case]? It might solve your problem.”
  • Redirects to existing solutions

Making Self-Service Irresistible

Golden paths should be optional, but if you make best practices the most convenient option, developers will follow them. The key is making your golden paths so good that developers choose them over asking for help:

  • Faster than asking: If it takes 10 minutes to ask and wait vs. 2 minutes to self-serve, developers will self-serve
  • Better than DIY: Pre-configured with security, monitoring, and best practices
  • Clearer than documentation: Interactive guides beat static wikis every time

Real-World Success Patterns

The Netflix Model

Netflix built its platform (Wall-E), which allows developers to bootstrap new services easily with security best practices already integrated, turning a compliance checklist into an automated reality.

The Spotify Approach

Their Golden Paths provide opinionated, supported workflows that guide developers from idea to production, reducing the questions platform engineers face daily.

The Google Standard

Google uses the HEART framework (Happiness, Engagement, Adoption, Retention, Task success) to measure and improve developer experience, ensuring their platform teams focus on outcomes, not activities.

Practical Metrics to Track Your Transformation

Start measuring these today:

Toil Metrics

  • Support ticket volume: Should decrease over time
  • Repeat questions: Track and eliminate through automation
  • Time to resolution: Should improve as self-service grows
  • Escalation rate: Lower is better

Value Metrics

  • Golden paths created: Quality over quantity
  • Self-service adoption rate: Target 80%+ for common tasks
  • Developer productivity: Measured through deployment frequency
  • Platform stability: Uptime and reliability metrics

The Bottom Line: It’s Time to Build Highways

Platform engineering isn’t about being a faster help desk—it’s about eliminating the need for one. With high AI adoption but little strategic value realized, the next stage is clear: focus relentlessly on scalable solutions that multiply impact.

Every hour spent debugging someone else’s Dockerfile is an hour not devoted to building the self-service capability that could prevent that issue for everyone. Each time you manually configure an AWS permission, you miss the opportunity to build an automated governance system.

The most successful platform teams in 2025 and beyond will be those that:

  1. Ruthlessly prioritize self-service over support.
  2. Measure impact, not activity.
  3. Build golden paths for Day 2-50, not just Day 1.
  4. Treat their platform as a product, not a service.
  5. Empower developers rather than becoming their crutch.

Your Next Steps

  1. This Week: Start tracking where your time actually goes. Set aside a brief reflection checkpoint at the end of the week to reinforce the habit of daily improvement. Use this time to review where most of your time was spent, identify any surprising patterns, and adjust your approach to improve efficiency. This reflection and adjustment will create a steady path toward continuous improvement.
  2. This Month: Build your first golden path for your most common support request
  3. This Quarter: Establish metrics and share success stories
  4. This Year: Transform from a support team to a platform product team

Remember: your goal is not just to answer developer questions, but to create scalable, lasting solutions that lift the whole organization. Build bridges when needed, but let your focus remain on the highways that deliver true, lasting progress.

Visualize developers seamlessly merging their code onto a frictionless highway of innovation, where every line contributes to a sleek, flowing path toward success. This is the vision of a platform that not only supports but propels an organization to new heights, leaving behind the bumpy roads of constant troubleshooting. Let this image of effortless progress inspire your journey, encouraging each step towards an agile, transformative future.

[1] Platform Engineering Community & Vultr. (2025). State of AI in Platform Engineering 2025. https://platformengineering.org/reports/state-of-ai-in-platform-engineering-2025

[2] Mia-Platform. (2025, January 14). Top 4 Predictions for Platform Engineering in 2025.https://mia-platform.eu/blog/top-4-predictions-for-platform-engineering-in-2025-and-beyond/

[3] Vultr & Platform Engineering. (2025, September 26). State of AI in Platform Engineering Report. https://discover.vultr.com/platform-engineering-state-of-ai-2025-report

[4] Gartner. (2024). Platform Engineering Predictions. As cited in DevOps.com.https://devops.com/platform-engineering-the-2024-game-changer-in-tech/

[5] DevOps.com. (2025, January 30). State of DevOps Report Finds a Rise in Platform Engineering. https://devops.com/state-of-devops-report-finds-a-rise-in-platform-engineering/

[6] Google. (2017). Site Reliability Engineering: Eliminating Toil. https://sre.google/sre-book/

What’s your biggest platform engineering challenge? Are you building bridges or highways? Share your thoughts and experiences in the comments below. I encourage you to share a recent win or obstacle you encountered in your platform engineering journey. These stories can spark a richer, peer-driven discussion and yield valuable, actionable insights for everyone.