Guidance Framework for Internal Developer Portal Work Prioritization and Measuring Success

Lalit Kale Lalit Kale
platform-engineeringdeveloper-experienceinternal-developer-portaldeveloper-productivity

Summary

Platform teams lack knowledge about product teams’ workflows and friction points. As a technical platform team member responsible for leading the internal developer portal, you can use this guidance framework for feature prioritization and define success metrics in internal developer portal initiatives.

Focus areas

  • An overlap is observed between the platform and product teams in automating workflows and building and managing infrastructure. Ideally, an internal developer portal should be a commonly established central, go-to place for reusable knowledge, practices, and capabilities.
  • Forced adoption or a top-down approach to adoption does not work for developer portal initiatives. The adoption of the internal developer portal itself should not be the cause of friction between platform teams and product teams.
  • Improving work prioritization and throughput improvements as an impact of the developer portal is critical to getting budgets and sponsorship from organizational leadership.

Key Takeaways

  • Develop personas and software delivery journey maps to identify the key areas where the developer portal can facilitate and reduce friction for product teams.
  • Use a minimum viable product development approach to deliver the capabilities to adapt to the changing needs of product teams and increase developer portal adoption.
  • Establish collaborative ownership of the developer portal by participating in direct development through inner sourcing and communities of practice.
  • Measure the impact of developer portals by using metrics focused on developer productivity, efficiency, developer effectiveness, and return on investment.

Overview

“80% of software engineering organizations will establish platform teams by 2026, and 75% of those will include developer self-service portals.” — Gartner

Platform teams are custodians of the internal developer portals. They build, manage, and curate the internal developer portals. Product team developers are primary customers of internal developer portals, yet the product team can be cross-functional. Developer portals aim to reduce team friction, bring standardization, and speed up transformation. Yet, the platform teams responsible can become overwhelmed with product teams’ requests for various features that internal developer portals should provide.

In other scenarios, the established methods of putting tickets to platform teams and operating in silos continue and do not yield the expected outcome of the adoption of developer portals by product teams. Platform teams also need an overall roadmap and more knowledge to see the broader picture of what exists in the organization as reusable assets. As a result, platform teams and product teams can duplicate the efforts, or the adoption of the internal developer portal needs to be improved.

So, how can technical professionals in platform teams determine the capabilities of the internal developer portal and prioritize delivering these features? Adopting a developer journey map and establishing a feedback loop with product teams can be used to develop the internal developer portal features. In addition, to measure the success of the features, technical professionals can utilize the various primary and proxy metrics related to developer productivity.

Develop Personas and Software Delivery Journey Maps to Understand Product Team Friction Points

As a technical member of the platform team responsible for leading the internal developer portal, hold internal discussions with your team, and get help from product owners to build customer personas to understand the requirements of the internal developer portal. Creating personas helps you to understand user needs, experiences, behaviors, and goals. Some principles for developing effective personas are:

  • Shape personas iteratively and maintain them over time to remain relevant.
  • Divide internal product team users into manageable groups and represent each with a persona.
  • Capture common segmentation elements like roles in product teams, technology landscape, and team composition.
  • Develop a hypothesis from the research, determine the qualities and differences between users, and ensure product team stakeholders agree on the hypothesis and can relate to personas.
  • Create brief documentation for each persona in your knowledge base or documentation system.

Based on the personas identified, determine how these different personas participate in software delivery and the times taken for core responsibilities performed by these personas. Create developer journey maps.

Like a customer journey map, the developer journey map is a visualization that identifies the path a developer follows and experiences. As they move left to right across the stages, their level of interaction increases with your internal developer portal team. It’s one of the most valuable tools in developer experience. It helps you think holistically about the experience from the developers’ perspective while providing a practical guide.

The following figures illustrate an example of a product team doing their first mapping of a typical feature as it moves from definition to production.

