It’s a story as old as tech: your team is moving fast, building incredible features, and focused on scale. But as you stop to catch your breath before that next stage of growth, you realize everything’s a little, well, messy.
Documentation is outdated, standards are non-existent, and ownership is a guessing game. Time spent solving valuable business problems or critical incidents evaporates as your developers lose hours trying to figure out who owns a service or duplicating work another engineer completed weeks ago. A widespread problem is that your fast-moving team slows to a crawl.
These challenges are particularly acute for companies with growing engineering teams. It might be that you’re part of a new acquisition, undertaking significant projects like onboarding a key customer, expanding to a new market, or have received a new round of funding. Yet whether your org is going from 10 to 20, 1,000 to 2,000, or you’re simply making ambitious engineering moves, the root problem is the same: sprawl. Engineers are facing challenges from context switching, cognitive load, silos to fragmentation, duplication, toil, dependencies, and congestion. And in an era of AI code generation, constantly reducing coding time, it’s only accelerating.
So, how can you tame the chaos and reignite that dampened agility?
Embracing internal developer portals
An internal developer portal (IDP) goes a long way to solving complex and chaotic internal software and infrastructure. It acts as a single pane of glass—housing your services, clients, libraries, data, standards, documentation, processes, and tools all in one place. It unites all of that information that was previously spread out across files, tools, and random Slack messages—or which had never even been documented in the first place. Engineering teams are rapidly embracing these tools, with Gartner finding 22% of IT leaders are currently piloting the technology.
The value for those early adopters is clear: Instead of firing off a message to dozens of engineers, searching endlessly through tabs and spreadsheets, or simply giving up and starting from scratch, developers with an IDP have a default location to find everything they need. That means faster, standardized, and more accurate work.
Most engineers would admit this sounds appealing. Who doesn’t want clear, useful, well-organized resources at their fingertips, when an incident is ongoing or when they need to create a new service? The barrier to implementing an IDP, however, is often knowing where to start.
Laying the foundations for an optimized engineering team
Kick-starting an IDP can seem daunting—but it doesn’t need to.
To start, every portal needs a few universals, and one of the primary ones is a catalog.
The catalog: This will contain all of your services, web apps, libraries, data pipelines, and more. You don’t have to build this from scratch. Plenty of solutions do this effectively, including Backstage, which was originally developed by the Spotify team as an internal platform and was contributed to the CNCF as an open source project now available to all.
Whatever tool you choose, the goal is to bolster discoverability, ownership, and quality across every item in your catalog. Anyone using it to find a specific item should understand what they’re looking at, who owns it, how it works, and whether it’s healthy—all on their own, without needing to ping another engineer with questions.
Plugins: While the catalog is the foundation of any great IDP, features can go much deeper. Plugins can bring the most used functionalities and data across all the tools in the software ecosystem to one place, the IDP, adding more value beyond the catalog—from day-2 operations, incident management, security alerts, deployment or testing, through to powerful analytics or AI assistants, all in one single pane of glass.
Templates: After bringing all the data and tools into one place, templates are a set of actions that can be created simply by any engineer. Templates automate processes across these data and tools, and can create a new service, or automate workflow. Any engineer can then use them as a fast-track for new services, for example, filling out a basic input form and turning it into a functional service in the preferred platforms, frameworks and connected to all the relevant tools—all from within the IDP. It makes sharing best practices and expertise across teams seamless and creates a self-service experience for developers saving hours, including the DevOps or Platform teams who often need to do these actions manually.
As a result of these foundations, your IDP becomes more than a repository for previous work or standards; it’s a seed for new innovations and a hub for tracking or assessing ongoing deployments and workflows.
Making the right way to build something, the easiest way
Growth and innovation motivate developers to do incredible work. Yet without the right standards, processes, and catalogs in place, that work can quickly stall. A growing software stack, disconnected teams, and legacy code can become a swamp for coders to wade through, impacting their own work and ability to hit key business goals.
An IDP enables fast-growing and fast-moving teams to sidestep these issues. By empowering developers to create new services, templatize effective processes, discover and reuse existing components, and track the health and standards of their services it enables them to build effectively, the right way —and via the path of least resistance. In fact, approximately 96% of Spotify R&D employees engage with our Backstage instance on a weekly basis.
Engineering time is valuable. It fuels faster processes across our companies, stronger security, reliability and incredible features or products for our end customers. IDPs are about maximizing the value of that time so developers can do what they do best—creating, building, and solving for the future.
To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon North America, in Salt Lake City, Utah, on November 12-15, 2024.





