Quite interesting article re top-down, bottom-up motion in other companies. I always thought top-down was the way, because we once tried bottom-up adoption with our platform customers (aka developers), but it caused the management to spend 3 months on never-ending meetings with discussions that lead to a dead end afterward. After various attempts to be democratic, our management made the top-down decision which… caused us another 6 months of DX adoption. Now everything works smoothly, but this whole experience, ambiguous opinions (e.x. as Sam Newman said: Ops buy, devs use) made me wonder which side has less negative consequences. I know there’s no one right answer, but I’d like to hear your opinions on it.

This is an important topic for me as well. Something really important explained in the team topologies is that the adoption of platform as a product needs to be optional. Therefore, having self.-service capabilities with the standards is what developers will start using which is going to force them to use some tooling. They can use whatever they want, but if they do, they need to handle with a bigger complexity by their own.

Thats how we did it with our kubernetes stuff, we provided one team with the golden path but dident make it mandatory, they adopted it, we provided support and they evangilised it to the rest of the other teams.

So you build it, you run it rests on assumptions that cannot be met by all teams from skills perspective. If you cannot assume the dev team is able to do it effectively alone and it needs to be done you need a platform. What happens next depends on if you are large scale pure play software shop or for example OEM car manufacturer trying to get going on software.