Hey there! This is Platform Weekly, the gnarliest wave in the platform engineering ocean. 🏄🤟

This week’s issue is one you won’t want to miss. Bryan Finster of DevOps Dojo fame is weighing in on the top platform pitfalls you should avoid. Check it out and share the platform ♥️ with your friends!

Let’s get bakin’

Avoiding common platform pitfalls

Bryan Finster, Value Stream Architect at Defense Unicorns

Platform engineering has become a hot topic in the industry recently. However, it’s not a new practice. Doing it correctly seems to be the main sticking point. The problems that occur are common and generally come down to one problem, lack of user-centric focus. Comparing notes with many other organizations, these are some of the most common pitfalls I’ve seen.

Platform as a Mandate

A central tools team is formed to decide what tools the developers will use. The tools are bought or built, and management mandates that everyone uses them. Little or no thought is given to discovering the problems that development teams face daily, and the tools team’s primary focus is on operations, not customer service. The result is hostile customers and a platform that either improves nothing or degrades productivity. It doesn’t even matter if the new tools are better. The lack of empathy and engagement with the people doing the work means that even better tools will be used to re-implement bad patterns. The workflow of the development teams has been disrupted, an adversarial relationship has been created, and delivery suffers.

If we need to use a mandate to increase adoption, we’ve done a poor job of solving the right problems and/or helping our customers understand how the new tools can be used to make their lives easier.

Platform as a Service Ticket

We’ve created a platform, but to use it requires teams to open a ticket, wait in a queue, and have someone outside the team do the work of configuring it. Growing the number of people using the platform will require growing the number of people supporting it. The worst outcome for the platform is that more people use it, and the platform effort is crushed by operational overhead. Worse, the onboarding process can impact application architecture. “We want to use an event-based microservice architecture to enable auto-scaling for peak capacity, but it takes two weeks to create a pipeline…”

It’s not a useful platform if it’s not self-service. That should be a baseline requirement to improve both user experience and keep operational costs down.

“We built this great thing. Why won’t people use it?”

What incentive do they have to change? Is it solving their problems better than what they have? Is it solving a real problem at all? Does it make it easier for them to meet security and compliance requirements? How heavy is the lift for them to adopt your new solution? What support are you providing to help them? Did we only build it because it would be “cool?” We should start with the adoption plan before we start implementation. Who can we partner with to help first? What are our plans for identifying and prioritizing the problems we are solving? What incentives can we introduce to encourage adoption? How about marketing, training, workshops, etc? We need to be user-centric and not assume we know what’s needed. We should focus on the problems that impose delivery drag, not solutions that are splashy but don’t relieve daily pain.

Focus on the Customer

Avoiding these and other pitfalls is easy, we should treat internal users the way we would want to be treated, with empathy and respect. We talk to them, understand their problems, and help make it easier to do their work. Platforms should be built with the same empathy and mindset we would use for building great products for external customers. It’s even easier to deliver great experiences to internal users because user feedback and collaboration are so much easier. All that’s required is to establish that collaborative relationship and leverage their feedback. I had a conversation about platform development with someone from Exxon several years ago. He said, “It seems the top developers tend to end up in our platform area because they can be closer to their customers.” I know that’s true for me. If that doesn’t resonate with you, there may be a problem.

‍

Short on time? ⏳ We got you 🥐😋

🥐 ICYMI: Kubiya launched the first generative AI for platform engineering at KubeCon 2023.

🥐 Does platform engineering make software sustainable? 🍃

🥐 DevOps ain’t dead… but we’ve gotta talk.

🥐 Here’s why Python will eventually die.

Last but not least, have you joined the Platform Engineering Slack channel? If not, you're missing out. Here are some highlights:

• Metrics are always a relevant topic. This time, Roni is asking: How should I be thinking about what metrics to look for when it comes to test automation for improving DevEx?
• Want to benchmark toolsets and technologies?
• Flux vs ArgoCD: What GitOps platform do you use?
• How’s the platform engineering job market faring? Some folks in the community are trying to find out.

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

‍