Platform Engineering’s Main Goal: Supporting the Developer Experience

At the end of the day, platform engineering is all about building and leading effective teams, paving a clear path with centralized control planes, and supporting the developer experience through and through. Here’s how we can ensure developer experience is prioritized throughout your platform engineering strategy, as well as helpful advice from a few of our previous podcast guests from Livin’ on the Edge.

Master Sociotechnical Systems to Build Strong Teams

Platform engineers have to consider how do human factors interact with technical factors when building ideal teams. The interaction between human and technological considerations gets to the heart of sociotechnical systems design and engineering. That is, what requirements sit at the intersection where hardware, software, people, and community meet?

The book Team Topologies is helpful for building out your organizations. Team Topologies "provides the (r)evolutionary approach required to keep teams, processes, and technology aligned," which relies heavily on considering teams' cognitive load when assigning responsibilities. This fundamentally demands that an organization "evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams."

With this demand as the backdrop, it becomes obvious that there is a need to gain a clear understanding of the operating model, i.e., the sociotechnical system(s) in which the business operates. This involves constructing a team with knowledge of the company's market, its maturity, and its business and technical goals. Then, when building a team around these considerations, ask what the team should look like to serve internal and external customers.

To get started, it is critical to understand where the team needs to go, and to get this understanding, it is essential to know how the team is doing and to look at key metrics within the software development life cycle (SDLC).

Gauge Team Performance: The Value and Limitations of DORA Metrics

Another key aspect of platform engineering is knowing the performance metrics to put behind your team’s efforts. A popular method is utilizing DORA metrics, which look at lead time for changes, deployment frequency, mean time to recovery and change failure rate. These metrics provide much-needed visibility and actionable data for making improvements to performance.

While the full picture painted by the data provides valuable insight, it doesn't tell the entire story. The insight generated does not give you the answers, but it indicates where you should focus. Systematically, look at how we should be fixing these things as engineering leaders in the company and understand what the data tells us in context. These DORA metrics canvas the entire industry and take that into consideration.

These metrics are a snapshot, but make sure you’re benchmarking internally against yourselves to understand what success looks like. Determine what the expected outcome is versus what's considered good. What do you expect to see, and how can you continue to improve?

Design Platforms for the People Using Them

With a clear vision of what a team should expect to see, it becomes easier to focus on internal goals, how to achieve them, and what the developer experience should look like. How should platform engineering consider the platform's users? What does a platform look like that defines and supports the developer experience without completely locking it down?

One trick is to engineer a developer control plane that potentially reduces cognitive load for all developers, provides a paved path for the majority of developers, and enables flexibility for "off-road" excursions for the minority who want to do something "non-standard." More broadly, as Team Topologies describes, the aim is to reduce cognitive load and the need for too much context switching.

Most real-world platform engineering cases bear this out. In one of our previous Livin’ on the Edge episodes, Bo Daley from Zipcar, for example, argued for platforms that wrangle complexity for a better developer experience, "

Another podcast guest, Cheryl Hung, formerly of Google and the CNCF, shared similar sentiments on engineering platforms for developers, "Tools like Backstage or other developer control planes lessen the learning curve and provide a clarity of experience for developers without limiting their ability to seek out and learn platform tools beyond that portal. That is, developers can get access to a dashboard and 95% of what they need is centralized and actionable from the UI. Modular control planes enable enough developer autonomy to do what they need to do and "break the glass" to escape and move beyond that environment if needed, learning platform tools, working from the command line, or requesting specific functionality from the platform teams, when and if needed."

Your platform design should also be flexible; it is not an either/or choice. Many smaller organizations have a finite number of engineers and a need to build platforms quickly. If you don’t have the capacity to build something, you can at least provide a playbook to follow so that other teams don’t run into bottlenecks. Aim to encourage an ecosystem of components and empower your developers to take something and run with it. For smaller organizations, consider building a high-velocity team.

"I'm a big fan of high-velocity teams–where each team member has a specific expertise, and the team collectively covers different layers of the platform. It definitely leads to a more streamlined and effective development process," shares fellow podcast guest and CNCF influencer Michael Levan.

A high-velocity small team might make sense for those wanting to practice practical platform engineering but may need more resources and team size to tackle it. Focus on dedicating individuals to specialize on specific layers such as Kubernetes, implementation, platform capabilities, platform interface, or interactions.

Champion a Developer Who Is a Resource for Others

Not every developer is going to be keen to get their hands dirty, and the ideal platform makes sure they don't have to (you’re aiming for turnkey). For example, maybe a developer needs a new instance, and they should be able to go into a self-service UI, press a button and have an instance up and running in 45 minutes. This will require a lot of automation that may not be in place yet. In the meantime, developers will often be other developers' best friends.

For your developers who want something more than the platform offers by default, they’re welcome to take on these challenges and should be encouraged because they can be a great resource for other developers.

Bo Daley shared a similar experience from Zipcar, "Focusing on the developer experience for DevOps and platform engineers, is about being responsive and having real conversations, observing what developers actually do and the problems they run into. Sometimes a developer is another developer's best resource. Any time you find a developer who seems like they are on the verge of understanding the big picture, invest in that developer because they will help other developers get them across the line in understanding the core concepts. Champion a developer who is a resource for other developers."

Developer Experience: Culture, Education and Experimentation

Introducing a new developer platform fundamentally disrupts organizational culture, which is often a bigger change, and harder to manage, than any technical changes. Cultural change requires education and experimentation. Just as some developers prefer to stay on the paved path, others prefer to experiment. By the same logic, different learners learn at different paces and in different ways. Education, training, and communication will all be integral parts of the "long game" of developing and optimizing a developer platform.

When you’re introducing a platform strategy or a new platform altogether, understand how engineers learn, try to reduce barriers to entry, and make their access to the platform as easy as possible. Your platform team, or whoever is heading up the developer experience priority should be prepared to really help with an inward-facing effort, listening closely to the R&D organization and bringing that feedback in regularly.

In the end: Design Platforms to Reduce Toil & Increase Joy

One of our final previous podcast guests, Kelsey Hightower, shared that empathetic engineering is informed by considering the user experience and the needs of end users when building software,

The same is true when creating internal control planes or platforms for developers. We’re aiming to reduce toil, cognitive load, and pain while giving developers a valuable tool for doing their work. If done correctly, the end user should get a sense that this platform or application was truly created with their needs in mind and even potentially a sense of joy.

Remember, in the end the goal of platform engineering is to ​​reduce developer toil and pain, and maybe even find interesting cases where our platform does more than just reduce pain and instead brings joy!