Figure 1: Journey Map for the product team feature delivery Figure 1: Journey Map for the product team feature delivery

Another way to visualize a journey map is shown below in Figure 2, highlighting context switches and non-value-added tasks, which are potential candidates for internal developer portal capabilities.

Figure 2: Journey map for a product team member knowing about different product services. Figure 2: Journey map for a product team member knowing about different product services.

After the mapping activity, the platform team can identify the hotspots (highlighted in the red color background) in the map where delays (lead time) are significantly more significant and discuss with product teams the dependencies and other bottlenecks.

Use a Minimum Viable Product Development Approach to Deliver the Capabilities of the Internal Developer Portal

To build or integrate any new capability for the internal developer portal, platform teams must start small and validate the features with the customer. The minimum viable product development approach for the internal developer portal can look as depicted in Figure 3.

Figure 3: Conceptual example for applying minimum viable product development approach to the internal developer portal Figure 3: Conceptual example for applying minimum viable product development approach to the internal developer portal

For adopting this strategy, the platform team can organize demos or walkthroughs of new capabilities and leverage the reuse of existing organizational assets. The new functionalities for the portal can also be delivered quicker by integrating with existing organizational systems. The developer portal team should use existing assets without reinventing the wheel. Platform teams also refrain from reimagining the final or full-fledged capability at the beginning. This will help the platform teams and developer portal’s features to be relevant to the customer needs and keep product teams engaged in the developer portal initiative.

The following are the benefits of applying a minimum viable product development approach to the internal developer portal:

  • Validate your understanding of product teams’ friction and pain points without using many resources for development.
  • Accelerate the platform team’s learning regarding expectations and timelines for rapid iterations with product teams.
  • Identify and gain effective early adopters product teams, which can help to demonstrate early success across the organization.

Establish Collaborative Ownership of the Developer Portal Through Inner Sourcing and Communities of Practice

The internal developer portal must support backward compatibility so product teams can transition smoothly from the existing systems and workflows to the internal developer portal. Besides, at a certain point in the lifecycle, platform teams must extend and own the components representing products and services. Adopting new collaboration mindsets and platforms, teams can use practices like inner sourcing and community of practice. Innersourcing various integrations and extensions can quickly expand the feature set of the developer portal. Establishing a community of practice can also help to market and evangelize the roadmap and can be instrumental in getting early feedback from product team developers. The benefits of adopting these techniques are:

  • Increased visibility of the internal developer portal initiative
  • Establishment of a contribution and governance model early on
  • Development of high-quality code and early testing
  • Healthy Culture: Silos are broken down between platform and product teams. It helps to increase effective conversations and a deeper understanding of product teams’ workflows and workings.

The platform team must be staffed with appropriately skilled technical members to justify the growth and further adoption. To achieve that, the impact of developer portals should be demonstratable with not only adoption metrics but also metrics pointing to usefulness, efficiency, and user satisfaction. However, there is no one way to measure the success or adoption across the industry. Platform teams can utilize the following framework for measurement and metrics.

Figure 4: Metrics framework for internal developer portals

“Our KPI is the percentage of developers that entered the developer portal at least once in the past week. Today; it stands at around 40%. The more actions we enable … the more people use it”. — Lior Rabin, Monday.com

Along with measuring, platform teams must regularly evangelize and promote the internal developer portal tools and related integrations and initiatives that are in progress to ensure product teams are increasingly aware of the advantages of the adoption of the internal developer portal capabilities.

Conclusion

For the internal developer portal initiative to succeed, the platform team must understand and practice a collaborative mindset, establish joint ownership and shared responsibility with product teams, and treat the internal developer portal as the product. Designing and implementing the internal developer portal is only the first step. It will also be critical for platform teams to market their portal by committing to delivering, maintaining, and improving over time an experience better than what product teams already have. With this guidance framework, platform teams will navigate through steps to develop and successfully deliver the features or extensions for internal developer portals.

References