Hey there! It’s Platform Weekly, the #1 doctor recommended source for your platform engineering needs. Let’s get bakin’ 🥐

Design principles for successful platforms, according to top engineering orgs

In my time researching and talking to hundreds of platform teams in the community, I’ve noticed that all successful Internal Developer Platforms (IDPs) follow similar design principles. McKinsey’s IDP reference architectures (which I shared in last week’s newsletter) were informed in large part by these same principles, so I recommend learning (and following) them👇

1️⃣ Prioritize your users. Developers are your platform’s most important customers, so do what it takes to deeply understand their workflows and pain points. Keep the conversation going by involving users in the design, prioritization of features, and testing. This is how you ensure the platform is fully self-service and usable.

2️⃣ Run your platform like a start-up. You’ll want a small central team that truly owns the platform and is responsible for marketing it. And (don’t forget this bit) they’ll need the resources to make it all happen.

3️⃣ Build golden paths, not golden cages. If you think forcing developers to use your abstractions is going to work, you’re 100% wrong. And you’ll create a ton of security vulnerabilities in the process.

4️⃣ Drive standardization by design. Platform engineers should define how to vend resources and configuration so developers can self-service the IDP with confidence that the result is secure, compliant, and well-architected.

5️⃣ Implement Dynamic Configuration Management. Dynamic Configuration Management slashes config complexity and enforces standardization by continuously generating app and infrastructure configs with every. single. deployment.

6️⃣ Let developers decide on their platform interface. IDPs should never break developers’ workflows or (try to) force them to use a specific interface. Instead, they use a code-based workflow by default, with the option to use a UI, CLI, or API.

7️⃣ Keep code as the single source of truth. When everyone is working from the same version, the risk of errors is minimized.

Short on time? ⏳ We got you 🥐😋

َQuick Bites

• “Still using story points? Tired of arguing about if the defects in this release are enhancement requests or not? Just fed up with poor quality? ‘Code harder’ doesn’t fix it.” Bryan Finster shared how his team found a solution in a 5-minute read you won’t want to miss.
• Dr. Milan Milanović shared what he thinks a DevOps engineer’s roadmap should look like in this viral tweet. What do you think of his picks?

• I enjoyed this article about how DoorDash migrated from StatsD to Prometheus, particularly because it discusses how engineering organizations respond when legacy infrastructure fails to adequately scale alongside the business.
• For the folks working on Slack’s platform, the key to improving developer experience was “approaching challenges with the openness and curiosity of a beginner.” The lessons shared in this TNS article definitely apply to Internal Developer Platforms, also.
• A friendly reminder to invest in life outside of work. Platforms can only do so much to prevent burnout.

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it our way.

Stay crunchy 🥐

Luca

‍