Internal Developer Portals: Autonomy, Governance and the Golden Path

This content originally appeared on DEV Community and was authored by Tiago Barbosa

In today’s fast-paced tech landscape, development teams face the challenge of improving their autonomy while adhering to organizational governance. Striking this balance is key for driving innovation and ensuring that teams can focus on what truly matters: delivering high-quality products efficiently.

In this blog post, we’ll explore several key topics that highlight how organizations can empower their developers while maintaining necessary standards. We’ll discuss the importance of team autonomy and how it enhances productivity, the impact of reducing context switching and cognitive overload, and the concept of treating your platform as a product. Additionally, we’ll delve into the significance of standards enforcement and how it contributes to a cohesive development environment.

By the end of this article, you will have a better understanding of some of the most common challenges faced by engineering teams daily, along with effective strategies to overcome them.

Ready? Let’s do this!

What is an Internal Developer Portal in the first place?

An Internal Developer Portal (IDP) is the entry point within an organization for developers to access tools, resources, and documentation they need to effectively build, deploy, and manage applications or services.

The purpose of an IDP is to provide autonomy for developers while at the same time improving governance for organizations through standardization of best practices and access controls. By standardizing best practices and implementing access controls, Internal Developer Portals allow teams to operate independently, all while adhering to essential guardrails that ensure compliance and quality.

While Internal Developer Portals are designed to tackle a variety of challenges for different users, this multifaceted approach can make it difficult to get them just right. Striking the perfect balance between flexibility and structure is key to unlocking their full potential.

We recently released a whitepaper discussing Internal Developer Platforms and Portals, along with key considerations for selecting the right one. If you’re still uncertain about your options, I suggest downloading it here.

This article focuses on identifying and implementing the right balance between providing developers the autonomy they need to be effective in their tasks and at the same time provide relevant insights to the business and teams to improve the way they collaborate and provide value for their customers and stakeholders.

What do developers want from their portal?

Every developer has experienced the endless cycle of new practices, frameworks, processes, and tools that promise to solve the daily challenges they encounter. However, many of these initiatives are often driven by conflicting priorities that don’t always align with the actual needs of software developers. This disconnect can lead to frustration and, over time, result in developers becoming obstacles to new initiatives.

Developers want the freedom to create software without restrictions or relying on other teams. An intuitive Internal Developer Portal will simplify workflows, boost collaboration, and provide easy access to essential resources. It will, not only, enhance productivity but also drive innovation, empowering teams to deliver high-quality software more quickly. In the sections that follow, we’ll dive into some common pain points developers face and explore effective solutions to overcome them.

The dream of fully autonomous teams and individuals

According to a research article published by Microsoft, developers spend approximately 20% to 40% of their time waiting for other teams. This waiting can involve dependencies on infrastructure, approvals, or other teams' tasks, impacting overall productivity, satisfaction and project timelines.

For years, efforts have been put in place with the goal of reducing this number. You have surely heard of DevOps, Platform Engineering, Team Topologies and more. And I bet that most probably your organization follows one of these practices. In a way, all of these have succeeded but also failed because the truth is organizations still struggle to provide autonomy to their teams to reduce the amount of time they spend waiting for others.

But let’s face it, do developers really want to be autonomous or are they just looking forward to having less blockers and being more productive?

Focusing on what is important

In recent years, companies have undergone a radical metamorphosis, embracing digital innovation at an unprecedented pace. According to recent surveys, in 2019, about 30% of companies reported having dedicated budgets for digital transformation. By 2023, this number increased to approximately 70%, showcasing a strong commitment to investing in digital initiatives.

This upward trend underscores the increasing recognition of digital transformation's importance in maintaining competitiveness and has elevated developers to the status of premium assets, with every organization competing for their expertise as they strive to navigate this brave new world.

Simultaneously, developers have assumed greater responsibility for various elements of the software delivery lifecycle. Previously, developers primarily focused on coding while others were responsible for maintaining it. Now, however, most development teams are tasked with building, deploying, and managing the products and features they create in production. If you use AWS or have seen some sessions of their main conferences you have probably heard of “You build it, you run it”.

This can, of course, diminish the need for collaboration. While having diverse skill sets within teams can enhance productivity, it also creates a challenge: developers may become unfocused. As they are required to gain expertise in various areas of the technology stack to deploy and maintain their code in production, their attention can be divided.

