Platform Antipatterns - When Good Intentions Go Wrong

The road to platform hell is paved with good intentions.

I've been there. We all have. You start with noble goals: reduce complexity, enable teams, ship faster. But somewhere between conception and reality, something goes sideways. Your golden path becomes a prison. Your self-service portal becomes a bureaucracy machine. Your platform team becomes the bottleneck you were trying to eliminate.

The cruel irony? The worse these antipatterns get, the more they look like success from the outside. Adoption metrics climb. Standardisation spreads. Leadership nods approvingly at the dashboards.

Meanwhile, your best engineers are quietly planning their escape.

After years of building, breaking, and rebuilding platforms across different organisations, I've captured the most insidious antipatterns that turn well-intentioned platform initiatives into engineering nightmares IMO. Recognise these early, and you might just save your platform - and your sanity.

1. The Cathedral Antipattern: "We Know Best"

What it looks like: The platform team designs everything in isolation, then unveils their masterpiece to the organisation. Beautiful architecture diagrams. Comprehensive documentation. Zero input from actual users until launch day.

Why it happens: Platform engineers are often senior, experienced, and genuinely passionate about good engineering practices. They see the mess of inconsistent tooling and think, "I can fix this." The temptation to build the perfect solution is overwhelming.

The warning signs:

• Platform design sessions happen without delivery team representatives
• The phrase "they'll understand once they see it" gets used regularly
• Documentation is written before the first user interview
• Platform features are justified by technical elegance rather than user problems

Why it fails: Engineering teams have context you don't. Their "messy" solutions often solve real problems you haven't discovered. When you ignore this context, you build platforms that work beautifully in demos but fall apart under real-world pressure.

The recovery: Stop building. Start listening. Embed with delivery teams for a week. Shadow their daily workflows. Understand their pain before prescribing your medicine.

2. The Swiss Army Knife Antipattern: "One Platform to Rule Them All"

What it looks like: Your platform tries to solve every possible engineering problem. CI/CD, monitoring, secrets management, deployment, testing, documentation, project management, coffee ordering... If it touches engineering, it's in scope.

Why it happens: Scope creep is seductive. Every team has different pain points, and each one feels urgent. Saying "no" feels like you're not being helpful. Plus, integrated solutions do provide better user experiences - when they work.

The warning signs:

• Your platform roadmap looks like a software vendor's entire product suite
• You're rebuilding functionality that existing tools already provide well
• Team retrospectives mention learning your platform as a significant overhead
• Your platform documentation needs its own search engine

Why it fails: Complexity compounds exponentially. Every new capability increases the surface area for bugs, security issues, and maintenance overhead. Your platform team becomes spread thin across too many domains, delivering mediocre solutions to every problem instead of excellent solutions to the most important ones.

The recovery: Choose three core capabilities and nail them. Everything else should integrate, not replicate. Remember: you're building a platform, not an operating system.

3. The Golden Cage Antipattern: "Standardisation at All Costs"

What it looks like: The platform enforces uniformity through technical constraints. One language, one framework, one way to deploy, one monitoring stack. Deviation isn't just discouraged - it's technically impossible.

Why it happens: Consistency is genuinely valuable. It reduces cognitive load, simplifies operations, and makes engineers more interchangeable across teams. The benefits are real and measurable.

The warning signs:

• Engineers describe your platform using prison metaphors
• "But that's not how the platform works" becomes a common phrase
• Teams start building shadow infrastructure to work around limitations
• Innovation proposals are evaluated primarily on platform compatibility

Why it fails: Different problems require different solutions. When you force every team through the same constraints, you optimize for the average case and harm the edges. Innovation dies. Your best engineers leave for places where they can choose their tools.

The recovery: Build golden paths, not golden cages. Make the right thing easy, not the only thing possible. Provide escape hatches for legitimate edge cases.

4. The Ivory Tower Antipattern: "We Don't Do Support"

What it looks like: The platform team builds tools but doesn't get involved in day-to-day usage problems. "That's a team issue, not a platform issue." User questions get redirected to documentation or community forums.

Why it happens: Platform engineers often come from infrastructure backgrounds where abstraction and self-service are core principles. The goal is to build systems that don't need human intervention. Plus, doing support doesn't feel like "real" engineering work.

The warning signs:

• Your platform team spends less than 20% of their time on user support
• Bug reports get classified as "user error" by default
• You measure success by reducing support tickets rather than increasing user satisfaction
• Platform team members can't describe common user workflows in detail

Why it fails: Platforms are products, and products need product support. When users struggle and can't get help, they stop using your platform. Worse, they build workarounds that make your standardisation efforts meaningless.

The recovery: Embed support into your platform team's identity. Make it a shared responsibility, not a separate function. Use support interactions as product feedback - they're gold mines of user insight.

5. The Perfection Paralysis Antipattern: "It's Not Ready Yet"

What it looks like: The platform team spends months or years building the perfect solution before releasing anything. Every edge case gets covered. Every integration gets polished. Every potential workflow gets supported.

Why it happens: Platform work is highly visible. When it breaks, everyone notices. The pressure to get it right the first time is immense. Plus, platforms have network effects - a bad first impression can poison adoption permanently.

The warning signs:

