Following Master Yoda with “The greatest teacher failure is”, in this article you’ll find my confession on 5 mistakes I’ve made being a Product Owner & Designer of Internal Developer Platforms. Without unnecessary extension, let’s get over with it!
Mistake #1: I’ve created a technology-oriented backlog.
I once worked on a platform for a large company, and I was a novice Product Owner who lacked awareness that the Platform… is not just a purely technological project. I approached the subject like a typical mediocre engineer: since I though wasn’t delivering business functionalities, I described the backlog in sequence with the tools I had designed as components of the Platform.
Let me show you one real User Story I had in a backlog back then:
“Create Grafana Dashboards for Feature Toggles in Application“
From purely DevOps Engineer perspective, this story looks ok – but it is missing the crucial element. Developer need!
Because yes, dashboards are necessary… but what kind? Perhaps basic ones like CPU usage will suffice? Or maybe specific ones are needed because without them, developers won’t be able to react in time to poorly configured feature toggles? And who should have access to them? Why the Developers even want to monitor anything related to Feature Toggles…?
This is how the story should look like:
“As a Developer, I want to see user interactions: number of clicks per session & percentage of users leaving the page – once I’ve enabled Feature Flag”
By formulating user stories this way, we won’t get bogged down in unnecessary development or automation that we will only use sporadically.
Conclusions from Mistake #1
The perfect Platform is not necessarily the one with full automation. The perfect Platform is also not the one that provides 100% tooling for the delivery & operations process, nor is it one written “perfectly using Kubernetes operators”.
The perfect Platform is the one that focuses more on addressing developers’ needs, following the idea of “Thinnest Viable Platform”. I described this in more detail in an article dedicated to building the Platform’s backlog, which you can find here.
Mistake #2: I’ve left DevOps Engineers alone with Platform Design.
We were building a Platform for one of our clients in the banking industry, and we decided to prioritize observability as the first set of functionalities. The problem we encountered was the lack of a simple troubleshooting functionality: when something crashed in production, the developers struggled to determine the exact cause. What was my mistake? It seemed so obvious and well understood by my team that… I left the DevOps team to handle it on their own. Well, they ran into some trouble.
After some time, I received a complete, automated observability solution, all coded in Terraform, Terragrunt, and Helm Charts—fault-tolerant, scalable, cloud-based, and so on. However, it was challenging for the client to adopt due to its complexity and lack of seamless integration with the applications.
What would I do today? I would tell the guys to manually click everything in one day, and then focus on integrating several applications with the monitoring system they set up. I would focus on precisely demonstrating how to troubleshoot using these tools. Don’t get me wrong – the guys made a really decent software… well, except that the client couldn’t consume it and didn’t see any value in it 😊
Conclusions from Mistake #2
The perfect Platform is the one that perfectly addresses the current needs of development teams – at the time when those needs are most pressing.
A better Platform, even if put together hastily, is the one that allows the organization to scale up at a critical moment, rather than the perfect Platform delivered six months too late.
Mistake #3: I’ve “sold” the Platform concept not to people in power of making decisions.
I think this is a typical mistake resulting from a lack of understanding of how the organization works, into which we are entering. But let’s go step by step.
There was a bidding process, and along with a significant business delivery, we also offered to build the Internal Developer Platform – because the multitude of teams and the planned number of systems justified it. The client liked the concept and chose us.
I was surprised only when we started the work because it turned out that the organization has such rigid procedures and a strict division of responsibilities in technical teams that building Platform would be very difficult there without the appropriate decision by senior management & changing Team Topologies and responsibility boundaries.
How did I get through it? I built something resembling a Platform service, covering communication with the technical teams so that developers didn’t have to run around the organization to arrange all the tools – my team was responsible for it instead. From the developers’ perspective, they had something like a Platform, except that the service provided by my team wasn’t as fast as it is with traditional Platforms.
Conclusions from Mistake #3
Seek at least the blessing of individuals who can make significant decisions that affect the procedures and architecture of the entire organization.
Ideally, ensure that the Platform is part of the Strategic Planning and have a clear insight into its implementation. Otherwise, you will have your hands tied, and you will need to come up with workarounds.
Mistake #4: I’ve chosen delivery strategy badly.
There are two most popular Platform implementation strategies: either we tidy up the existing technology in the organization and add a layer of services and an Internal Developer Portal – or we go for what’s called a big-bang and say, “Okay, we’re doing most of it in a new way.” Cleanup is mostly used when the organization wants all systems to be easily migratable to the Platform from day one. And big-bang is used when we want to do new deliveries in a new way and gradually move the “old systems” over time.
And what did I manage to mess up? Well, I managed to misjudge the actual situation we were dealing with and what the organization really needed! So, at times, I got stuck in tidying up when the organization was waiting for a “breath of fresh air,” and other times, I introduced technology that caused even more confusion and, in fact, wasn’t needed at that particular moment.
Conclusions from Mistake #4
When building a Platform, one must understand the organization’s strategy. It is essential to know roughly how many deliveries are planned in which areas and technologies.
The Platform Owner should closely collaborate with the enterprise architecture and make decisions based on the directions set by the CIO for business applications – not just on technological premises. In other words, the Platform Owner must grasp the business and its needs, even though it may seem far from their theoretical role.
Mistake #5: I wanted to make everyone happy with the Platform.
In large organizations, it is impossible to satisfy every team and every architect. And I realized this… a bit too late, and I wasted a lot of time and energy trying to convince someone to adopt the Platform, only for them to see its value when they experience it firsthand.
I encountered a situation where the organization was highly diverse in terms of technology. Some excelled in everything, down to the “bare metal,” while others struggled with containerisation or CI/CD pipelines for their applications. In such circumstances, how do you build a Platform that satisfies everyone?
Today, I believe that not every team in the organization needs to be a Platform client from day one – and one must recognize such cases and not try to force everyone to adopt it.
Conclusions from Mistake #5
There will be three conclusions this time!
First: Check if there are any elements of the Platform already present in a mature team. Usually, these Platforms are specific to the particular team, but some parts of it might be successfully reused.
Second: Let the mature team be your “challenger.” The advantage of a development team that built the Platform themselves on the side is that they understand the needs and complexities of the delivery and maintenance process for business applications. They can validate priorities and shape the Platform accordingly.
Third: Do not let yourself be “dominated” by extreme teams, both in terms of organizational and technological decisions. Remember that their needs and perspectives are specific, and you must find a solution that improves the entire organization. Perhaps an “extreme” team will never be a client of the Platform – they should only become one when they themselves are convinced that what you have built is better than what they have internally.