You might wonder if this leads to increased productivity for developers. While it can, the key question is whether they are leveraging their expertise effectively. Could the operational aspects of their roles be streamlined so that they can dedicate more time to writing code and delivering new features to customers, thereby maximizing their overall business impact?

Reducing context switching

Every single developer dreams of being focused, without disruptions, when ideas are flowing, time and space fade away, you move with certainty and at a strong pace. This is known as flow state.

When you’re in the flow, you are fully immersed in what you’re doing, and enjoy increased creativity, innovation, and happiness. On the flip side, when developers can’t freely collaborate or get “in the zone”, their productivity suffers. According to a study from the University of California, it takes 23 minutes, on average, to get back into the task at hand after an interruption.

As developers take on more responsibilities, it is crucial for them to learn new skills and adapt to emerging tools and technologies. These tools feature different interfaces, function across various platforms, and fulfill specific roles.

Alongside these technological challenges, developers face additional context-switching activities, such as participating in meetings to share their expertise and ensure team alignment on project goals, or assisting with the onboarding of new team members.

Developers typically waste a significant amount of time due to context switching, with estimates indicating that it can consume between 20-30% of their workweek. A recent survey by Qatalog and Cornell University revealed that 69% of developers report losing 8 or more hours weekly to context switching, which varies across tasks and environments.

This chronic switching negatively impacts productivity and focus, making it a critical issue in software development that needs to be tackled from multiple perspectives as this is more of a people problem than a tool problem.

However, having all the necessary information in one centralized location could greatly improve the situation, wouldn't you agree?

The right skillset

As mentioned before, the demands placed on software developers have shifted dramatically, reflecting a broader transformation in the tech landscape. The concept of shifting left - a pivotal aspect of modern software development - aims to address issues earlier in the development process, enhancing quality and minimizing costs. However, this shift also raises expectations for developers, necessitating a well-rounded skill set that can sometimes exceed practical capabilities.

Shifting left refers to integrating best practices and testing into earlier stages of the software development lifecycle (SDLC) which leads to identifying problems sooner in the process and making them cheaper to an organization than if they were found only in production and affected customers.

This approach makes total sense and it has its benefits for sure but how does this impact development teams?

Cognitive Overload: With the diverse set of technologies and methodologies available, developers face pressure to keep pace, leading to potential burnout and decreased efficiency. It's unrealistic to master every technology in a rapidly evolving field.

Specialization vs. Generalization: While some developers thrive as generalists, others excel in specialized roles. The push for a universal skill set may cause frustration for those who prefer depth over breadth.

Quality vs. Speed: Balancing quality with the need for swift delivery can lead to rushed work, potentially compromising security and reliability. Developers must determine priorities, sometimes at odds with organizational goals.

As organizations continue to emphasize shifting left, it's crucial for companies to recognize the challenges developers face.

What do Platform teams look for in Portals?

For years, Infrastructure teams have been given the responsibility of enforcing standards, yet they often lack the resources and authority needed to truly empower development teams. This disconnect can affect their ability to deliver meaningful value and support.

What these teams truly seek in Internal Developer Portals is the power to eliminate blockers for developers while upholding standards and ensuring compliance. They strive for increased visibility across the organization, which enables smooth workflows and fosters innovation without the hassle of unnecessary friction.

In the following sections, we’ll explore the significant work these teams have accomplished over the years, the challenges they face, and actionable strategies to overcome them.

Building on solid foundations

In the past decade, we've observed a shift where professionals who previously managed in-house servers and infrastructure have transitioned to similar roles in the Cloud. This change required a transition from simple point-and-click operations and local scripts to remote management using Infrastructure as Code (IaC) in a more streamlined and predictable manner.

For many organizations, this has become the new norm. But why does this matter?

The shift to Cloud and Infrastructure as Code (IaC) has compelled teams to reconsider not only their infrastructure but also how these scripts and templates are utilized and their impact on business objectives. Typically, these resources have been made accessible to software developers through various means, such as CI/CD pipelines, command-line interfaces, or sometimes by submitting a ticket to the infrastructure or platform team for execution - commonly referred to as TicketOps.

While some of these methods are more effective than others, they all share a common foundation established by the organization to standardize best practices and simplify processes. This approach aligns with one of the primary objectives of internal developer portals: to enhance the use of existing tools and practices.

Therefore, if you have embarked on this journey over the past few years, you are already ahead of many others.

Platform as product

