A Platform Team's Guide to Inevitable Failure

In the realm of software development, a platform team is the unrecognized hero, toiling away in the shadows to ensure engineers can build and deploy their applications with ease. However, there's a dark side to platform teams, a side that can turn your highly praised platform into a tangled mess of frustration and misery.

Here's a comprehensive guide to ensuring your platform team is a complete disaster, a source of pain, and a drain on the overall productivity of your organization.

Focus on Tools, Not People

Prioritize building cutting-edge tools and complex systems, even if they're completely irrelevant to the needs of the engineers who will actually be using them. After all, who cares about what developers want? They're just glorified code monkeys.

Ad-hoc Support Slack Channel

Create a Slack channel as your sole support system. This will ensure that the same questions are asked and answered repeatedly, consuming the time of both developers and platform staff. Who needs a central knowledge base when you have a never-ending stream of ad-hoc questions?

Avoid Engaging with Developers

Minimize interactions with developers, especially during the design and development phases. After all, you're the expert, right? Your knowledge is superior to theirs, so why bother asking for their input? Just make assumptions and hope for the best.

Neglect Data Collection

Don't bother collecting historical data or metrics related to developer behavior and usage patterns. It's not like understanding how developers interact with your tools and platforms will help you make informed decisions or identify areas for improvement.

Set Unrealistic Timelines and Avoid Prioritization

Prioritize every idea and issue as top priority, creating an atmosphere of perpetual urgency and stress for teams to embrace your latest moonshot project. And of course, avoid setting realistic timelines, since you're the genius on a mission to save the company and humanity.

Ignore Business Priorities

Ignore the company's strategic priorities and goals, especially when it comes to initiatives that directly impact developers. After all, Platform is its own little island, separate from the real world.

Hire Only External

Recruit only experienced Platform professionals from outside the company. Why bother promoting or training internal developers, even if they have the potential to grow into valuable members of the team? After all, industry experts are always better than homegrown talent.

Build for the Future, Not the Present

Focus on developing platforms that are far ahead of the current needs and capabilities of your developers. Why bother addressing immediate pain points when you can build something that might be useful in five years?

Move Fast, Break Everything

Deploy new features and functionalities without proper testing or staging rollouts. Just throw them over the fence, developers or their customers will tell you if they work or not. That's their job, right?

Document Minimally, or Not at All

Provide bare-bones documentation for your tools and platforms. After all, developers are supposed to be smart enough to figure things out on their own, right? Don't waste precious time explaining things to them.

Never Deprecate, Ever

Never officially deprecate old tools, libraries, or features, even if they are no longer supported or maintained. After all, you don't want to upset those who are still using them. That would be rude.

Ignore Inner Source Contributions

Discourage and reject contributions from developers, even if they have valuable ideas or improvements to suggest. After all, they're not part of the Platform team, so their input doesn't matter.

Blame the Developers for Everything

Whenever there's a problem with your tools or platforms, always blame the developers. Never take ownership of your own shortcomings or shortcomings in your work. After all, you're the expert, right? It must be the developers' fault.


This guide may seem like a parody, but it highlights some of the common pitfalls that Platform teams can fall into.

To avoid these pitfalls, Platform teams must adopt a customer-centric approach, treating their services as products that need to be carefully refined and continuously improved.

Was this article interesting or helpful?

Stefan Buck
Written by
Stefan Buck is Software Engineer since 2006. In 2013, he created OctoLinker, a browser extension for GitHub trusted and used by over 30,000 developers. Since then, constantly striving to enhance the developer experience with tools such as Pull Request Badge, Jumpcat, and more recently Tentacle,