Stack Overflow on platform engineering, it's a people (not platform) thing first

Tools are not enough

It’s easy to assume that once a platform team delivers a new service or internal developer platform (IDP), others will simply adopt it, but developers usually stick with what they know. The “build it and they will come mentality” rarely works to break tried and true habits we develop.

Even if their current systems are clunky, they’re familiar. New tools, no matter how well designed, will easily end up ignored.

Often this pattern stems from a lack of understanding. Platform teams may not be close enough to the day-to-day pressures of development to understand where help is needed most and product teams can’t always grasp how new tools will benefit them in the long run. Platforms must build to the user problems coming from product engineering teams and not for the next perceived problem they have.

Embedding to build understanding

One approach which consistently works for my teams is embedding.

By placing platform engineers directly into product teams, it becomes much easier to identify what’s slowing them down and causing cognitive load. Whether it’s long build times, complicated deployment steps or a lack of easy-to-use patterns, platform engineers find themselves shoulder-to-shoulder feeling the pain just as much as the product engineers. For example, embedded engineers should take the time to code, sprint plan, troubleshoot and reflect alongside their peers to fully grasp their customers’ pain points. These interactions often produce insights of friction – where documentation is unclear, tool understanding is low and environments behave inconsistently.

Working alongside developers helps platform engineers build tools that are genuinely useful. More importantly, this approach builds trust. Rather than being seen as a distant team issuing new rules or frameworks, platform engineers integrate themselves as part of the team, shifting the perception to collaboration. As with many adoption stories, the early adopters will radiate the benefits and thus, others are more likely to follow.

Embedding isn’t a long-term solution for every team, especially when resources are tight. It can be hard to get your leadership to adopt this mindset, but it’s important to secure buy-in from executives so you can see the time to value decrease from a better platform environment. No matter the timeline, the insights gained from these early partnerships will inform what happens next. Teams can use what they’ve learned to produce better documentation, standard templates and lightweight automation that reflect how people actually work.

Clear guidance, good defaults and approachable tooling are easier to produce once a platform team has lived the challenges first-hand. Communicating those improvements – through dedicated support channels or even internal branding – helps encourage adoption across the board. Approaching communication from a branding or professional learning technique can reap tremendous rewards if your culture fosters this type of interaction.

Treat internal platforms as products

A useful mindset is to treat internal platforms like any other product. That means putting user problems first, not solutions.

Good product development involves:

• Researching what people actually need, not just what you assume they need
• Testing and refining based on real usage and user feedback
• Measuring success by outcomes, not activity

Internal surveys can help, but they have their limits. Observing teams in action – or soliciting feedback from embedded engineers – often uncovers problems that would otherwise be missed. Like any product, your internal platform needs adoption to succeed, including understanding the user journey, identifying blockers and repeating based on feedback.

Where to invest time

Embedding engineers comes with a cost and it’s important to be selective. Focus on high-impact projects or influential teams that are likely to benefit and share their experiences. Early adopters who see results are often the best way to spread the word. One of the first goals is to enable enough people to cause the platform team more problems in scaling their reach. This is an opportunity to move to the next level.

The focus should shift towards making support more sustainable: developing guidance, building automation and reducing manual work. Partnering with teams responsible for things like data systems or InfoSec can also help ensure platform tools are usable from end to end while being compliant.

Trust, not just tools

One practical technique gaining traction is the use of ‘golden paths’: predefined workflows that represent best practices within the organisation. These are often embedded into tooling such as GitHub Actions, Terraform modules or Helm charts, giving developers a way to follow secure and efficient routes to production without needing to configure everything from scratch. Golden paths help reduce variability across teams and ensure consistent outcomes, particularly in complex, multi-cloud or regulated environments. In the early phases, it’s important to be okay with simple tools such as documentation and static sites. Information is more powerful than a flashy tool when adoption isn’t guaranteed yet.

Stack Overflow’s O’Connor: At its best, platform engineering allows developers to work more efficiently by owning DevOps without the cognitive load it brings.

At its best, platform engineering allows developers to work more efficiently and confidently by owning their DevOps without the cognitive load it brings.

But that doesn’t happen through tooling and code alone. It requires trust, shared understanding and thoughtful collaboration. So, for any platform organisation investing in this space, the key question isn’t only “what are we building?” but “who are we building it with?”

Ultimately, technology matters, but it’s the relationships you build that turn good ideas into something users will turn to as a meaningful tool every day.

*A note on moving towards scalable support

A hot topic in the Platform Engineering area is the “need” for an internal developer portal (IDP). My guidance on embedding is an engineering team’s first steps to get adoption which means there is no need for an IDP.

Only once embedding has yielded a substantial amount of tools or services which allow teams to own their DevOps, the next problem which occurs is scaling the ability to serve all customers within the organisation. The next step is to collaborate with your product engineering teams to define the requirements for an IDP which can scalably solve working with the entire engineering organization’s product teams. These portals are increasingly being adopted to centralize access to tools, templates, environments and documentation. According to a 2024 CNCF survey, 60% of organisations with platform teams have implemented an IDP to standardise workflows and reduce the time developers spend on infrastructure-related tasks.

These platforms often incorporate service scaffolding tools like Backstage or custom-built command-line interfaces (CLIs) that allow developers to spin up new microservices in minutes, using pre-approved configurations for security, observability and deployment. Much of the tooling found to support these IDPs come from the embedding work done in the adoption phase. Portals provide the scaling, the platform team provides the tooling and abstractions for the portal to use which maintain internal engineering practices and compliance.