Dev Portals - You can actually make your developer experience worse.
Implementing any tool in an enterprise can be a daunting task with developer portals being no exception. I have lead many different implementations and done assessments of tools like Spotify’s Backstage along with other dev portals like Cortex, Port, or Atlassian's Compass. They all come with sets of challenges but one thing that is rarely considered is that you can actually make your developer experience worse if you’re not careful.
This concept is something that is never really considered but can be a real problem. Here are a few questions that I might ask before jumping into a solution.
Do you really understand the problem you are trying to solve?
Is the dev portal actually capable of solving it?
How many people have this problem and what is the impact?
What are the current ways of solving the problem?
Is it a people, process, or technology problem?
This really shines the light on good product management and thinking about your dev portal as a product. Getting the answers to some of the questions and truly understanding the problem is critical to the overall success of the platform.
You can’t get to where you are going until you know where you are
There are many different reasons why developer portals come up inside of an organization, but there is one that I would like to call out here as being problematic. It’s when there is a desire to create a “portal of portals” or when a team wants to create a portal, but there really isn’t a lot of buy-in from leadership or across the organization.
This can be a very difficult road to go down as it takes a lot of time and effort to gather buying and there could be groups that feel like you are trying to take their stuff away from them or don’t feel like there is an issue in the first place. Here is a great example from large software company I have worked with recently.
They have a cloud platform team has a scaffolding tool that was created and provides a fairly robust set of starter kits and infrastructure as code templates. There is a bit of a struggle between the dev portal team and the platform team around who should own the tooling but also who should own the standards for what good looks like. This has created competing tools inside of the organization and now teams and engineers need to figure out what the right tool is, where it’s located, and how actually to use it.
This is a fairly basic example but you now have a bifurcated experience that is actually worse than it was before. High cognitive load, fragmentation of the ecosystem, and duplication of effort are all higher now with the introduction of a dev portal without alignment across the organization.
Trying to improve developer experience really takes top down leadership along with a bottom up understanding of what is really causing toil for the engineering community. Just creating another portal wont cut it.
Even when you have both leadership alignment and understand the engineering community, you can still have plenty of other issues. Another great example of this is when your dev portal just becomes a trash can of things. This happens when there is not enough thought or effort put into the overall design and user experience of the portal. There are a six major principles that need to be taken into account when you are thinking about a dev portal.
Discoverability
Visibility
Trustworthiness
Productivity and Efficiency
Governance
I will dig deeper into these in another article but the general idea is to provide a portal that makes things easy to find, that I know I can trust, with the ability to truly self serve.
A developer portal can rarely be implemented without a broader DevEx journey associated with it. It takes thought, planning, and coordination across teams to truly be successful. If not, you very well can make you’re developer experience worse.
Where have you struggled with implementing a developer portal? What practices worked well to help you through it? Lets us know!
Want to learn more about DevEx and Dev Portals?
Check out this episode of our podcast where we break down it down even further.
Also dont forget to check out the Think Big Code Small podcast along with our other content at thinkbigcodesmall.io