Developer Control Planes: A Platform Builder's Point of View

The unicorns of the tech world generate a lot of buzz in the cloud-native landscape. But the workhorse users who adopt cloud-native technologies slowly where it makes commercial sense don't get quite the same level of attention. Weaving cloud-native technology, not just into legacy systems that deliver on a business's core mission, but also into risk-averse commercial organizations is no easy feat.

Read on for the key takeaways from their conversation, or listen to the full podcast:

Make it make sense

Build the business case for investing in a internal development platform (IDP) or developer control plane (DCP)

‍While it might be obvious to developers and their managers that a centralized control plane could increase developer productivity and focus, it's not always obvious to other stakeholders. Chances are, you're going to have to prove that a developer control plane can unlock developer effectiveness and efficiency by building a business case.

Alan emphasizes the importance of early stakeholder buy-in, with executives likely being the most important group with which he communicated. They won't have time to read a lengthy document, so the best bet is something like an executive summary showing what you're planning, the projected value, and what complications you foresee. "If you think of the venture capital slide deck, that's basically where we started." Alan shares, "Be explicit about what the problem is, how you are going to solve it, this is what we need."

From this starting point, Alan's team was given the green light to move forward with their developer platform, and created something like an 'ask deck', as outlined in the book, Technology Strategy Patterns by Evan Hewitt. "What we are looking for at each stage is permission to take the next step. First, can we do the research? Then, can we do a proof of concept? Next we delivered an UI they could see and understand. This incremental approach gave us a lot of freedom to move forward and experiment and try building the platform without attempting to do it "behind the scenes". At each step, we had transparency and alignment.

If you build it…

Make the most of working with limitations

If you build an IDP/DCP, don't succumb to the paralysis of too much choice. The vast CNCF/cloud-native landscape is a good example of the kind of sprawl that can be paralyzing. Alan describes how he worked with and used the limitations imposed on his team when building their developer platform, basing what it would contain on core business needs that mapped to tools that were actually available.

"Constraints really help you fill in the details in a better way. It helps you get creative," Alan says. "You're really able to push yourself to come up with a solution that could even be better because you're lacking the options that you would otherwise be tempted to pursue if you had all the money and time in the world."

It is also helpful here to remember that context is key: a tool or abstraction that would be ideal for one organization won't necessarily be right for another. It is critical to understand organizational goals and what skills will get you there.

Eliminate toil

Make setting standards and direction a priority

‍With the right abstractions, developer cognitive load and "toil" should naturally lighten. The developer experience is, hopefully, usable and useful. Part of this is being careful about the tools (see "choosing the right abstractions") and platform itself, and never taking shortcuts on internal tools.

Another part, in commercial settings like Alan's, is standardization. "We know there are low-level or common problems, and we need to standardize around those trainable things so they don't become bottlenecks. One way we do this is in our API development. We have a template generator via the Swagger Codegen. When someone creates a new app, they receive the community standards automatically. We've wired it up as much as we can so that it doesn't require configuration. There are still things to figure out, but what we are striving for is keeping standards in place and up to date so that developers focus on higher-level business problems versus the low-level infrastructure and how things connect or other basic things that we have solved already."

Make it human

The “hospitality” focus‍

Remember that all of this is human-first. Alan explains, "We shine [as a business] because we are focused on our niche, which is the veterans of the armed services. We focus on the VA benefits that allow veterans to put zero-down on a house. The program is complicated, and we want to help vets get through the process without stress. We strive to automate everything we can and otherwise put a human touch on the home-buying experience."

And, as Alan continues, that human touch extends to the developers creating these products. Developers creating for humans are humans, too, which touches on the empathetic engineering concept Kelsey Hightower discussed in a previous podcast as well as the mechanical sympathy concept Nicki Watt highlighted. While Alan also reflects on mechanical sympathy, he cites Twilio's "hospitality" focus as an example of creating a developer experience (and platform) that a developer would like to use. That is, removing all the cruft, unblocking the road, taking away challenges, and paving the path. While Alan claims this is a work in progress, he feels that the platform can achieve something akin to a “white-glove”, hospitality-oriented experience that inspires developers to adopt and use it.

‍Make it matter

Share the why as well as how

‍Documentation and training are both vitally important and necessary tools for getting developers up to speed and advancing their skills and even careers. However, while the standard developer docs often are "wonderful to achieve a goal, they don't explain why we're making the platform or the reasons why we built it or other initiatives." Alan discusses the importance of storytelling and making the "why" matter. "Not understanding why frustrates developers, and in fact, a lot of us. Why are we doing a certain thing? Sometimes we're just dictated to and told 'this is the way to do it'. Instead we want to tell a story that explains, 'Here's why you're part of the journey. Here's how you're going to contribute to the journey. And in the case of the developer platform, here's how it's going to improve your experience'."

Throughout all of these activities, Alan emphasized: "Communication is a really high-leverage activity. Half the battle is building the product and then the other half is communicating the value and getting people to use it and feel heard when they do. Whether or not we ultimately act on feedback and ideas, a big lesson learned was that all the stakeholders wanted to feel heard."