Generative AI
Building an AI-first platform strategy
Disclaimer: AI-generated summaries may contain errors, omissions, or misinterpretations. For the full context please read the content below.
When I started working with internal platform teams, I kept seeing the same pattern.
Pipelines were delivered, shared tooling put in place, documentation published. And still, the friction remained.Teams prioritized delivery over enablement, measured adoption instead of maturity, and shipped outputs rather than outcomes. Few could describe what “good” looked like, or how to measure progress over time.
The ambition was clear: reduce cognitive load, improve developer experience, enable delivery at scale. But without a structured way to understand the current state, those ambitions stalled.
Today, with AI-assisted development reshaping engineering, closing this gap has never been more urgent. The 2025 DORA Report highlights platform quality as a key differentiator: high quality platforms act as force multipliers, accelerating delivery, improving well-being, and amplifying AI’s impact across the organization.
That made me pause and ask:
What does “good” really mean for a platform?
How do we create a shared baseline so teams are aligned on what good looks like?
And how do we turn that baseline into deliberate, meaningful evolution?
Most frameworks I found focused either on delivery metrics like the well-known “four key metrics” or on strategic principles. Useful as they are, few connect the two, leaving platform teams without a clear way to see where they stand, decide what truly matters next, and move forward with evidence.
Eventually, I turned to Thoughtworks’ Engineering Effectiveness (EE) Framework. It gave me the underlying dimensions to orient my thinking — and from there, a structural way of finding direction began to emerge.
To build on that emergence, I made the mindset explicit.
A mindset for finding direction
At its core, the mindset is simple: make the dimensions of platform work concrete and distinguishable so that “good” becomes defined, comparable — not vague or subjective. This clarity gives teams:
A shared language and a clear view of uneven capabilities and hidden gaps
A sharper sense of where investment will matter most
A shift from checkbox claims (“We have observability”) to nuanced evaluation (“How reliable is it and how do we know?”).
Making the mindset tangible
With the mindset established, I expressed it through the following tangible structure:
Capability domains: technical, organizational, and experience-driven dimensions of platform
Capability subdomains: practical focus areas tailored to platform realities
Maturity levels: a five-point scale describing how capabilities evolve from inconsistent, ad-hoc efforts to strategic, self-sustaining enablers of developer and business goals.
This structure is not rigid. Together, the domains, subdomains, and maturity descriptors create a shared language for describing platform effectiveness.
The table below provides a summary view : outlining the capability domains, example subdomains, and how maturity typically evolves.
Summary view
| Domain | Example subdomains | What maturity evolution looks like |
Platform engineering capabilities |
Infrastructure automation, CI/CD, observability, security foundations |
From ad-hoc scripts → automated, trusted, self-service platforms that establish organizational standards and resilience. |
| DevEx and productivity accelerators | Self-service enablement, starter kits, SDKs, workflow insights, AI-assisted delivery enablement | From scattered tools → coherent, reliable developer experience that accelerates delivery and supports business outcomes. |
| Enterprise testing strategy and enablement | Contract testing, test environments, data management | From unreliable QA → robust, scalable testing infrastructure embedded in delivery flows, ensuring predictable quality and faster cycles. |
| Domain driven and Cloud Architecture Enablement | API strategies, cloud guardrails, service boundaries, adoption of Cloud Managed Services | From reactive fixes → aligned, intentional architectural patterns that evolve with business and product strategy. |
| Scaling knowledge and leadership | Docs, inner sourcing, communities, onboarding | From tribal knowledge → discoverable, shared, continuously evolving knowledge that grows organizational capability. |
| Operating model alignment and governance | Team structure, ownership, impact metrics, platform governance and shared responsibility | From unclear responsibilities → aligned, measured, accountable decisions that shape investment priorities and organizational direction. |
Turning structure into practice
Turning structure into practice means using it to clarify your specific context. A few patterns tend to matter most:
Grounding in context
The structure is most effective when it reflects the platform’s real purpose and sphere of influence. Different platforms emphasise different domains, and not all capabilities carry the same weight. When these boundaries are made clear — what the platform owns, how it operates, and why it exists. Then the conversation shifts from abstract ambition to practical focus. This often reveals both current limits and future opportunities.
Build an honest shared view of the current state
The structure works best as a lens for shared understanding, not as a scoring mechanism. It helps surface uneven capabilities, reliability gaps, accumulated cognitive load, and recurring friction in the developer experience. The aim is a grounded view of how the platform operates today — based on lived experience rather than aspiration or assumption.
Focus attention where uplift will amplify flow
Not every gap deserves equal attention. The most meaningful improvements are often the small, targeted ones that shorten feedback loops, reduce manual effort, strengthen reliability, or smooth a critical workflow. These patterns highlight where uplift can create outsized impact on delivery and developer experience.
Make improvement deliberate and incremental
Sustained progress comes from intentional focus, not large-scale transformation. Concentrating effort on a few capabilities at a time, shaping a shared view of what “better” means, and creating space for steady movement tends to unlock more momentum than sweeping change.
Revisit and recalibrate as context evolves
Platform work moves with the organisation. Teams grow, dependencies shift, and AI-assisted development reshapes demand. Keeping the structure aligned with day-to-day reality ensures direction stays relevant and maturity becomes part of ongoing work, not a one-time exercise.
What the practice reveals
Once the structure is applied in practice, two complementary views emerge. Together, they help benchmark where the platform stands and create a shared understanding of its health:
The Cumulative View aggregates maturity across multiple platform teams. It highlights overall patterns, capability gaps, and alignment, especially useful for strategic and leadership discussions (see example radar view below).
The Granular View focuses on specific subdomains within each team. It helps identify friction points, understand maturity progression, and prioritize improvements, particularly useful for operational planning and team-level retrospectives.
The following are three maturity scenarios, drawn from our collective field experience across diverse industries and platform contexts. These patterns are illustrative, not prescriptive. They highlight typical focus areas rather than fixed recommendations.
Cumulative view: Platform organization maturity patterns
| Maturity scenario | Legacy enterprise— strength in depth, friction in flow |
Scaling startup — velocity without guardrails | Product-to-platform shift — balanced evolution |
| Pattern | Strong in infrastructure and architectural control, but constrained by monolithic systems, manual processes, and fragmented toolchains. Developer experience suffers from heavy governance and slow feedback cycles. Stability comes at the cost of change velocity. | Rapid delivery and strong CI/CD foundations drive speed, but governance, security, and quality practices lag. Agility outpaces structure, creating environment drift and inconsistent developer experiences. | Balanced maturity across domains, supported by intentional investment in platform-as-a-product practices. The organization is shifting from bespoke delivery toward scalable, self-service platforms with clear ownership and metrics. |
| Recommended leadership and team focus | Leadership focus: Reduce cognitive load by consolidating fragmented toolchains and shifting governance from control to enablement. Team focus: Modernize CI/CD, observability, and deployment automation to improve developer flow.
|
Leadership focus: Strengthen platform governance through automation and shared quality practices before scaling further.
|
Leadership focus: Sustain cross-team alignment and make platform impact measurable through clear metrics and product thinking. Team focus: Broaden and deepen platform adoption, strengthen feedback loops, and enhance developer self-service capabilities with product teams. |
Maturity Radar
These radar charts illustrate typical maturity patterns observed in practice; higher levels (“Scalable” and “Strategic”) remain aspirational and are not shown here.
Finding direction, building momentum
Platform maturity is not a destination. It shifts with context, scale, and the realities of day-to-day engineering. Every platform evolves on its own path. The goal isn’t to hit a maturity level, but to create the conditions for progress to keep happening.
In this blog post, the mindset and a tangible way of expressing it makes those shifts visible: showing where things stand, where friction accumulates, and where a small uplift can unblock meaningful movement. When teams can see their reality clearly and act on it with intent, momentum becomes a natural outcome.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
