This message was deleted.

Hi Ben, Good read! I like how you covered different ways for adoptin IDP tools. When I read for the first time I understood it's one strategy that should be chosen for the enitre IDP adoption but second look I think you can choose apropriate startegy for the specific IDP component or process that fit best in your environment. Also, very recently I realized that adoption of IDP in corporations is a subject of Diffusion of innovation theory coined by Everett Rogers in his book at the same title. https://en.m.wikipedia.org/wiki/Diffusion_of_innovations Based on this idea Geoffrey Moore described in his book Crossing the chasm, how to approach early majority that is much more difficult audience to attract comparing to innovators and early adopers. So I wonder can these theories be applied to IDP adoption? Dod you study this?

This is great, thanks @Grzegorz Wojciechowski. I haven't studied how diffusion of innovation relates directly to internal developer tool adoption, but as a model it makes sense and matches my own personal experience. Time to theorize! There are a couple of ways to look at it -- the first is if we are building a product for a specific customer segment in the company, then the early adopters and innovators are where we want to see the most adoption and thus business impact. The long tail of teams after may not be impactful relative to cost. But, this depends on the feature and if the platform culture is a "building for all" or "building the right thing for a customer segment". There's always that struggle. The other is there is always an appetite to spend for further adoption until there isn't and at most companies, after the early majority (maybe?), the late adopters and laggards are usually coerced to adopt even if they don't want to by top-down pressure or the platform slowly turning features off. Of course, this is why thinking about near 0 effort adoption early in a feature/product is important -- so you can bypass some of these uncomfortable strategies as much as possible. Either way, you raise an interesting idea that depending on the customer, the product, and the attractiveness (cost of delay vs cost to adopt), they may land in one of those diffusions and the strategy will be different per bucket, or set of buckets.

You nailed it!!! I just wanted to stress that the problem of technology adoption is described by the Diffusion of innovation theory and remedies for that challenges are described in Crossing the Casm book. Sounds like your proposed adoption strategies fully support these ideas. I do face these challenges every day, so just started listening to Crossing the Casm Audible recording. I'll share when finish and get some experience with these ideas in my area.

I really loved this post! I'm realizing that ultimately my team's platform requires reasonably high effort adoption (although it varies a lot depending on the team's service).. so I'm trying a bit of all of these strategies. I've found keeping documentation up to date/ invite contributions is really nice.. I'm not sure it's ultimately going to drive adoption much, but it certainly gives me more time to pursue the other areas.

Thanks @KirstinS! Let us know what approaches work best for you!