Developer Experience and Developer Platforms - part 2
Developer Experience, Platforms, and Platform Engineering
Introduction
In the previous post, we talked about the importance of Developer Experience (DevX) to the software developer and the organization. We ended with the idea that a Developer Platform is the embodiment of the DevEx concept. In this post, we will delve deeper into the definition and meaning of “Developer Platform”, the role that a product-based approach plays, and the emerging role of Platform Engineering.
“Platform” as a product for developers
“Platform” is a term that has an even more rich history and ambiguity as “Developer Experience”. It seems that a lot of different things over the years have been called “platforms”. You have “core banking platforms”, “storage platforms”, “API Platforms” etc. Sometimes “platform” seems to refer to any “big” system or system of systems, but more often than not it refers to something that can be used to create something else.
In terms of our discussion, the definition given in 2018 by Evan Bottcher from Thoughtworks in the article on Martin Fowler’s blog site seems to resonate the most.
“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”.
The key part of Evan’s definition is “product”. One important thing missing from that definition is the word “process.”
The developer is the customer of processes that an organization establishes for creating software products. The tools and all the other technologies are physical embodiments of the process. These processes are also what create the organization’s engineering culture, but that’s a subject of a different blog post. Let’s just say that Developer Experience and Engineering Culture are related.
So then, processes used for developing software are part of a product called “platform” together with tools, APIs, services, knowledge and support.
Why is the product aspect so important? Because as we have learned from UX, best UX is achieved when organizations focus not on systems, but on products. The same is true here.
If the Developer Platform is treated like a product and is managed like a product then the focus will be on the DevX of using that Platform, and on the long-term value that the product brings. If treated as a product, it will be possible to come up with product-like metrics to measure its success and also make sure that as a product it satisfies the requirements that the organization may have around security, compliance. etc.
As with any product, cost is a factor that the product manager of the platform needs to consider. There are many different tools and solutions out there that can be used, but they range from free ope- source to very expensive. What may work for a massive enterprise IT shop that is able to negotiate significant volume discounts, may not work for a smaller team. Look at SaaS options and Cloud charging models where you pay only for what you use.
This approach has already led to the creation of a new field called “Platform Engineering”. Again, the term has existed for some time, but recently has acquired a fairly precise definition. You know that when Gartner includes it in their “Top Strategic Technology Trends” it’s gone mainstream. According to them, Platform Engineering is:
“The discipline of building and operating self-service internal platforms — each platform is a layer, created and maintained by a dedicated product team, designed to support the needs of its users by interfacing with tools and processes”
Nice definition, and has a reference to “products”, except we would argue that it’s probably better if these product teams work in collaboration as part of the “larger” platform product united by common principles and vision.
Where to start
It is important to understand that a Developer Platform is a long-term investment. It is not something that can be built once and then it will remain unchanged forever. Software engineering practices evolve over time, technology stacks change, even the requirements of the organization may change with the change in the business environment. Treating it as a long term product investment will ensure that Platform doesn’t become “stale”.
Having a Product Manager (or Product owner) for the platform is key. This product manager will do user research, understand requirements coming from different types of “personas” relying on the platform and then will build the product and most importantly iterate and improve based on the feedback coming from the users. It is also best if the Product Manager relies and works with an Engineering community of practice (CoP) that jointly exercise the governance and stewardship of the Developer Platform.
We suggest starting with the process. Tools a plenty and chances are you already have all the toys.
Identify someone who will act as a Product Manager for the Platform
Define the stakeholders - developers, operations, security.
Run VSM of the delivery process from idea to production. Do it with the people who are doing the work and not just with managers.
Identify all the points of “friction”, all the “wait times” and unproductive work (toil).
Solutionize in any way you feel comfortable - design thinking, brainstorming etc for the best possible choice of tooling that could automate manual processes.
Always ask “why” when coming across something that’s not automated.
Define your north star
Build a Platform Engineering team
Build a prioritized backlog. Apply WSJF technique to prioritize’
Establish a process for collecting feedback.
How to measure progress?
Good old DORA metrics. If they are trending in the right direction, there is a good chance that your DevEx is improving. If not, chances are it’s not. Agree among leaders on the definition of Business Value. Build a link from the DORA metrics to business value. More on this in our other blog post “Guided By Business Value”.
One good metric to look at is how long does it take for a newly hired software engineer to become productive within the organization and project? The platform is not going to be the only factor contributing to this, but it will be one of the key ones. Another excellent metric that is used by a number of organizations is “Time Loss”, or related to that “Focus Time”.
But that’s not all. As we mentioned earlier, since a platform is a product - ask users. Conduct user reviews, focus sessions, observations. All the things that a good product manager would do.
A very good study of how various companies measure Developer Experience is in this article by Gergely Orosz and Abi Noda.
Conclusion
In this series of blog posts, we explored the concept of Developer Experience, platforms, and the pivotal role the emerging field of Platform Engineering plays. We've looked at the importance of product-centric approach to platform development and how the focus on Developer Experience can lead to a faster realization of business value.