Platform Engineering Teams Are the Foundation - Intelligence Platforms Are the Visibility Layer

General
1

Two Gartner predictions are deeply connected:

  1. 80% of large organizations will have platform engineering teams by 2026 (up from 45% in 2022)
  2. 50% of software engineering organizations will use intelligence platforms by 2027 (up from 5% in 2024)

These aren’t separate trends. Platform engineering creates the foundation that makes intelligence platforms valuable.

Why Platform Engineering Comes First

Intelligence platforms measure what happens in your engineering systems. But if those systems are fragmented:

  • Different teams use different CI/CD tools
  • No standardized deployment patterns
  • Inconsistent observability across services
  • Manual processes that aren’t instrumented

…then intelligence platforms have nothing coherent to measure.

The Platform Engineering Value Stack

Layer 4: Intelligence Platform (visibility, measurement, insights)
         ↑ depends on
Layer 3: Developer Portal (self-service, golden paths)
         ↑ depends on
Layer 2: Platform Services (CI/CD, infrastructure, security)
         ↑ depends on
Layer 1: Infrastructure (cloud, containers, networking)

Organizations trying to skip to Layer 4 without Layers 1-3 get dashboards of inconsistent data.

The Maturity Model

Stage 1: Fragmented (No platform team)

  • Teams build their own tooling
  • Intelligence platform shows inconsistent or missing data
  • No organizational view of engineering health

Stage 2: Foundational (Platform team exists)

  • Standardized CI/CD and deployment
  • Intelligence platform can measure deployment frequency, lead time
  • Team-level visibility emerging

Stage 3: Product-Minded (Platform as product)

  • Self-service developer portal
  • Golden paths for common patterns
  • Intelligence platform shows full DORA + DX metrics
  • Organization-level visibility with team drill-down

Stage 4: Strategic (Platform + Intelligence integrated)

  • Business metrics connected to engineering metrics
  • Predictive capacity planning
  • Investment allocation optimization
  • Real-time decision support

The Investment Sequence

I’ve seen organizations waste intelligence platform licenses because they weren’t ready. My recommended sequence:

  1. Year 1: Platform team + foundational infrastructure (6-8 engineers, $800K-$1.2M)
  2. Year 2: Developer portal + standardized practices (add 2-4 engineers, $400K-$600K)
  3. Year 3: Intelligence platform + business integration ($150K-$300K software + integration work)

Trying to compress this timeline usually fails. The foundation work takes time.

Where is your organization in this maturity model?

2

This maturity model matches what I’ve seen. The organizations struggling with intelligence platforms almost always skipped platform engineering fundamentals.

Building platform teams that can support intelligence platform adoption:

  1. Hire for product thinking, not just infrastructure skills: Platform engineers need to understand developer workflows, not just Kubernetes. The best platform teams include former application developers.

  2. Start with internal customers, not tools: Before buying an intelligence platform, your platform team should be doing manual measurement and user research. What are developers actually complaining about?

  3. Build instrumentation into the platform from day one: Every platform service should emit metrics that intelligence platforms can consume. Retrofitting observability is expensive.

The organizational design challenge:

Platform teams often report to infrastructure/ops leadership. Intelligence platform adoption is driven by engineering leadership. This creates misalignment:

  • Platform team optimizes for reliability and cost
  • Engineering leadership wants developer productivity data
  • Neither owns the full picture

My recommendation:

Platform engineering should report to engineering leadership (not ops) if you want intelligence platform adoption to work. The platform team’s KPIs should include DXI, not just uptime.

The Stage 2 → Stage 3 transition:

This is where most organizations get stuck. They have a platform team doing good work, but:

  • No self-service (developers still file tickets)
  • No golden paths (every team invents their own patterns)
  • No developer portal (discoverability is tribal knowledge)

Without Stage 3 maturity, intelligence platforms show fragmented data because teams are doing things differently.

3

The “platform as product” framing is exactly right. As someone who’s spent my career in product management, I see the same patterns:

Applying product thinking to internal platform and intelligence tooling:

  1. Define your user personas: Not all developers have the same needs. A frontend engineer setting up a new React app has different friction points than a data engineer building pipelines. Your platform and intelligence tools should serve multiple personas.

  2. Measure adoption, not just availability: A platform team that ships features nobody uses isn’t succeeding. Track:

    • Feature adoption rates
    • Time-to-first-value for new developers
    • Self-service completion rates (how often do devs file tickets vs. solve problems themselves?)

  3. Run regular user research: Interview developers quarterly. What’s still painful? What’s working? The intelligence platform can show you metrics, but it can’t tell you “why.”

  4. Build a roadmap based on impact: Prioritize platform investments the same way you’d prioritize product features. What will have the biggest impact on developer productivity?

The portal problem:

Most developer portals fail because they’re built as documentation repositories, not products. A good portal:

  • Guides developers through golden paths (not just documents them)
  • Shows personalized recommendations based on the developer’s context
  • Integrates with intelligence platform data to show team-specific insights
  • Has a feedback mechanism that actually gets responded to

The intelligence platform integration:

The intelligence platform should be embedded in the developer portal, not a separate destination. When a developer opens the portal, they should see:

  • Their team’s current metrics vs. goals
  • Recommendations for improvement (“Your PR wait time is 3x average. Consider these review workflow changes.”)
  • Links to self-service solutions for common problems
4

Scaling platform and intelligence capabilities across the organization is where we hit our biggest challenges.

The financial services context:

In regulated industries, the maturity model has additional requirements:

  • Stage 2 must include audit trails and compliance automation
  • Stage 3 must include policy-as-code and approval workflows
  • Stage 4 must connect to risk management and regulatory reporting

We couldn’t adopt Cortex (our preferred developer portal) until we added custom approval workflows for production changes. That added 4 months to our timeline.

Scaling challenges we encountered:

  1. Multi-tenancy: With 15 product teams, each wanted their own configuration while sharing the platform. Building the right abstraction layer took longer than building the initial platform.

  2. Federated vs. centralized: We started centralized (platform team controls everything). Scaled teams wanted autonomy. We moved to federated model (platform provides guardrails, teams customize within bounds). This required intelligence platform changes to support team-level views with org-level aggregation.

  3. Legacy systems: Not everything runs on Kubernetes. Our mainframe processes 40% of transactions. The intelligence platform needed custom integrations to include legacy system metrics. Without this, we had a blind spot covering almost half our business.

The 3-year investment sequence in reality:

Year Planned Actual Variance
1 $1M $1.4M Legacy integration costs
2 $500K $700K Multi-tenancy rework
3 $200K $350K Custom compliance integrations

Total: $2.45M vs. $1.7M planned. Still worth it - the ROI has been positive - but budget for 40-50% overruns in regulated environments.