• Your platform has been "almost ready" for more than six months
• Demo environments work perfectly but real-world testing keeps getting delayed
• The phrase "we should support X before we launch" comes up regularly
• You're building features for hypothetical future users rather than current real ones

Why it fails: Perfect is the enemy of good. While you're polishing your masterpiece, teams are inventing their own solutions. By the time you launch, your beautiful platform is solving yesterday's problems.

The recovery: Launch an intentionally limited MVP with one golden path for one type of application. Get real usage data, then iterate based on actual needs rather than imagined ones.

6. The Metrics Theatre Antipattern: "Look at Our Adoption Numbers"

What it looks like: Platform success gets measured by vanity metrics: number of services onboarded, API calls per day, percentage of teams using the platform. The dashboard looks great, but engineers are miserable.

Why it happens: Platform value is genuinely hard to measure. Productivity gains are diffuse and long-term. It's much easier to count things than to measure satisfaction or effectiveness.

The warning signs:

• Platform metrics focus on usage quantity rather than user satisfaction
• You can't explain how platform adoption translates to business outcomes
• Teams use your platform because they have to, not because they want to
• User feedback sessions are rare or superficial

Why it fails: High adoption with low satisfaction is a ticking time bomb. Teams will find ways to work around systems they hate. Your metrics look good right up until the moment they don't.

The recovery: Measure outcomes, not outputs. Track time to first deployment, cognitive load reduction, and engineer satisfaction. Do regular qualitative interviews. Ask hard questions about whether your platform actually makes people's lives better.

7. The Not-Invented-Here Antipattern: "We Can Build It Better"

What it looks like: Instead of integrating or extending existing tools, the platform team rebuilds everything from scratch. "Kubernetes is too complex, we'll build our own orchestrator." "GitHub Actions doesn't fit our workflow, we'll create our own CI system."

Why it happens: Engineers love building things. Existing tools often have quirks or limitations that seem easy to fix with a clean implementation. The NIH syndrome is particularly strong in infrastructure teams.

The warning signs:

• Your platform includes multiple components that replicate existing open-source tools
• Evaluation of existing solutions focuses on limitations rather than capabilities
• "We could build that in a weekend" is a common phrase
• Your platform team spends more time on infrastructure than on user experience

Why it fails: Every piece of custom infrastructure becomes a maintenance burden. While you're fixing bugs in your homegrown orchestrator, your competitors are innovating on top of battle-tested tools. The opportunity cost is enormous.

The recovery: Default to buy/adopt, not build. Only build custom components when the alternative genuinely doesn't exist or creates insurmountable constraints. Focus your engineering time on the thin layer that makes existing tools work better together.

8. The Platform Drift Antipattern: "We'll Figure It Out as We Go"

What it looks like: The platform evolves organically without clear direction. New features get added based on whoever shouts loudest. Architecture decisions get made reactively. Six months later, nobody can explain why certain design choices were made.

Why it happens: Platform teams are often under pressure to deliver quick wins. Strategic planning feels like overhead when there are urgent user requests. Plus, the problem space genuinely evolves as the organisation grows.

The warning signs:

• Platform architecture has grown organically without clear design principles
• Feature decisions get made in Slack conversations rather than formal planning
• Different parts of the platform feel like they were built by different teams
• Onboarding new platform team members takes weeks because nothing is documented

Why it fails: Platforms without clear direction become maintenance nightmares. Inconsistent interfaces confuse users. Technical debt accumulates faster than features get delivered. Eventually, you end up rebuilding everything anyway.

The recovery: Define your platform's core principles and design philosophy. Make architectural decisions explicit and documented. Regularly review whether new features align with your vision. It's never too late to impose some intentional design on organic growth.

---

Breaking the Pattern

Here's the thing about antipatterns: they're not character flaws or signs of incompetence. They're natural responses to complex organisational pressures. Every platform team faces the tension between perfection and delivery, between standardisation and flexibility, between autonomy and support.

The key is recognising these patterns early and course-correcting before they become entrenched. Some practical advice:

Build feedback loops into everything. Regular user interviews, embedded team time, and honest retrospectives aren't overhead - they're essential platform infrastructure.

Start small and grow deliberately. Every successful platform I've seen started by solving one problem extremely well, then expanded thoughtfully based on real user needs.

Measure what matters. Adoption without satisfaction is meaningless. Focus on outcomes: are teams shipping faster? Are engineers happier? Are systems more reliable?

Stay humble. Your users know their problems better than you do. Your job is to amplify their capabilities, not to replace their judgment.

Design for trust. Every platform decision should ask: does this increase or decrease trust between the platform team and delivery teams? Trust is your most valuable currency.

---

Platform engineering isn't just about technical architecture - it's about human systems. The most elegant technical solution will fail if it ignores the human context it operates within.

So the next time you're designing a platform feature, ask yourself: am I solving a real user problem, or am I falling into one of these traps? Am I building something that engineers will love to use, or something they'll have to use?

The difference between the two is often the difference between platform success and platform failure.

And in the end, that's what separates great platform teams from the rest: they build tools that engineers choose, not tools that engineers endure.

What antipatterns have you encountered in your platform journey? I'd love to hear your war stories and recovery strategies in the comments.

---

#PlatformEngineering #DeveloperExperience #DevOps #EngineeringLeadership #TechStrategy