Lessons Learned Building Platform Teams

Navigating the Path to Success: Insights on Hiring, Measuring Value, and Iterations in Building Platform Teams

When the director of DevOps was about to depart from the fintech company I was working in, I was excited to step up and take the responsibility of the function. I saw multiple long-standing flaws in the infrastructure and observed issues with the way the DevOps team managed their operations, which had evolved into a bottleneck for the development teams, slowing down the delivery of value. So, I put up a plan to create a platform cluster as the central focus of the new engineering center.

The concept of platform teams is gaining popularity these days, with many companies utilising them to bridge the gap between software development and infrastructure. However, the way companies implement the platform concept varies. The responsibilities of a platform team can range from building infrastructure to developing internal tools for software engineers. In some instances, platform teams even take on the task of building commonly used services, including customer-facing ones, that don't fit within other business teams.

In our case, the goal of the platform was to simplify service deployment and automate infrastructure provisioning. To achieve this, we decided to create a self-service tool for developers, known as the Internal Developer Platform (IDP). Due to historical reasons, the company's infrastructure had been manually constructed, making it challenging to maintain and build the IDP on top of it. While the Site Reliability Engineering (SRE) team focused on keeping the lights on, another team started rebuilding the entire infrastructure from scratch and implementing IDP. Simultaneously, yet another team concentrated on addressing developers’ needs by crafting commonly used libraries and services.

Despite the challenges we already had, there was one major issue with the approach we took. Platform teams didn't have a clear way to show their impact, leading to lower job satisfaction and failure to demonstrate a value for business. Dealing with prolonged development and lengthy feedback loops was a headache. These challenges often stemmed from inappropriate hiring decisions. So what did we do and what did we realise?

Establish Strict Hiring Process

While building an engineering center I had to hire multiple teams. My preferred approach on hiring involved conducting structured interviews. By asking the same set of questions to each candidate, you create a basis for comparing their responses and predicting how they might perform in specific scenarios. I found that the optimal number of interviews for each candidate is 3 or 4. Moreover, I preferred to have the interviews conducted by the very individuals who will be working under the new leader's guidance and by their peers. Also it’s good that someone from the development team would interview a candidate as well. This approach offers invaluable insights into what it would be like to collaborate with development teams.

To minimise confirmation bias, I suggested that interviewers refrain from sharing their opinions until all interviews have concluded. A post-interview debriefing session is conducted to consolidate and evaluate the gathered information, ensuring unbiased hiring decisions are made.

This stringent hiring process is even more important when hiring for leadership positions. During my journey of building platform teams, I had the privilege of hiring both exceptional leaders and those who fell short of expectations. The latter often resulted from the impulsive rush to fill a vacant position or ignoring early indicators of a mismatch. In hindsight, I've come to believe that it's preferable to have no leader at all than to have a subpar one. A poor leader can fail to deliver the anticipated results, disrupt team dynamics, erode team morale, or even drive other team members to consider alternative opportunities.

One of the most significant lessons I've learned through my experiences is the paramount importance of ensuring that the team leader possesses the right mindset for building platforms. Don't underestimate the power of a well-established hiring process when seeking for an ideal candidate. 

Align The Work To Business Metrics

When it comes to building platform teams, one crucial piece of advice is to treat them just like any other product team. This perspective means that we should deeply understand our clients, which, in this case, are other developers. We need to grasp their needs and pain points. To achieve this, we conducted interviews with each development team, aiming to gain insights into the issues they were facing and the areas where improvements could be made.

This way we compiled a comprehensive list of challenges and areas for enhancements. This enabled us to create a vision of where we wanted to be in the future and develop a roadmap for addressing these issues. As we started working on various initiatives we noticed that it was pretty difficult to measure the value that we created, and that contributed to reduced sense of achievement and lower job satisfaction for the platform engineers. Failure to demonstrate business value might cause the platform team to become the primary target for headcount reduction, when tough times hit the business. 

One of my personal failures in this journey was not measuring the business value. This made it hard to establish clear priorities and align them with a specific business metric. This business metric could encompass various aspects, such as improved developer productivity (measured by time-to-market), enhanced quality, improved reliability or boosted internal Net Promoter Score (NPS) of the development teams using the platform products.

Deliver value continuously

Creating self-service tools, like Internal Developer Platforms, has the potential to significantly shorten time-to-market and reduce the dependency on infrastructure and DevOps teams. However, in our case, it required substantial infrastructure refactoring. We worked for months on infrastructure refactoring and building IDP, but as the market landscape shifted and our business underwent seismic changes, most of our work lost its relevance. 

The valuable lesson I received from this experience is that executing prolonged refactoring in a single sweep doesn't yield immediate benefits for both developers and the business. When a complete rewrite spans several months, or even years, it risks becoming meaningless. Therefore, my key takeaway is to approach such challenges in small, manageable iterations and delivering value continuously.

Conclusion

The journey building platform teams proved to be both challenging and exciting. Although these insights were gained building platform teams, their applicability extends significantly to any engineering team. With a strong, well aligned team it is possible to move mountains, just do it one step at a time.