Hello, All! I am currently working as a PM for our internal IDP (Internal Developer Platform) based on Backstage. We have thousands of people in IT, diverse systems in use, and limited collaboration across business areas. Although we continue promoting our IDP, progress has been slow. I’ve identified two main challenges: • Time Constraints: Teams are busy with their own business commitments, making it difficult for them to dedicate time to adopt the IDP. • Diversity in Tech Stack: With such varied teams and technologies in use, it's challenging to find a common approach for IDP adoption. The cost of education and onboarding is high. I have two questions: 1. Many teams in our company are undergoing a transformation to DevSecOps. For example, adopting CI/CD pipelines and integrating security tools are already significant steps, and they are occupied with these tasks. Introducing the IDP feels like an additional burden. How can we approach these teams and convince them to start using the IDP? 2. Measuring the impact of the IDP is essential to proving its value to the business. How do you measure the impact of the IDP in your organization, and what metrics are most effective? Thank you in advance for your feedback & suggestion!

Hey Mingdao, the metrics will kind of depend on what were your assumptions or goals for the IDP initiative - could you share a bit more on that? What was the problem you were trying to solve?

thanks for the quick reply, @Marta Wozniak! Right, the general or high level goal is to improve productivity and quality for our development teams. But as it has very diverse systems in use, I need talk to each "application team" for backstage introduction and then to figure out how Backstage can help them. Some examples: 1. some team use the SW template to create new SW quickly. 2. Some others big teams they use Software Catalog to manage their components (around 200-300 microservices). 3. Some use SW template to provide self-service access provisioning

Ok, this will be a bit harsh, but… 1. If it’s time consuming to „adopt”, you somewhere lost your focus on the teams needs. Platform is not something to learn, platform is something which should simplify developers live. What I suggest is: select few teams which are slowly progressing with features delivery / are overloaded / request you the most of tickets. Choose one area and make it simpler for them (maybe it’s observability, or painful deployments? Or dependency management? Deliver them first simplification of their everyday sdlc) 2. There is a way to overcame it - make a company vide discussion on target technology stack. Involve COO / Enterprise Architects. Companies, even big ones, rarely really need diversity in tooling. Select the most teference teams and take responsibility for migrating them to the platform instances (but do not involve them much, because their focus should still be their usual business). In one company I just did enabling teams, both for migrations and for parts of the platform delivery - and invited developers from each team to join. Of course it reduces those teams capacity for a month, but then platform felt like it’s something they co-created, not something you forced them 3. metrics - I like those ones attached Most of the dilemmas you are having I had as well. You can ash your boss to finance my course to make your live easier :) and I also do commercial consulting (first session can be free if you need help). http://drogaarchitektait.pl/en/efficient-platform-manager-global/?trk=public_post_comment-text