Push vs Pull - How to succeed with an Internal Developer Portal

How should you structure the project and incentives to drive Internal Developer Portal adoption?

IDP

Some of the most promising designs and plans software teams have come up with for managing software have struggled to gain adoption and withstand the test of time. Often this is the result of how we ask others to participate. Many times we default to “push”.

So what exactly is “push”? In this context “push” means siloed building in anticipation of future demand while relying on organizational mandates and processes to force a desired behavior. Essentially telling a developer “use this system we built without your input.”

Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. - Dee Hock, Founder of Visa


One of the biggest issues we’ve all faced in trying to standardize, scale and automate how we manage systems and software is the attempt to force rules and standards onto people and teams where they don’t fit or are not well received. Mandating that software engineers enter every software component into a CMDB or to craft a Design Document that will never be read is both inefficient and demoralizing.

This frustration invariably gives rise to shadow IT: the deployment of resources outside of the approved system. It’s not going to end well: In the best case your software estate is left in organizational disarray, and in the worst case you are left to deal with attrition of your best people. Because of this, we advise that organizations adopt a “pull” strategy. Organizations should focus on creating a point of immediate value for users of internal platforms. What does your development team want? What do they need? Perhaps that is a software catalog or templates for service creation or something else entirely. Build what they need in a way that is useful for them, where the organization does not mandate usage.

We like to think of Platform Engineering as an exercise in pattern matching. The platform consists of all of the patterns that pave the golden path to production. It defines the least-friction route to successfully bring new or existing code to production. An engineering team can feel confident that their components will be fully supported by the broader engineering organization. And, as more and more patterns are identified (and eventually codified), the organization can quickly adopt more efficient ways to develop code.

This is where “pull” comes in. We’ve found that the organizations that are most successful in their adoption of Platform Engineering principles create a value chain that is continually built upon itself. For these organizations the adoption of the platform and standards outlined therein become inevitable. Not because of mandates, but because development teams are enabled by the platform’s value.

This is why we are so bullish on internal developer platforms. They are a perfect tool at the right time for helping an organization identify patterns, formalize how they may be adopted within the scope of day-to-day development needs, and even for providing insights into how these patterns may be augmented over the course of time. 

Centering your internal developer platform around value delivery implies that engineering teams are granted autonomy to deviate from the golden paths defined by the broader organization. Perhaps new toolchains have been introduced, or additional commoditizable platform components have been developed. No matter the reason, a priority for an effective platform engineering team or developer platform project is to continuously codify these emerging organizational patterns. 

Just as we believe organizations are best served with a “pull” model when it comes to building their platform, so too do we believe it is critical when leveraging an internal developer portal. Organizations should not be beholden to the features of proprietary solutions. They should use what works for their own needs; continuously evolving their portal to suit the current (and anticipated) needs of their development teams.

We’ve built Arctir with Backstage as the underpinning technology so that our customers can frictionlessly bring a pull model into their organizations. Consume the community components that make sense for your teams. Let us help you fill in the gaps with additional plugins. 

Let’s build your value stream together. Sign up for our Beta here, we are adding capacity weekly: https://www.arctir.com/register