A significant challenge that operations and infrastructure teams have consistently faced is their perception as gatekeepers and a cost center within organizations. Often viewed as a slower part of the operation, these teams have been seen as obstacles to progress and innovation. However, with the right motivation, strategy, and leadership, this narrative can be transformed.

In recent years, there has been a notable shift where many organizations are establishing internal-focused platform teams. These teams aim to deliver Platform as a Product (PaaP), which encapsulates not only the technical infrastructure but also the necessary tools, services, and support that empower teams across the organization. This approach underscores the importance of these teams as enablers of agility and innovation.

This transition is more than just a rebranding; it represents a strategic pivot towards collaboration, efficiency, and innovation. By treating platforms as products, teams can better understand user needs, enhance service delivery, and promote a culture of continuous improvement. This model encourages cross-functional collaboration, allows for faster deployment of solutions, and ultimately drives business success.

The question now is: What does it mean for organizations? It implies embracing a mindset where operations and infrastructure are not merely support functions but integral components that drive business agility, responsiveness to market changes, and innovation.

In practical terms, this approach means treating your platform like any other product within your organization, with the key distinction being that your customers are internal stakeholders. You will engage with these customers to gather requirements, manage the product backlog and roadmap, and develop the necessary tools and resources for their use. Additionally, you will be responsible for ongoing maintenance and ensuring these solutions are effectively adopted over time.

As a result of this shift, platform teams become powerful enablers, enhancing the effectiveness of various teams while promoting consistent standards across the organization. However, just as companies face challenges in encouraging external customers to utilize their offerings, platform engineering teams may encounter similar difficulties in driving adoption of their platforms.

Improving adoption rates

Increasing user adoption of your Internal Developer Portal can be a significant challenge. As noted in this article, many organizations see Backstage adoption stagnating at just 10%.

Adoption is a crucial aspect of the process, extending beyond just Internal Developer Platforms or customer-facing products. You've done it plenty of times before, potentially in smaller settings. Remember that time you had to persuade your team to follow a new way of testing code, or when you led that project that required a complete redesign? These experiences are directly relevant — they just occur on a larger scale when it comes to product adoption.

Now, here’s a strategy that has consistently worked for me, regardless of the context: keep your “customers” engaged and satisfied. How can you achieve that? Build the features they need to make them more effective.

However, it’s essential to remember that you are developing a product, so manage it accordingly. You’ll be interacting with various teams, each with competing priorities and timelines. Therefore, it’s vital to prioritize effectively and deliver frequently, maximizing the value you provide.

If your teams express frustration over a lack of documentation or find that information is scattered across multiple locations - impacting developer onboarding times - start by implementing Service Catalogs. If they struggle with dependencies on other teams for simple tasks like creating cloud resources, focus on enabling Self-Service actions.

We've seen organizations successfully tackle these in different phases, addressing specific problems and working with smaller subsets of teams. Attempting to solve everything at once is likely to lead to failure.

In short, leverage customer feedback to drive your Internal Developer Portal implementation to ensure higher engagement rates. And while you're at it, why not measure its success?

Enforce standards

Maintaining software in production is no small feat. For those tasked with this responsibility, ensuring that best practices are consistently applied across the entire stack can feel like an uphill battle. In many organizations, the burden of service management often falls to a single team, which simplifies oversight but doesn’t reflect the reality for most teams.

Even if you’re part of a dedicated group that manages the full lifecycle of a product, the landscape changes as your organization grows. Onboarding new team members and ramping up deployment frequency can introduce complexity, and without robust best practices in place from the outset, mistakes are inevitable.

This is where Internal Developer Portals come into play. These powerful tools can streamline your processes in several ways. First, they enable Self-Service actions, allowing developers to scaffold new services that incorporate established patterns across the organization. This not only accelerates development but also ensures that all necessary integrations with observability and incident management tools are seamlessly established, along with the infrastructure needed to run your code.

Moreover, Internal Developer Portals facilitate the automated collection of insights from your services and their dependencies, helping you verify that best practices are being adhered to. This data can be visualized in various formats, such as charts showcasing DORA metrics or team scorecards. Such visibility empowers you to monitor compliance with best practices and make informed, data-driven decisions to enhance both your services and team workflows.

Does it sound like Internal Developer Portals could address many of the challenges you’re currently facing? That’s fantastic!

However, it’s important to remember that achieving the right balance is crucial.

Autonomy vs governance

Improving the developer experience within your organization is not just a possibility; it’s an imperative. However, the timeline for achieving this can vary significantly based on the maturity of your platform and processes - ranging from weeks to months, or even years.

