Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

Annnnd, *<https://platformengin-b0m7058.slack.com/archives/C03CGFZAUGH/p1699620823516159|the blog post is live>*. Thanks <@U04EQ7LEVGV>, <@U041NE1V0JY> and other folks for helpful feedback on this piece. *“If you build it, they will come” — is the cardinal sin for any platform team.* The key to successful adoption of a developer lies beyond the tool itself; it’s about intentionally engaging engineers and leveraging their surrounding ecosystem for effective adoption. Social proof is the most powerful currency you have to convince future engineers to switch to a new developer tool.

Give it a read: *<http://gitpod.io/blog/champion-building|gitpod.io/blog/champion-building>* - happy to hear feedback or thoughts - curious to hear your experience  :thread:

Thanks Ben, next one is already in the works / published very soon (hopefully tomorrow) :partying_face:

hey Lou, I just had the chance to review the article, I love it, it is great advice.

And I know that because I did the opposite in the past for some of these points and I got some unexpected results :sweat_smile:

Glad you found it useful, Erick! :slightly_smiling_face:

&gt; And I know that because I did the opposite in the past for some of these points and I got some unexpected results
That’s interesting! :slightly_smiling_face: I’m curious—what did you do? What were those unexpected results?

Well, to mention some of the mistakes, when we introduced the new solution we wanted teams to adopt across organization we were requested to do a big demo to showcase the value proposition and functionality (for political and funding reasons mainly) At the time of demo not all requirements were there so many teams were not impressed.

We should have started to demo that to couple of teams and just some use cases, but instead we were pushed to appeal to everyone on Day 1

image.png

This affected us later because some were reluctant to adopt our solution because “it was not complete”, eventually after some time and interesting conversations they came along (once we had the features they wanted) but there was no need to start early with them, after this, I did not let external pressures to influence who we should target first and then later, not all internal customers are the same, some are more willing to collaborate on early stages of product and collaborate with it to shape it, others just want the full working solution, later I learned in product there is a term for this, the technology adoption lifecycle.