Platform Engineers: Developers Are Your Customers
If you’re an organization building a platform engineering team, that team’s new customers are application developers. This may seem obvious, but it’s a huge shift from the usual way infrastructure builders think about their job. The shift from delivering a service to managing a platform as a product is significant.
While platforms have been around for decades, the notion of treating a platform like a product grew from the DevOps community, Netflix’s tools group, site-reliability engineering principles, Pivotal (now VMware Tanzu) practices, “Team Topologies,” Thoughtworks and many, many others.
Having studied platform engineering teams that have built and run these platforms over the years, we’ve found that is the organizations that see the most successful adoption are the ones that switch to a product mindset and consider their internal developer teams as their customers. Before we get to what it means to product manage a platform, let’s start with what a platform is.
The Product: Platforms
A platform is the gooey layer of frameworks, middleware, tools and practices that developers use to build and then run their applications. Thoughtworks’ Evan Bottcher defined that gooey layer more precisely back in 2018:
“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.“
You can think of it as everything above the infrastructure layer, whether that infrastructure is Infrastructure as a Service (IaaS), bare metal, virtualization or Kubernetes. In cloud native shops, Kubernetes provides the blinking cursor, sometimes referred to as the “dial tone,” and the platform is all the stuff you pile on top of it so developers can start coding and you can start running their applications in production.
In the past year, internal developer portals (IDPs) have been added to the components of what is considered a “platform.” What an IDP is varies (Gartner has a good go at defining it), but we think of it as all the old-school application life cycle management stuff that’s been missing for many years.
It’s the intranet that developers use to support inner sourcing, discovering other available teams and APIs, tracking their own apps, documentation and, as the name implies, a portal framework for all the information radiators and single-pane-of-glass needs that organizations have.
At the moment, Backstage, the open source project from Spotify, is an incredibly interesting foundation for building IDPs. Backstage is turning out to be a good approach to standardizing what an IDP looks like while making plenty of room for customizations.
It’s intentionally designed to help developers in large companies work better with each other, and it shows. We’ve had good experience with it in VMware Tanzu Application Platform.
There aren’t that many vendor-less diagrams of platforms (I’m happy to show you the VMware one!), but this one from a CNCF working group that’s defining “platform” is pretty good:
So, there’s a quick notion of what a platform is.
The Customers: Developers
Over the past 10 years, we’ve learned many platform engineering lessons. The most important lesson of platform success is knowing who your customers are. In the case of a platform, those customers are the developers.
The first step is to understand what your customers need: what their goals are, how they do their work, the problems they have and what works well for them. That is, you want to start building up an idea and a taste for their developer experience. Also, you need to understand what’s valuable to the organization and other stakeholders (these are often security, governance and FinOps people).
The “you” here is a product manager, also called a “product owner” in some platform teams. Thankfully, product management is a very mature, well-documented role with processes that we can adapt. Syntasso’s Paula Kennedy, one of the early proponents of the platform-as-a-product approach, summarized what a platform product manager does:
A product manager can help define the product strategy. They can help set out a product road map. They can manage the backlog of features that are being delivered, and help prioritize those features with data-driven decisions and validating assumptions.
The product manager decides what features and services are to be included in the platform and when to implement them. To do this, the product manager talks with, researches and understands what developers and other people in the organization need along the path to production.
The product manager is constantly balancing several things, among them:
- What are valuable problems to solve for developers?
- What are the best ways to solve those problems with features in the platform?
- How should features be implemented to meet the needs of their organization as a whole, not just individual developers?
- Identifying risks and their mitigations
All of this is done with not only intuition, but data-driven studies and testing, following a validated design approach.
Go Where the Developer Is
If they’re not already using a platform like Cloud Foundry, most infrastructure teams we talk with are focused on building out Kubernetes as the foundation of their platform. These teams generally follow the same approach, what could be called a service delivery approach.
Service delivery-minded teams gather up the performance and capacity requirements, an idea of how many workloads will run on the clusters over the next few years, security and production needs and so on. They then build out the “kool korporate Kubernetes kloud” and are more or less done. They’ve delivered the service and now just ensure its availability.
Now the developers can come and get all the Kubernetes they want — or as much as their quota allows. This approach is more of a project mindset than a product mindset, so it gives us a good way to think about how you would product manage a platform.
The problem with this project-minded approach is that the developers need more than the blinking cursor of Kubernetes; they need ongoing help to figure out what tools they need on top of Kubernetes. And, more than likely, you won’t be able to predict ahead of time what that stack looks like for the unique needs of your organization. You’ll need to discover and evolve it, test out theories … that is, product manage it.
To do that, you should start with developers and find out what they’re doing day to day. There are two common things to start with: mapping out the path to production and improving developer onboarding.
The path to production is based on a value stream map, which charts all of the activities it takes to go from idea to designing, coding, deploying and getting to the people using the software to deliver value. Here’s a hypothetical example:
Be sure to validate this journey map with actual users! Understanding this value stream map will give the platform team an ongoing understanding of their customers, even though not every activity will be the responsibility of the platform team.
With this path mapped, you can start looking for problems to solve. Many of those problems will be eliminating waste, usually by deleting unnecessary steps, improving collaboration between different groups (often called “shifting left”) and automating processes along the path.
Another common place to start is the developer onboarding process. In one survey this year, about 50% of managers in large organizations said they weren’t satisfied with developers’ onboarding time. So, for example, you might target how long it takes a developer to start using your platform from scratch.
Another version could be to measure how long it takes a new developer to contribute meaningful code, to get through the golden path. I’d recommend just asking your developers what would be helpful by running regular surveys to find and track the elimination of developer toil.
When you start with the developers, you can better product manage what’s in the platform. This is not only picking the best fit for features, but also prioritizing how you spend your time.
Developers usually want the latest and greatest thing — anything that seems both cool and useful. But too much variance across even a hundred or so developers, let alone 25,000, will damage the whole organization.
If you start from the bottom, with just Kubernetes, for example, you might build out more than needed, you might miss adding in a service mesh that works well with your Java developers (or whatever type), and you certainly won’t be able to learn and adapt the tooling and internal developer portal approach you use.
Here are some examples of common problems and features platform teams tackle:
- Standardizing the build pipeline and automating the generation of bills of materials for compliance and security
- Automating spinning up developer environments
- Establishing and improving the internal collaboration tools, like internal developer portals
- Finding ways to package and configure new applications to run on the platform or to reduce the time required to modify an app to run on the platform
- Modifications to the onboarding portal to add more self-service features
- Additional backing services (or “middleware”) such as MySQL, RabbitMQ or Spring Cloud Services
- Standard toolkits for cross-cutting concerns like security, logging, metrics and load balancing
- Integrations with other enterprise systems, especially your internal systems
- Multiple variants of the platform that have different service-level objectives (SLOs) and production characteristics, industry regulations and cloud sovereignty support
One of the most difficult things these teams do is balancing developer desires with organization-wide standards. Developers usually want the latest and greatest thing — be it a programming language, a deployment method (remember when Docker was some weird thing? Or virtualization?), new tools and frameworks … anything that seems both cool and useful. But too much variance across even a hundred or so developers, let alone 25,000, will damage the whole organization — local optimization and all that.
What’ll be valuable are all the customizations of your platform that make developers productive.
This is a problem that we hope product management can handle. When you’re treating developers like customers, you’re more eager to give them what they want and put in the extra work to make it sustainable.
In contrast, if you’re just delivering a set of predetermined services, while you may not intend to do this, it’s easier to slide into “just use the approved enterprise architecture.” I think the cycle of Java application servers simplifying to Spring, JBoss and Rails, developers moving to Docker, and things like WS-* and enterprise service buses falling out of favor show this problem with centralized platforms that fail to treat developers as customers.
Beyond the Blinking Cursor
The thing is, you’re going to end up with a platform along the lines of the diagram above. But that’s not going to be the most valuable part of your platform. How your platform fits into your organization’s practices, needs and even culture (in the DevOps sense) is what’s going to make the platform engineering team valuable.
When you start with the developers, you’ll find the most impactful problems that the platform engineering team can solve. It won’t be cost management, security or even Multicloud Global Control Plane Magic. All of those are needed but, really, they are commodity, industry-standard features, or quickly becoming so.
What’ll be valuable are all the customizations of your platform that make developers productive. And the order in which you build them. A big part of what a product manager does is prioritizing All The Things, and making sure to focus on adding the most value in the shortest amount of time.
Thinking in terms of platform-as-a-product and putting product management in place is the key to good platform engineering in organizations, especially large ones. First step: better get a product manager.