As I highlighted in our earlier discussion about adoption challenges, keeping both developers and platform/infrastructure teams engaged is vital. This means prioritizing the delivery of value frequently. Think of it this way: delivering small, incremental improvements is far more effective than waiting for a massive feature release that could disrupt existing workflows.

If you’re a fan of streaming TV series, you’ve likely experienced the thrill of a new season releasing just a few episodes at a time, with new episodes dropping weekly. The creators don’t release everything at once because they want to keep you engaged and excited for what’s next. The same principle applies here.

By consistently delivering small enhancements, you demonstrate your commitment to improving the developers’ experience. There’s no one who wouldn’t appreciate that!

However, it’s crucial to strike a balance between autonomy and governance. Developers often seek full autonomy, while platform and infrastructure teams prioritize governance. Here’s the reality: autonomy without governance can lead to chaos in the medium term, while strict control without autonomy can hold back creativity and hinder product adoption.

Finding the ‘right’ balance with Golden Paths

Finding the right balance is essential for the successful execution of your Internal Developer Portal strategy. It’s about fostering an environment where developers feel empowered, yet supported by the necessary governance to thrive.

That’s why golden paths are important. Golden paths offer structured guidelines that empower developers to adhere to organizational best practices while still allowing for flexibility to make minor adjustments as needed. By following these golden paths, developers can concentrate on their core tasks without the complexity of navigating compliance issues. For platform teams, golden paths establish a consistent framework that allows them to collect relevant signals that can be used to monitor usage, providing valuable insights and data that help improve practices across the board.

So, you might be wondering how you can do all this in an easy way, right? Let me show you how you can do it in Rely.io.

Default dashboards, views and homepages

One of the primary advantages of Internal Developer Portals is the ability to centralize information in a single location. However, simply gathering information isn’t enough; we need to present it in a way that is intuitive and easy to digest for users.

At Rely.io, we understand this challenge. That’s why we offer out-of-the-box dashboards and views tailored to the most common use cases. This approach enables users to hit the ground running and quickly discover the platform's capabilities. Plus, all dashboards and views are fully customizable to meet your specific needs, utilizing built-in widgets and requiring no coding skills.

Another example of where built-in dashboards provide value immediately is on improving visibility on productivity metrics across your organization. At Rely.io we understand how important this is. If you don’t have enough information on how and where your services are running or how frequently you deploy to production how can you improve?

With Rely.io’s dashboards, you’ll enjoy a seamless experience across various entity types, ensuring standardization throughout your organization while making information readily accessible and actionable.

Self-service actions
At Rely.io we are aware of the time that is spent on repetitive tasks when writing code and maintaining software in multiple environments. This includes, but isn’t limited to, scaffolding new projects, deploying infrastructure, updating feature flags, performing rollbacks, etc.

To overcome this challenge we built the Self-Service Hub which contains a list of relevant built-in actions and allows teams to create their own set of Self-Service actions focused on their needs. In the image below we simplify the steps needed to set up a new project by abstracting everything that happens in the background such as creating a new repo, scaffolding files and folders, creating a new service in the observability and incident management platform, etc.

The execution of Self-Service actions in Rely.io is audited and might require an approval before running which gives developers the autonomy they need within the boundaries and controls implemented by the organization.

Scorecards
A common trend we’ve seen in all our customer engagements is the extensive amount of hours that teams and their leaders spend in collecting data that reflects their current maturity state from a service or production readiness perspective.

They typically depend on data coming from several different platforms that are operated by different teams and since this is mostly for internal use they never invested time and effort into automating these tasks. Well, Rely.io scorecards are here to help.

Scorecards provide an automated and always up-to-date way of collecting insights from several data sources and make them available to everyone. Do you have a service review meeting in 1 week? 1 hour? 5 minutes? We got you covered.

Although this saves teams precious time it doesn’t help with adoption and so we decided to make scorecards fun and engaging by bringing gamification to play. We have been incredibly successful with our leaderboards as it creates some friendly competition between teams and their services. And no one likes to be last, right?

At Rely.io, we’re on a mission to strike the right balance between being opinionated and flexible. Ready to give it a try?

Explore our demo environment or sign up for a 15-day free trial today!

If you’d like to dive deeper into how Rely.io works and discover how it can enhance your developer experience while enforcing standards across your organization, feel free to book some time with our Platform Architects.

This content originally appeared on DEV Community and was authored by Tiago Barbosa