What do you mean an Internal Developer Platform Culture?

TLDR; and Key Takeaways

• Understanding IDP Culture: An IDP culture centres around viewing development teams as internal customers, prioritizing their needs and fostering collaboration. It aligns with a product management mindset, emphasizing continuous improvement, shared responsibility, and a commitment to delivering a robust platform that enhances developer experience.
• Investing in IDP Culture: The decision to embrace an IDP culture involves a strategic shift with clear goals. It aims to streamline development processes, boost developer productivity, encourage collaboration, ensure consistency, improve operational efficiency, enable scalability, foster innovation, and address security and compliance concerns.
• Challenges in Adopting IDP Culture: Despite the benefits, the transition to an IDP culture can face resistance due to cultural, skill set, setup, legacy system, security, resource, tool overload, maintenance, lack of standardization, and scalability challenges. Overcoming these friction points requires careful planning and ongoing effort.
• Starting the IDP Journey: Initiating the IDP journey involves defining clear goals and objectives, establishing measurable success metrics, gaining leadership support, starting with small pilot projects, introducing incremental changes, creating feedback loops, providing training, developing comprehensive documentation, encouraging collaboration, and investing in automation and self-service capabilities.

To Centralize or Decentralize, that is the question.

Much like any other highly loaded technical topic with clear absolute polarizations, the debate about Fully Autonomous Teams versus Centralized Standardized Teams rage on. This categorization is broadly, and loosely, used to cover discussion topics from decision making, accountability and ownership, to technology stacks and ways of working. But, such is often the case, what if there was a middle ground, or rather, even a third dimension to the argument (and let me save you the suspense, there is and most often even more than one alternative).

Fully Autonomous Teams are positioned with the argument of increased ownership and accountability, and flexibility and agility, while Centralized Standardized Team advocates table reduced cost and cognitive load, and standardized tools and processes. There are more areas and arguments, but today I would like to position this within the realm of Internal Developer Platforms (IDPs), and specifically focus on the Organizational Culture as opposed to what an IDP is.

What is an IDP again?

Firstly, lets do a quick recap of what an IDP is.

An IDP is a set of tools, services, and infrastructure that software development teams use to streamline and enhance their delivery process. It serves as a centralized hub, with self-service capabilities for developers to manage, deploy, and monitor their applications. IDPs are used to automate and standardize development processes and workflows, enabling teams to focus on coding and delivering value rather than dealing with the complexities of infrastructure, or finding the right information to do their work. These platforms typically consists of features such as documentation repositories, Infrastructure-as-Code (IaC), container orchestration, continuous integration/continuous deployment (CI/CD) pipelines, collaboration tools, and monitoring solutions, fostering a collaborative and agile development environment within an organization. The primary goal is to boost developer productivity, accelerate time-to-market, and ensure consistent and reliable application delivery. There are many articles that cover this in depth, and many more that promote specific tools or combinations of tools, which is beyond the scope of this article.

OK, so with that out the way, what is an IDP Culture then, and why should you care?

What is an IDP Culture then?

Build it and they will come. Sure. Like Ever!?!

I am sure this will solve their problem and they will love it and they will use it forever. If it solves their problems, maybe. If it gets in the way, nopes.

So what do we really want to achieve here? We want to position an IDP as an internal product.

And why is this important? Well, it aims to create a culture where the emphasis is on internal customers, and value is identified, prioritized and delivered through experimentation, feedback loops and data driven decision making. Its about understanding your internal customers first, understanding their jobs to be done, and the pain points they experience, and then coming up with ideas to test that would resolve these problems. Its about using an outcomes mindset, thinking about what it is that we want to achieve rather than what we want to build.

Yes, we need the tools, and yes we need the processes, but first of all, we need to know why its important, why should we spend our time on this and not on more features for our customers.

An IDP culture represents a collaborative and empowering environment in which the development teams are viewed as internal customers, with a focus on their needs and priorities. The culture fosters a product management mindset by aligning efforts with enhancing the developer experience and accelerating product delivery, time to market, and quality and stability. The culture represents continuous improvement, emphasizing feedback loops and responsiveness to evolving requirements. Additionally it places a strong focus on providing user-friendly tools, automation, and standardized processes, empowering development teams to efficiently manage and deploy applications. The culture encourages a shared sense of ownership and responsibility for the entire product lifecycle, fostering innovation, adaptability, and a commitment to delivering a robust platform that enables seamless and efficient development practices.

Why should we invest in an IDP Culture?

Good question. As with any culture shift within an organization, there will be resistance and challenges, so you better be sure you understand why you are embarking on this journey (and please tell me its not just because it’s the latest fad).

Here are some thought as to why you would want to go down this road.

If its so good, why isn’t everyone doing it?

Exactly. Good question. If you have ever tried to change Organizational Culture or even just the views and behaviours of a small group, you know exactly what you are in for.

So what can be such a challenging exercise to convince others to buy into this amazing new initiative?

So its not that easy. How do I start?

Great. You have made it this far. Lets see what we can do to get the ball rolling. There are some simple things you can start with that will set you up for success.

So no silver bullet?

Sorry to disappoint, but no, its not just a tool that you drop in and it magically fixes all your problems. It doesn’t make your teams super coders, spitting out reams of code with no errors. It doesn’t absolve you from having to do the hard yards to understand your current landscape, create a future view of what good looks like for your specific organization, and plan an incremental journey to get you there.

For us, this will be a key enabler, combining many models, processes and thinking from many industry leaders over numbers of years, into and ever evolving capability aimed at improving our overall Developer Experience and achieving our intended Customer Value Proposition.