What does a successful developer platform as a product feel like?
The balancing act of meeting user and stakeholder needs when designing and building your own developer platform as a product
Written while in Amsterdam, Netherlands, while waiting to head to dinner with the lovely organisers of AxonCon 2024.
A preamble
I’m scared. Not terrified, but scared. It’s the usual pre-public talk emotion, amplified by my choice of topic and my choice of story to tell.
Last Friday I gave a completely new talk to my colleagues and it’s the scariest talk I’ve prepared in my career. Not only am I dealing with the popular subject of Platform Engineering and building an intentional Internal Developer Platform as a Product and so entering into an area where there are already so many incredibly knowledgeable people I admire hugely. But I’m also sharing my own personal reasons why building products, and in particular developer platform products, is so important to me.
The talk is part perspective on developer platform as a product, part true story of where I found meaning in life. It’s really personal and I really push myself in this story.
I cover a lot of ground too. The talk is a curated collection of lessons I’ve bled over and learned over almost 18 years of platform engineering. From developer tools, libraries, frameworks through to Infrastructure as Code, APIs and cloud services, I’ve been working in and around improving developers lives for a long time and I absolutely love it. All of that is poured into this talk, to the degree that I had to cut a lot of things out just to make it fit in an hour. This Thursday I am giving the talk again in Amsterdam, and I’ve had to cut things down even further. I want to leave everything on the table for the audience that give up their precious time for my talk, and so the process of cutting things out is brutal.
Thankfully the cuts and the edits are not being lost. All those snippets will surface as a little “Developer Platform as a Product” series of articles here on my blog. In fact, they’ve already begun to arrive. Each article contains a little message I either included in the talk—and want to go a little deeper on—or a message that got caught in the nets of filtering and editing but that here I have a chance to share it anyway.
As well as sharing these additional lessons, I’d also be keen to hear from you on what subjects and questions you might have on building developer platforms as products. Experiencing something hard to work with? Please pop me a question in the comments or ping me a message privately:
I’d love to help if I can, and the only thing I ask is that I can share anonymised ideas and answers to the best questions with your permission.
With that, here is today’s little platform as a product snippet:
Developer Platform Product Success is a Balancing Act
A developer platform product’s first priority is to be a positive impact in its users’ creative lives
We all have an incumbent internal development platform. Everyone. It might not be an optimal one, it might not be one we easily recognise and label, it might not even be a nice one to use and it could be one of those things standing between you and success, but everyone who is shipping code to production already has one.
My job as developer platform product owner is to turn those chaotic, often unintentionally established platforms into something more tuned to where a business wants to be. To intentionally evolve a platform as a product, not as a haphazard manifestation over time.
That usually means creating a platform of services and tools that deliver an exceptional development experience, bake in the "non-functional"1 concerns to empower those stream-aligned development teams, and also establishes those services and tools as a platform product that is manageable by the small numbers of developers the organisation can afford.
A successful internal developer platform product is a balancing act that looks to satisfy the needs of the business, the stream-aligned development teams, and the platform product teams as well. Balancing those diverse needs is the craft of intentional platform product engineering.
Happy developers are creative developers, are productive developers, are valuable developers.
Everyone has a slight bias when it comes to balancing those scales and I am no exception.
My bias is to tip the investment scales in the direction of the stream-aligned developer teams experience of the platform. I invest from the ground up—to avoid the lipstick-on-a-pig syndrome—, but as quickly as possible I am looking to improve my platform’s direct users’ lives. Happy developers are creative developers, are productive developers, are valuable developers. To put it another way, if the platform is not servicing your product development teams well then its impact is going to be severely diminished. It's failing its users, and that's unacceptable to me. A product’s first priority is to be a positive impact in its users lives2.
The platform product can be weak in other areas, perhaps providing less than brilliant interfaces to regulatory governance or giving the occasional support headache to the platform product teams. But those are its stakeholders, its curators. Its users are the stream-aligned platform teams and ultimately it is their experience, their lives, that your platform product is trying to improve first and foremost. The concerns of other stakeholders then follow.
I want the stream-aligned product development teams and engineers to feel great early about what our platform as a product provides, and so my balance of prioritising leans a touch in that direction. How they feel when doing their creative work matters the most to me and my teams. How do you prioritise building your own internal developer platform? What are you rules of thumb for figuring out the best order of improvements?
Nothing is more functional than what we casually label non-functional requirements. Yet another example of where naming in our industry is not at its best. More on that in a later article in this series.
This is why I cannot work on social media platforms. Or even on platforms that directly support social media platforms. My personal answer to why I’m here on this planet—my answer to “What are you here for?”, or my meaning if you want to check out Viktor Frankl’s work on this—is for other people. I care about other people, and I cannot therefore work on any product that has a net direct harm on the users’ lives. I can work in banking, because it is an intersubjective system that can be used for good or bad. Social media platforms, similar to gambling platforms, are a net, direct harm on their users and so I’m out on those. That’s just my own take though; each to their own in life!