Platform Teams

For years, we've heard about "platform teams" as the holy grail of scaling engineering organizations. The promise? Reduced toil, increased developer velocity, and a focus on building rather than maintaining. But too often, the implementation feels… clunky. Teams are created, ownership is unclear, and engineers end up frustrated, navigating layers of abstraction that slow them down.

Have you ever felt the pressure to adopt a “best practice” like platform teams, only to find it adds more complexity than value? I've led engineering teams at both fast-growing startups and within larger enterprises, and I’ve seen platform teams succeed and fail. The difference isn’t usually the idea of a platform team; it’s the intentionality behind its creation and a deep understanding of what truly empowers engineers. This article dives beyond the buzzwords to explore how to build platform teams that actually deliver on their promise.

The Problem with Premature Platformization

Before we jump into solutions, let's acknowledge the pitfalls. The biggest mistake? Creating a platform team before you understand the pain points. It's tempting to think, “Let’s proactively build this!” But without clear evidence of repeated toil and duplicated effort, you’re likely creating unnecessary complexity.

I remember one instance at a previous company where leadership mandated the creation of a “self-service infrastructure” team before the individual teams had truly articulated what they needed self-service for. The result? A team building tools no one used, and engineers still resorting to manual processes because the platform didn't address their specific challenges. This initiative not only wasted valuable engineering time and resources but also negatively impacted team morale, as engineers felt their voices weren't being heard.

Key takeaway: Don't build a platform looking for a problem. Solve real problems first, then consider if a platform team is the right solution.

Identifying the Right Problems for a Platform Team

So, how do you identify those genuine pain points? Here's a framework I’ve found helpful:

1. Conduct a "Toil Audit": Ask engineers to track their time for a week or two, specifically categorizing tasks as:

   • Building Features: Directly contributing to customer value.
   • Infrastructure Management: Deployments, scaling, monitoring.
   • Tooling & Automation: Scripting, CI/CD maintenance, etc.
   • “Undifferentiated Heavy Lifting”: Tasks that don't provide a competitive advantage.

2. Look for Patterns: Analyze the audit data to identify recurring, time-consuming tasks that fall into the "undifferentiated heavy lifting" category. Are teams repeatedly writing the same boilerplate code? Are they spending hours troubleshooting the same deployment issues?

3. Prioritize Based on Impact & Frequency: Focus on the problems that impact the most teams and consume the most time. A good rule of thumb is to prioritize issues that could potentially free up at least 20% of engineers’ time, though this will vary depending on the context.

Defining the Scope of Your Platform Team

Once you’ve identified the problems, it’s time to define the scope of your platform team. This is critical. Resist the urge to boil the ocean. Start small and iterate.

Here are some examples of potential platform team focuses:

• Internal Developer Portal (IDP): A single pane of glass for accessing internal tools, documentation, and services.
• CI/CD Pipeline: Automating the build, test, and deployment process.
• Observability & Monitoring: Providing centralized logging, metrics, and alerting.
• Data Infrastructure: Managing data pipelines, warehouses, and access controls.

Important Considerations:

• Prioritize an API-First Approach: The platform team should expose well-defined APIs that other teams can easily consume. This prevents lock-in and promotes reusability.
• Focus on Self-Service: The goal is to empower other teams to solve their own problems without relying on the platform team for manual intervention.
• Establish Clear Ownership: Define clear ownership for each platform component to avoid confusion and ensure accountability.

Beyond Tooling: The Human Side of Platform Teams

Tooling is important, but a platform team is more than just a collection of tools. It's a service organization focused on enabling other teams. Here are some key principles:

• Empathy & Understanding: The platform team needs to deeply understand the needs and challenges of the teams they serve. Regular communication and feedback loops are essential.
• Documentation is King: Comprehensive, well-maintained documentation is crucial for self-service adoption. Invest in making it easy for engineers to find the information they need.
• SLAs & Support: Define clear SLAs for platform services and provide timely support to ensure a positive user experience.

Remember: A poorly designed platform, even if technically sound, can be more frustrating than no platform at all. This is why understanding the needs of your engineers should be the highest priority.

When Not to Build a Platform Team

Finally, it’s important to recognize that a platform team isn’t always the right solution. Here are a few scenarios where you might want to reconsider:

• Small Teams: If you have a small, well-functioning team, the overhead of creating and maintaining a platform team may outweigh the benefits. As the input text highlights, sometimes the “totems of Agile fly out the window” and a simpler, more collaborative approach is more effective.
• Rapidly Changing Requirements: If your requirements are constantly changing, it may be difficult to build a stable platform that meets everyone’s needs.
• Lack of Buy-In: If you don’t have buy-in from key stakeholders, your platform team is likely to fail.

Conclusion:

Building effective platform teams requires more than just adopting the latest technology. It demands a deep understanding of your organization’s needs, a commitment to empowering engineers, and a willingness to iterate and adapt. Focus on solving real problems, prioritizing self-service, and remembering that the human side of platform teams is just as important as the technology.

Key Takeaways:

• Focus on solving real problems before creating a platform.
• Prioritize self-service capabilities to empower your teams.
• Remember that a platform team is a service organization focused on enabling others.

Next Steps:

Take some time this week to survey your engineering teams and identify the top sources of toil. You might be surprised by what you discover.