Executive Overview

At the recent KubeCon & CloudNativeCon Europe conference, enterprise engineering leaders Eugenia Bergman and Hagen Tonnies delivered a compelling presentation detailing their organizational and architectural journey. Their core thesis challenged the traditional, output-driven software delivery model: they argued that engineering organizations must fundamentally shift from project-thinking to product-thinking when constructing internal platforms.

Traditionally, platform engineering has been plagued by a project-oriented mindset. Success was measured by delivery metrics—shipping features on time, executing according to initial scopes, and checking items off a roadmap. Bergman and Tonnies exposed the inherent flaws in this approach, demonstrating how treating internal platforms as living products radically alters how teams plan, collaborate, prioritize, and measure success. By implementing a producer-consumer model, establishing clear API-like contracts, redefining what it means for a capability to be "done," and securing enlightened leadership support, these engineering leaders transformed their platform from a cost center into an adopted, high-value ecosystem.

This report explores their journey in depth, examining the structural changes, organizational shifts, and cultural philosophies required to make internal platform engineering a true product discipline.

Detailed Chronology: The Evolution from Output to Outcome

The transformation described by Bergman and Tonnies did not happen overnight; it was a deliberate, evolutionary process born out of operational friction and a growing realization that old paradigms were failing to scale.

Phase 1: Recognizing the Limitations of Project Delivery

In the early stages of their platform journey, success was defined much like it is in traditional IT and software outsourcing environments. A feature or project was deemed "done" when it was delivered according to the pre-approved scope and timeline. Teams would gather requirements, build the capability, hand it over, and move on to the next project on the backlog.

However, this output-driven model quickly revealed its limitations. Features were successfully shipped, yet internal developer adoption remained sluggish. Platforms grew bloated with capabilities that technical teams thought developers should want, while the actual day-to-day friction points experienced by product engineering teams went unaddressed. The metrics of success—velocity and deployment frequency of the platform team—bore little correlation to the actual productivity gains of the internal consumers.

Phase 2: Introducing the Producer-Consumer Model

To untangle the web of ad-hoc dependencies and communication bottlenecks, Bergman and Tonnies introduced a structural paradigm shift: the producer-consumer model. In this framework, any team that provides an infrastructural capability, service, or tool is designated as a "producer," while any team utilizing that capability is a "consumer."

This clear delineation helped make architectural and organizational dependencies explicit. Instead of treating internal interactions as fuzzy, collaborative efforts driven by goodwill, they began treating them like formal APIs. Bergman highlighted a practical heuristic that emerged from this shift:

"If two teams require a recurring meeting to coordinate their work, the interface between them is likely not well defined."

By replacing meetings and intermediaries with robust interfaces and contracts, the organization successfully reduced coordination overhead. Teams no longer needed to sync on every minor detail; instead, they relied on well-documented, stable boundaries. This contract-driven approach empowered teams to make localized decisions, dramatically accelerating delivery cycles across the board.

Phase 3: Redefining "Done"

Perhaps the most critical inflection point in their journey was rewriting the definition of "done." Under the old project-thinking paradigm, a feature was finished when the code was written and merged. Under the new product-thinking model, the definition was expanded to encompass the entire lifecycle of utility and adoption:

"A capability is done when it’s integrated into the platform ecosystem, documented and understandable, supported and operable, and actually used by its intended consumers."

This redefinition forced the platform team to look past the deployment pipeline and consider the developer experience (DevEx) end-to-end. Building the feature was now only half the battle; ensuring it was discoverable, frictionless, and actively relied upon became the true measure of completion.

Supporting Context & Metrics: Measuring Value and Managing Error Budgets

Transitioning to a product-led platform model requires fundamentally different approaches to metrics, feedback loops, and organizational risk tolerance. Bergman and Tonnies shared how they adapted these elements to support their evolving ecosystem.

Tracking Adoption: Moving from Assumptions to Empirical Data

In a project-oriented culture, teams often assume that building a feature equates to creating value. Bergman emphasized that in a product-oriented culture, usage must be deliberately measured rather than assumed.

