This message was deleted.

Building the platform product that solves the right problem should always almost be a trailing indicator. The product will drive the adoption

Have a look into

I work on the vendor side, Harness.io, so ensuring a high/ accurate pace of adoption is critical to get the value realisation of the investment. My 2 cents are: • Have a plan. What applications/ teams, etc, are the early adopters. Get that signed of with senior leadership and establish clear ownership within each team scoped for onboarding and clear top down communication from the executive sponsor of the project to “why change” is necessary, ideally before kick-off. Then regular progression check-ins. • to your point of “crossing the chasm”, evangelising with an “early adoption” team/ service/ application showcasing success is key. Internal “lunch and learn” type sessions focused on outcome and how it’s impact the day-to-day for the Devs is pretty effective. • I think the most important matter is the ease of adoption. Yes the “product” has to be great, but however good it is, if it’s hard for the users to find eg. docs, the services specific to them, best practise, etc - adoption pace will suffer (the importance of having both an IDP as in Portal and the actual Platform for execution on the backend/ as central tooling

Having metrics helped. We tracked the adoption rate of capabilities that we offered within Platfrom Engineering. There were several ways we drove adoption • Early adopters programs to get feedback and to ensure we solved the right problems. We'd then use the outcome of these early adopter programs to influence hearts and minds • Tried to offer as much by default or lowered the barrier to entry using an IDP and good documentation • For the laggerds this is where executive buy in comes in. I would work with exec to push this in as OKRs. So more of a top down approach • Lastly, we had platform ambassadors act as champions and worked on culture change e.g Engineering Managers were accountable for "tech health". We would use score cards to create healthy competition between EMs

Adoption isn't the goal. It's the mechanics of getting an outcome your organization wants. I find it best to get buy in on the outcomes and then work out the mechanics of getting the fight adoption rate based on cost of delay. The three main outcomes I've found that buy in is clear on are: • reduction of KTLO/maintenance work, because it frees up more time for product work • delivery speed increases, because things you could ship before in a week you can ship in two days now, and product values that • it's safer to move faster, because production outages or security breaches kill both productivity and customer relationships, and product wants that I think my point is clear :)

Hi @Bartek Antoniak, To be fair, I strongly believe, you should search for (mainstream) sponsors. Bring your guidance(skills) and (emotional) safety (implicitly asked for). Enable and help these sponsors to share their story (your metaphors) and their successes (cost optimization, anomalies, (automated) pay-per-use, might be a simple entrance). Another (pragmatic) view is the (cloud)operating model, try to be(come) explicit on shared (GRC, security, network, iam) responsibilities amongst the different departments. How to split application and infrastructure engineering, do we follow a growth or optimize model? How to embed governance (regulatory requirements; security (detection, protection on app,infra,data, (enforcing) metadata, budgeting, assembly lines, itsm) its about time to make these (grc) departments part of your journey (your metaphors). Potentially assess via https://cloudreadiness.amazonaws.com/#/cart/assessment, determine the gaps, discuss how to breach these gaps from a top-down. Closing these value gaps, might be achieved via company objectives (ambitions) to improve business outcomes. Reflect on CAF/WAF frameworks, keep material like: https://dora.dev/research/ in mind.