Platform Teams hold an important position. They are the architects of the internal systems and tools that power product development. Like the builders of the mythical Tower of Babel, they can either create structures that reach for unprecedented heights of efficiency or become mired in miscommunication and misplaced ambition.

The  “if I build it, they will come” mindset is one of the pitfalls platform teams sometimes fall into. Building on my previous article, while impressive feats of engineering might arise, these platforms can ultimately be rendered useless if they don’t fundamentally address the core needs of the engineers who build the company’s products. This is the tech-for-tech’s sake fallacy that hinders rather than accelerates true innovation in many businesses.

The Peril of a Tech-Centric Focus

When Platform Teams prioritize technology for its own sake, they risk creating solutions that prioritize elegance over utility. They might get enamored by the latest shiny framework or bleeding-edge distributed systems, only to realize that these complex additions bring little tangible benefit to the product engineers. This can lead to several  consequences:

  • Complexity creep: Overly engineered platforms introduce unnecessary layers of abstraction, making the development process more convoluted and harder to understand.
  • Frustrated engineers: If product engineers find the platforms difficult to use or incompatible with their workflows, it creates friction, leading to resentment and workarounds that undermine the platform’s purpose.
  • Missed deadlines: When engineers spend too much time wrestling with the platform, it slows down product development and reduces time-to-market.
  • Stifled innovation: Complex, unintuitive platforms discourage experimentation and diminish the product teams' ability to rapidly address changing customer needs.

The True Mission

The primary mandate of a Platform Team should be to empower product engineers to build the best products possible. This requires a fundamental shift in perspective, from building the most technologically advanced platforms to building the most effective and usable ones. Platforms should be seen as a means to an end, not an end in themselves.

So, how do successful Platform Teams create this product-centric environment?

Deep Empathy for Product Developers

The first step is to develop a deep understanding of the workflows, pain points, and aspirations of the product engineers. This involves:

  • Shadowing and observation: Platform Team members should spend time shadowing product engineers, observing their daily routines, and understanding how they currently interact with technology.
  • Interviews and feedback: Proactive surveys and feedback mechanisms are crucial to gather qualitative data on the challenges engineers face and how platforms can better support them.
  • User-centric design: principles of user-centered design should be applied to internal platforms with the same rigor as any customer-facing product.

Focus on Outcomes, Not Just Outputs

Instead of measuring success by the sheer technical sophistication of the platform, teams should track metrics that demonstrate how the platform is tangibly impacting product development. These metrics could include:

  • Lead time to deployment: How long does it take from a code commit to a feature being available to customers?
  • Incidents and downtime: How frequently do infrastructure issues occur, and how quickly are they resolved?
  • Developer satisfaction scores: Regularly survey product engineers to gauge their satisfaction with the platform’s usability and effectiveness.
  • Product innovation metrics: Are new features being shipped more frequently? Is the business addressing customer needs in a more agile manner?

The Art of Abstraction (Without Obscuration)

Platform Teams should strive to abstract away common, repetitive tasks and reduce cognitive load for product engineers. However, this abstraction should be done thoughtfully to retain the necessary level of visibility and control:

  • Intelligent defaults: Provide sane defaults and best practices baked into the platform, reducing the number of decisions required of developers.
  • Self-service tooling: Give product engineers the ability to provision infrastructure, manage dependencies, and monitor their applications without needing hand-holding from the platform team.
  • Transparent Documentation: Ensure platforms are well-documented with clear explanations, examples, and a focus on practical problem-solving.

Collaboration, Not Dictation

Building a successful product-centric platform requires close collaboration between Platform Teams and product teams. Open communication channels and a shared sense of ownership are vital. This involves:

  • Joint roadmapping: Platform and product teams should work together to define a roadmap that aligns with business goals and addresses the most pressing pain points.
  • Open-source mindset: Where feasible, encourage internal open-source practices, allowing product engineers to contribute to and improve platforms, fostering a sense of shared responsibility.
  • Embedded engineers: Consider placing platform engineers directly within product teams temporarily to facilitate knowledge transfer and deeper understanding of specific needs.

Iteration over Perfection

Platforms should be treated as living, breathing products themselves. The “big bang” launch approach is a recipe for failure. Instead, platforms need to be launched, adopted, and continuously refined based on real-world feedback.

  • Minimum Viable Platforms (MVPs): Start with platforms that address specific, high-impact needs, focusing on essentials. Prioritize ease of use over having a comprehensive feature set initially.
  • Rapid feedback loops: Implement robust monitoring and telemetry on platforms to understand how they are being used. Regularly seek feedback from product engineers for targeted improvements.
  • Culture of experimentation: Encourage product engineers to test the boundaries of the platform and share their experiences. Embrace the idea that platforms will evolve over time.

The Right Kind of Babel Tower

It’s important to recognize that Platform Teams do need a degree of technical autonomy in order to build robust and scalable foundations. The key is to strike the right balance between this need for technical excellence and the overarching goal of making product engineers' lives easier.

In essence, Platform Teams should strive to be like the skilled builders who constructed the great cathedrals of the past. Those creations were technical marvels in their own right, but their true purpose was to serve a higher need - to provide spaces that inspired, uplifted, and enabled greater achievements.  Similarly, modern platforms need to be more than just feats of technical ingenuity. They need to be the cathedrals of the software world, empowering teams to deliver exceptional product experiences that drive the business forward.

Shifting From Tech-First to Product-First

This transformation from “if I build it, they will come” to a mindset of product-centric enablement might require a cultural shift within many organizations.  Support from leadership is essential to instill the understanding that focusing on platform strength aligns with the company’s broader goals, even if those platforms might not always be the flashiest pieces of the tech stack.

By prioritizing empathy, impact, collaboration, and iteration, Platform Teams can transcend their technical prowess and become the bedrock of product innovation. In doing so, they break down the silos of the Babel Tower and help forge a company where technology truly serves the ultimate goal – creating extraordinary products that customers love.