The platform team tracks adoption through a hybrid of operational and product-oriented signals:

  • API Request Volumes: Monitoring raw utilization to see if services are being called.
  • Active Consumers: Tracking who is using the capabilities across different business units.
  • Provisioning Activity: Measuring how frequently environments, storage, or infrastructure topologies are created.

Importantly, Bergman noted that the telemetry timeframe varies wildly depending on the capability. Services like storage provisioning or quota management yield immediate adoption signals almost instantaneously upon release. Conversely, foundational networking or infrastructure topology capabilities are integrated less frequently and may take several weeks or multiple planning cycles before engineering teams fully incorporate them into their workflows.

The Role of Leadership and the "Organizational Error Budget"

A product transformation cannot succeed through bottom-up grassroots efforts alone, nor can it be forced via top-down dictation. Hagen Tonnies stressed that leadership support was critical—not as a micro-managing mandate, but as an enabling force that created alignment, trust, and psychological safety.

Crucially, the organization recognized the need for an "organizational error budget." Just as software systems require error budgets to balance reliability with velocity, organizations need the space to explore new approaches, learn from missteps, and refine their direction without facing immediate pressure to meet rigid, short-term project milestones.

"That safety allowed us to treat the transformation as a learning system, where progress comes from understanding the gap between expectation and outcome and continuously improving based on that signal," Tonnies explained.

This protected space enabled teams to engage constructively with senior stakeholders, carefully balancing the tension between rapid innovation and long-term enterprise responsibility.

Official Statements: Insights from the Post-Conference Interview

Following their presentation at KubeCon & CloudNativeCon Europe, InfoQ sat down with Eugenia Bergman and Hagen Tonnies to dive deeper into the mechanics of their platform transformation. Below are expanded insights from their interview regarding team collaboration and adoption tracking.

On Producer-Consumer Collaboration and Team Topologies

When asked how teams collaborate as producers and consumers, Hagen Tonnies detailed the structural evolution of their internal organization:

"Our collaboration model between teams as producers and consumers is still evolving, but it is increasingly structured around clear ownership and intentional interaction points. We took inspiration from Team Topologies to learn about these concepts when we formed new collaboration efforts."

Tonnies explained that product areas are typically represented by a product owner and a lead engineer. These representatives engage directly with their counterparts in other domains to align on shared capabilities through regular check-ins aligned with sprint cadences.

"A key focus is making these relationships explicit—understanding the promises a producing API or capability makes, as well as the obligations on the consuming side, and ensuring both are grounded in real use cases."

To combat the natural friction of moving from implicit coordination to explicit, contract-driven collaboration, the organization focuses heavily on the "80% path"—identifying common use cases to deliver consistent value without falling into the trap of over-engineering for edge cases. Additionally, they introduced Scrum Masters and product operating managers to facilitate conversations and support enablement, helping engineers and product owners build competency in a product-oriented, API-driven ecosystem.

On Proving Value and Internal Evangelism

Addressing how they track and validate platform utility, Eugenia Bergman reiterated that value is defined by adoption:

"One of the key lessons from our journey was that delivering a feature is not the same as delivering value. A capability is only truly ‘done’ once it is adopted and relied upon by its intended users."

Adding to this, Hagen Tonnies highlighted that great products do not sell themselves—even inside the enterprise:

"Done requires active enablement—clear storytelling, education, and even internal evangelism—so teams know when and why to use it."

Future Outlook: The Next Frontier for Internal Platforms

The transition from project-thinking to product-thinking is not a destination with a definitive finish line; it is a fundamental cultural and operational evolution. As organizations scale their cloud-native estates, the complexity of internal developer platforms (IDPs) will only increase.

Looking forward, platform teams that cling to legacy project management methodologies will likely find themselves building sophisticated systems that developers actively bypass or find frustrating to use. Conversely, organizations that adopt the playbook outlined by Bergman and Tonnies—treating internal developers as customers, codifying service boundaries through explicit APIs, expanding the definition of "done" to include active adoption, and maintaining an organizational error budget for experimentation—will foster resilient, high-velocity engineering cultures.

Ultimately, the success of platform engineering will no longer be judged by what was built, but by how well it is used, understood, and leveraged to accelerate business value.