This is quite the representative case between Infra teams (or PaaS or SRE - based on where you're located) and application teams. Being part of the platform te

This is quite the representative case between Infra teams (or PaaS or SRE - based on where you're located) and application teams. Being part of the platform team, I've been in the exact same situation before at an ex employer. We assumed that _infra problems_ were _everyone's problems_ and how can anyone who cares about their application _not_ adopt to the latest-and-greatest-platform (or tool) we released. A lot of time was spent on figuring out the 'best approach' to getting everyone onboard quickly - we tried the carrot and the stick. We failed miserably at both. The trouble is, as someone else mentioned here - we didn't really go and _talk to the customer_. Internal customers are customers too - and 'product' thinking should be equally applied to all internal platforms. The general rule applies - talk to the customer and understand what they're going through. They have their own sets of problems and priorities. (a) Is the latest way actually _saving them a lot of time_ (b) Can we take another 2 weeks and make it even easier for them to come on board? (c) If they're really busy and/or lack the expertise, can we carve out some time to give enough training sessions? Yet, this never happens and we invariably end up blaming the application teams for _not doing this seemingly simple_ change. It may seem downright stupid from the platform engineer's PoV, but we are partly to blame. This also leads me to think that the cloud wars will be won by the <cloud-provider> that does this job better - of understanding the customer needs on a day to day basis and building platforms for them.