In the beginning, there was an app.
That’s how most tech company stories start, right? A small team comes up with an idea for an application and executes it. Then, if the app shows promise, the team hires more people so that they can refine the app and introduce new features. Fast forward a little, and the team is even bigger, coming up against new challenges like CI/CD limits and too many people trying to ship code. So, what’s next?
Often, at this stage, engineering teams will turn to microservices, splitting off certain workloads from the monolith so that they’re more manageable. This helps smaller teams move independently, introduces fault tolerance, and makes it easier to ship different pieces simultaneously—all things that enable the organization to scale.
Fast forward even further, and the engineering team now has a lot of people managing a variety of different services. By this point, some people have left the company, there’s likely been a re-org or two, and some services may have changed hands as a result. The tech stack has also grown, and the list of tools and services developers leverage on any given day to get their work done is longer than ever.
Introducing maturity at scale
As the company builds its customer base and sets a clear product roadmap for the future, engineering leaders are likely tasked with scaling their organization to meet these demands. However, this growth can only be sustainable and effective if the team is adopting systems, processes, organizational structures, and technologies that make it more efficient and mature.
For many teams, this means embracing a DevOps culture that’s iterative and cyclical in nature. Under this model, teams have end-to-end responsibility for the software and services they ship to production. They write the code and ship the features, but are also responsible for operating the software when it’s in production. This means they are on-call to fix issues as they arise, and are also keenly aware of the feature’s performance. For teams that have introduced security as a key component of the DevOps cycle, being aware of potential vulnerabilities is another core responsibility.
The next step towards building maturity is the introduction of a platform team. This is a foundational function that supports all product development teams by setting up and managing core infrastructure, introducing best-in-class tooling, establishing best practices, and optimizing the developer experience. So, instead of duplicating efforts across multiple product teams, platform engineers focus on cross-cutting problems. With a focus on agility, the platform team provides the cohesion that binds all product teams together so that they can get better features to market faster.
Alongside platform engineers, some teams will also have site reliability engineers (SREs), who focus on ensuring that the product is reliable by developing standards and learning from incidents, and security professionals who support developers in building security into the product.
With these maturity-building structures in place, the engineering team is better positioned to manage growth, respond to the demands of the market, and stay ahead of its competitors. However, there are still obstacles that need to be addressed in order to fully empower the team to take things to the next level and easily navigate exponential growth.
The challenges teams face
Even as the team becomes more mature and established, it’s likely that different members will come up against obstacles as the organization grows rapidly.
Product developers, for instance, may have a difficult time getting onboarded to new systems and processes if there isn’t a consolidated software catalog. Other common barriers include having little visibility into service ownership, not being able to find documentation easily, having to submit a ticket to platform engineering every time they want to build something, or even not having clarity about how best to get their service into production. This lack of visibility and clarity makes it difficult for developers to move fast, and can rapidly impact the developer experience in a negative way.
When it comes to platform teams, they may face challenges in rolling out new tools and guaranteeing their adoption. Often, they also have limited insight into which teams are adopting the right tooling and processes, and which teams are non-compliant. This makes it difficult to identify the gaps and establish where to place their efforts, and ultimately reduces the overall impact the team can have.
For engineering leaders, meanwhile, their concerns exist at a higher level. They want to ensure that the team is shipping reliable code as fast as it can while also reducing their spend. Their mandate is also to reduce developer toil and burnout, so product engineers can feel inspired to deliver their best work.
Unleashing potential with an internal developer platform
One way to address all of these challenges is to adopt an internal developer platform (IDP). An IDP is a platform that centralizes access to the tools and knowledge product developers need to deliver quality software, fast — but it doesn’t just benefit developers. For platform engineers, it reduces some of the burden by creating self-service features that developers can leverage and offering more insight into who owns which service, when. Meanwhile, leaders get more visibility and can make informed decisions that make the team more effective.
Specifically, an IDP supports engineering orgs across three key areas:
Visibility
A robust software catalog provides visibility into what tools and services there are, their metadata, who owns them, what dependencies exist, and which operational tools are available. Beyond helping teams move faster, this feature is invaluable for onboarding new team members, as they have a central source of information for anything they need to learn about their job.
IDPs also support engineering leadership with rollup metrics from entire domains of the business. For example, with a domains view, leaders could see what their total AWS spend is across the business, or how their entire system works together. This makes it easier to share reports with other business leaders and make data-driven decisions for the future.
Standards
The best engineering teams know that autonomy and standardization is not a dichotomy. You want your developers to be autonomous and make their own decisions, but you also want to support them with standards and structures that frame how they do their work. An IDP provides a mechanism for measuring and enforcing standards across a team’s production architecture.
There are levels for what this looks like. OpsLevel, for example, has a series of features designed to drive maturity from a standards perspective. This includes automated checks that measure standard adoption across services, a maturity rubric that gamifies standard adoption, and campaigns where platform engineers can roll out new standards with time constraints for adoption within existing services.
Self-service
In the traditional platform engineering model, product developers reach out whenever they have a request and have to wait for a response or for an action to be completed. While this may work with small teams, it can rapidly become an obstacle when teams are growing quickly — burdening developers and platform teams alike.
At the end of the day, platform teams don’t want to do things for product teams, they want to give them the tools they need to do their best work. An IDP allows platform developers to automate a lot of the support they provide developers, giving them a central location to find templates and launch ready-made custom actions that align with their current project.
Doing the best for your team
Optimizing the developer experience within your engineering org will always be a good idea. Not only does it reduce employee turnover, which is expensive in itself, it goes a long way to making your team more effective, producing creative features that meet the needs of your customers. With an IDP, your team can build software more seamlessly, reliably, and securely — and when leveraged properly, it can become the central hub where developers begin every workday.
Want to learn more about how a developer portal can benefit your organization as it scales? Our CTO, Kenneth Rose, went into great detail about what makes teams choose an IDP in a recent talk he gave. You can watch the recording here.