Building Internal Developer Platforms That Developers Love: From siloed delivery to autonomous, low-cognitive-load teams

Context: “Internal Developer Platforms” with Katharina Sick (Dynatrace GmbH)

In the session “Internal Developer Platforms,” Katharina Sick (Dynatrace GmbH) lays out a pragmatic path from siloed pre-agile release processes to truly autonomous product teams powered by a well-designed Internal Developer Platform (IDP). As a software engineer who moved from feature development into platform engineering, Sick is candid about her motivation: make developers more productive and happier by centralizing, automating, and simplifying the tasks around shipping and running software in production.

She also acknowledges a reality we often see across teams: many developers don’t share a passion for CI/CD pipelines, infrastructure, security, or observability. That’s fine. Platform engineering exists so dev teams don’t have to care about every operational detail. The goal is to remove repetitive friction, create simple self-service flows, and let developers focus on what they’re here for—building features and fixing bugs.

From silos to “You build it, you run it”—and beyond

Sick retraces how we got here:

• Before agile, shipping to production meant handing artifacts from developers to testers, maybe to a dedicated build team, and finally to operations. The result: very long lead times, late discovery of bugs, and hard fixes because issues surfaced after implementation.
• With agile, testing (and, if present, build) moved into the development team. Containerization (e.g., Docker) made builds much easier. The next logical step: operations moved closer to or into the dev team as well. Teams started truly living the “You build it, you run it” principle.
• One external dependency often remained: infrastructure. For a database, a Kubernetes cluster, or cloud services, teams still had to request resources from a central operations/infrastructure group. An IDP addresses that by bringing infrastructure provisioning into the same self-service flow.

The outcome: self-sufficient teams that implement, deploy, operate—and can obtain the infrastructure they need without waiting in queues.

The scaling issue: four teams, ten tools, and three different answers to one problem

“You build it, you run it” empowers teams, but at scale it increases cognitive load and duplication. Sick’s example is familiar: automated dependency updates. Even if the company provides a tool, each team writes its own configuration. End result: three different solutions for the same problem, which complicates onboarding, team changes, and cross-team support.

On top, teams must juggle dozens of concerns—coding, testing, security tools, CI/CD, deployment, observability, infrastructure—and their org’s policies and constraints. With dozens of services and multiple teams, inconsistency and fatigue creep in.

The idea: put an Internal Developer Platform at the center

Sick’s answer is to place an Internal Developer Platform in the middle. Instead of every team rolling their own configuration for every shared task, the platform provides curated, reusable solutions as simple self-service flows:

• One consistent configuration for repetitive tasks (e.g., dependency updates), consumable by all teams and collectively improved over time.
• Unified paths for image publishing, deployments (to Kubernetes, Google Cloud Run, or whatever you use), observability, and security.
• Integrated infrastructure provisioning—removing the last waiting point on central operations.

This isn’t architecture for architecture’s sake. The value shows up in four dimensions: reduced cognitive load, increased autonomy, unified solutions, and standardized workflows (the “golden path”). A service catalog becomes the navigation layer, where developers find ownership, runtime environments, and build status in one place.

Why an IDP matters: tangible benefits for teams and organizations

Less cognitive load

Sick emphasizes that developers are capable of doing all the things. The question is: should they? A platform reduces mental overhead by abstracting and unifying complex delivery and infrastructure steps. That frees attention for features and faster bug fixes—the core work product teams are hired to deliver.

Autonomy and self-service

With an IDP, teams don’t wait for busy operations colleagues. They deploy themselves, and they can provision infrastructure in minutes—whether the requester is an infrastructure admin or a Node.js developer. As Sick puts it: it should just be easy.

Unified solutions instead of variant sprawl

Instead of multiple slightly different answers for the same task, a curated solution works for everyone. That simplifies onboarding, makes team switching easier, and enables teams to help each other. The platform remains open to contributions from product teams back into the shared standards.

