The 3-step framework for adopting an internal developer platform
An internal developer platform (IDP) can help your developers focus on delivering software without the overhead of deployment pipelines, configuration management, or environment provisioning. As an engineering manager, this might be just what you’re looking for. But knowing you need an internal developer platform and adopting one are two different things.
While different platforms require different levels of resourcing to set up and maintain, a methodical approach to adoption will ensure your organization gets off to the best start. Choosing the right internal developer platform and successfully rolling it out will significantly free up developer time and resources.
In this article, we’ll provide a three-step framework for engineering managers who are ready to move from IDP concept to concrete action.
We’ll cover how to:
- Release a request for proposal (RFP) to identify possible vendors
- Roll out your chosen tool to ensure adoption
- Measure success and track improvements to developer experience
How to build an RFP for an internal developer platform
The first step to IDP adoption is creating a request for proposals (RFP). An RFP communicates exactly what your organization needs from an internal developer platform. Vendors will respond with proposals that demonstrate how they can meet these needs, such as through guided demos and free software trials. This will also give your team a clear rubric by which to judge the proposals.
Include all you need from an IDP
There are three main areas to consider in your RFPs:
- Challenges: What challenges do your engineering teams currently face that an internal developer platform can help address? You will likely have several key challenges you want to solve.
- Goals: What outcomes do you need to achieve by adopting an internal developer platform?
- Product requirements: What features and capabilities do you require to reach these goals?
For example:
If you’re losing knowledge when developers join or move teams, your goal might be to speed up developer onboarding. You might prioritize features that enable self-service and reduce manual configuration steps, such as through self-serve workflows and knowledge-base integration.
If your engineering organization is scaling and needs to follow more best practices and standards, your goal might be to improve security and reduce vulnerabilities. You might require capabilities for integrating with security platforms and monitoring compliance with scorecards.
If you’re finding it challenging to empower your engineers to be more productive and spend more time on the work they do best, your goal might be to reduce setup time so teams can quickly spin up services. You might require infrastructure automation and templating.
Get clear on your current state
To better understand your challenges and determine your goals, assess the current state of developer experience at your organization. Don’t just assume you already know the current state—instead, try conducting developer surveys, auditing existing processes, and holding developer focus groups to investigate where you need to improve. Be sure to explain the next steps you’ll take and keep teams updated on your IDP progress.
Our State of Developer Experience Report found that less than half of developers think their organization prioritizes developer experience. That’s not surprising when 2 out of 3 developers are still losing 8+ hours a week to inefficiencies in their roles. Read the full report here ->
How to roll out an internal developer platform
Once you’ve chosen an internal developer platform, collaboratively plan the rollout process and track adoption.
An out-of-the-box internal developer platform will reduce the amount of effort the rollout requires from individuals on your team. For example, Compass needs far fewer engineering resources than an open-source platform, like Backstage which requires 4 full-stack engineers to properly set up and maintain. With Compass, you can connect your source code management tools and import your repos to populate your software component catalog in just 10 minutes.
Form a steering committee
To ensure rollout goes even more smoothly, form a steering committee of a few key stakeholders. These experts will provide support, monitor the process, and make decisions to adjust when needed.
We recommend reaching out to:
- An executive sponsor: The most senior person who will spearhead developer platform efforts. The Chief Technology Officer, VP of Engineering, or Head of Platforms might be well-suited to this role.
- Influential developers: Choose a small group of influential developers from across your organization to help design, or at least be kept informed of your internal developer platform rollout plans.
- A platform team or DevOps engineers: Because integrations are key to how internal developer platforms deliver value, those responsible for these tools must be important partners in the rollout.
- Policy owners or governance teams: internal developer platforms make it easier for engineering teams to comply with standards and best practices, so working with those in charge of these standards can be helpful when planning.
Create a rollout schedule
With your steering committee in place, create a schedule for rolling out your internal developer platform. Communicate this schedule to all teams who will be using the new internal developer platform and ask for further feedback on your plan's feasibility to adjust as needed. As you move through the schedule, check in regularly to assess progress and adoption and provide support.
We’ve created an implementation guide for Compass to help you get started even more easily. Get the guide here →
How to measure the success of an internal developer platform
To measure your progress, return to the goals you outlined when you first crafted your RFP. Come up with both qualitative and quantitative key performance indicators (KPIs) that will show the full picture of whether your internal developer platform is delivering the value you were aiming for. With Compass, you can create custom scorecards to define your KPIs to make sure your engineering teams are aiming for the same standards.
Most people think of KPIs as “hard numbers” or “objective measures,” and that works for quantitative concepts like revenue or failure rates. However, developer experience is subjective, which means its KPIs will be somewhat qualitative, such as perceived ease of delivering software, perceived productivity, and employee engagement or satisfaction.
Find the right measurements for your organization
Here are some examples of what you might track, depending on your goals:
- If improving security was your goal, you might aim to reduce open vulnerabilities by a certain amount each quarter.
- If you set out to improve productivity, your KPI could be to reduce lead time to provision infrastructure from 5 days to 2 hours.
- If faster onboarding was your goal, you could track time to productivity for new developers and aim to reduce it.
- If improving developer experience is most important, you might aim for higher developer satisfaction scores from developer surveys.
Keep tracking over time
It may take some time to see the impact of your internal developer platform. Keep monitoring progress and use check-ins and retrospectives with your teams to discuss whether the internal developer platform is delivering the desired outcomes over time.
Team retrospectives give developers and leaders a chance to reflect on what’s going well vs. what’s not. You can find basic retrospective instructions and templates, as well as variations for specific situations, in the Atlassian Team Playbook’s Retrospective play here ->