Standardized workflows and a golden path

Sick recalls the common reality when joining a new company: you get a repo, start reading code, hit unclear bits, ask around, follow docs with dead links, and spend days before you can start. A standardized, well-documented golden path for tasks like “create a new microservice” cuts that down to hours. This is a core capability an IDP provides: guiding developers along proven paths.

A service catalog as the navigation hub

Who owns a given service? Where does it run—staging, production? Where’s the build? With a clean service catalog on top of the platform, developers no longer spelunk through Git history to find stale ownership info. The catalog consolidates what matters, tailored to the company’s needs.

The anti-pattern: “We built it for months—and developers hate it”

Sick points to a widely discussed Reddit post: “We spent months building this platform. Developers hate it. Help me understand why.” Her read of the discussion: the platform team stacked a bunch of “cool tools,” shipped the whole thing to developers, then declared it done. As expected, that failed. Building a platform in isolation and pushing it onto teams guarantees friction.

How to get it right: treat your IDP as a product

This is the one thing Sick wants you to remember. An IDP is not an internal pet project. It’s a product with real users—developers and adjacent roles. That implies product thinking from day one.

1) It depends—clarify use cases and stakeholders

“It depends” is foundational here. Small orgs or those starting from scratch can adopt an opinionated platform-as-a-service. It hides complexity by embracing a narrow set of opinions and asks you to align with them.

Larger orgs with established processes must identify and engage their stakeholders broadly: developers, architects, product owners, team leads, management, and potentially more. What problems should the platform solve first? What are the requirements around security, compliance, observability, and delivery performance?

2) A clear mission: what problems you solve—and which you won’t

An IDP that tries to be everything to everyone will fail. Articulate scope, goals, and explicit non-goals: which problems you tackle first, how you’ll solve them, and how you’ll measure success. That prevents platform bloat and misaligned expectations.

3) Design for UX, not “RTFM-driven design”

Sick distinguishes a pretty UI from actual user experience. “RTFM” should not be the default mode of operation. The platform needs design constraints and signifiers that lead users to correct choices. Documentation is additive; the platform should guide by design so new colleagues can become productive in hours, not days.

4) Start small: MVP, early adopters, quality over quantity

Bring proven software development lessons into platform engineering: start with a Minimum Viable Product, share it with early adopters, gather feedback, and only then roll it out to a broader audience. Prioritize the quality of features over their quantity.

5) Make the platform observable

Observability serves two purposes: troubleshooting and measuring success. Issues will happen—being observable shortens the time to root cause and fix. It also gives you product metrics: how many users, how many return, how many are one-timers, and what you can do to bring them back.

Sick highlights reusing metrics from the DevOps world—she calls them “driver metrics”—to assess deployment performance. You can use them to compare how much faster teams deploy with versus without the platform.

A concrete walkthrough with Alex: from code to running service

To make the path tangible, Sick walks through a concise example with “Alex.” She shares favorite tools as starting points, but stresses that nothing is set in stone—adapt to your context.

Step 1: Build an image with GitHub Actions

Alex has finished the application and tests. The first platform step is to build a container image and push it to a registry. Sick’s favorite tool here is GitHub Actions. Alex writes a YAML workflow that builds the image and pushes it. For developers, the key outcome is a reproducible, automated build connected to where code changes live.

Step 2: Define the application—Open Application Model (OAM)

Next, Alex defines how the application should be deployed, using a concise, developer-oriented spec. Sick points to the Open Application Model (OAM)—a specification for standardizing how applications are described and deployed.

In her example, Alex describes a “Hello World” web service, references the previously published image, exposes port 8080, and declares a database of size “medium.” “Medium” is a developer-friendly abstraction; the platform team translates it into concrete values. Sick underlines that the minimum configuration is roughly 20 lines of YAML. Additional traits can be added as needed, but keeping the base config small is deliberate.

Step 3: Store the spec in Git as the source of truth

Desired state lives in Git. Alex commits and pushes the OAM spec. From the developer’s point of view, the job is done: image pushed, spec written, spec stored in Git.

Step 4: GitOps sync to Kubernetes—and infrastructure via Crossplane

From here, the platform takes over. A GitOps controller syncs desired state from Git to the runtime:

• Sick’s tool of choice is Argo CD; Flux CD is a valid alternative. Both reconcile the declarative desired state with the actual state.
• Platform teams run on Kubernetes. For resources outside the cluster—e.g., AWS or Google Cloud services—Sick uses Crossplane, enabling the same declarative workflows to manage cloud resources.

Together, Git (desired state), Argo CD/Flux (sync), Kubernetes (orchestration), and Crossplane (infrastructure) form a coherent, reproducible delivery pipeline.

Step 5: Observability—automatic dashboards and alerts

Alex gets an automated dashboard and alerts, so there’s no need to stare at charts all day. Sick mentions Grafana together with an OpenTelemetry collector and “Kepton” to automatically get “Dwarven metrics.” She notes that Dynatrace would be her obvious tool of choice, but she keeps the example in the open-source realm. The takeaway is clear: observability isn’t an afterthought; it’s part of the golden path built into the platform.

The result: “Deployment done. Time to celebrate.”

Practical takeaways for engineering teams

From Sick’s session, we distilled a set of actionable steps:

• Identify and centralize repetitive tasks: dependency updates, container builds, image publishing, standard deployment flows, secrets/policy handling, observability baselines, and infrastructure provisioning.
• Define a minimal authoring model: concise, developer-centric specs (e.g., via OAM) instead of a jungle of low-level flags. Platform engineers map abstractions (like “database: medium”) to concrete configurations.
• Establish Git as the source of truth: version desired state; let a GitOps controller (Argo CD / Flux CD) reconcile it in the runtime.
• Curate golden paths: “Create a new service,” “configure deployment,” “enable observability”—a few dependable flows, well documented. Quality over breadth.
• Provide a service catalog: centralized ownership, environments (staging/production), and build/runtime info.
• Instrument platform telemetry: measure adoption (active users, returning vs. one-timers), accelerate troubleshooting, and quantify delivery improvements with “driver metrics.”
• Engage stakeholders early and often: developers, architects, product owners, team leads, management—align requirements and priorities.
• Deliver iteratively: build an MVP, onboard early adopters, act on feedback, and expand deliberately.

Editorial conclusion: An IDP is a product—build it like one

Sick’s closing message is unambiguous: an Internal Developer Platform is a product with real users. It deserves product discovery, clear mission and scope, UX-centered design, an MVP-first roadmap, and first-class observability—just like any successful customer-facing product.

Technically, the reference path is concrete: build container images (e.g., with GitHub Actions), describe apps in a concise spec (OAM), store desired state in Git, sync it via Argo CD or Flux CD into Kubernetes, manage external resources through Crossplane, and bake in observability with Grafana and an OpenTelemetry collector plus “Kepton.” Organizationally, it requires stakeholder engagement, standardization, and a culture that values autonomy and quality over tool-counting.

The payoffs land directly in developer experience: less cognitive load, real autonomy, repeatable delivery, and a faster, safer path from idea to production. Or, in Sick’s own words, remember the one thing: treat your Internal Developer Platform as a product—so that developers actually want to use it every day.

• 

  

  Indermohan Singh, Platform Developer Advocate bei Dynatrace

  Indermohan Singh von Dynatrace spricht im Interview von seinen ersten Berührungspunkten mit Software Development bis hin zu seiner aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  DevStory: Perihan Rashed, Senior Product Experience Designer bei Dynatrace

  Perihan Rashed von Dynatrace erzählt im Interview über ihren ursprünglichen Zugang zum UX Design, was ihre aktuelle Arbeit beinhaltet und gibt Ratschläge für Neueinsteiger.

  Watch now