Plato

Login to Plato


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Building a Platform Team

Building a Team
Dev Processes

27 February, 2021

Max Countryman, Director of Engineering, Platform at Pathstream, outlines the difference between a platform and product team, along with the key elements to pay attention to when building a platform team.

Problem

When we started out, we were only five engineers, all on the same team. We were all full-stack developers, wearing many hats and doing a variety of things. As the company grew, and more people were joining in, the inherent division between product and platform engineering started to appear.
 

It is natural for teams to specialize at some point, and the first and fundamental distinction is between the product and platform. The highest level of distinction is that the product team is building new things, and they are the ones pushing things forward, while the platform team rushes nowhere; it is committed to making other teams faster and more reliable.
 

Actions taken

First off, you should identify when it is the right time to do the split. Building a platform team starts with finding an inflection point for building the two teams. There is probably no much need for a separate platform team in the earliest days, and it will likely be premature to start it. In my experience, that moment became obvious as the value of spending engineering cycles to optimize what we were doing became more apparent. For us, that was also strongly connected to the size of the team, and we wondered if we could operate as a single unit with already 15 engineers. We were still a fairly small team, but there was much emphasis on efficiency that made sense for us to do the split.
 

The split often coincides with the moment of finding a product-market fit. If you still haven’t figured out what you should be doing as a company, you probably don’t need two teams, and you should first find your product-market fit.
 

Platform teams are built differently in different companies. If there is a group of engineers with a keen interest in the platform work, formalizing the team will be undemanding; otherwise, you will have to start hiring people with matching competencies. This is exactly what I am currently doing at my new company; I am hiring people externally to build the platform team from the ground up.
 

Again, the specific profile will differ from one company to another. At my current company, I first hired a data engineer because we are heavily data-driven, and this was our most immediate need. That being said, you need to identify what specific initiatives you will be working on in terms of efficiency and optimization and hire for those.
 

In small companies, platform teams are mostly flat with people wearing many hats. In my current company, all platform engineers are titled software engineers, and there is no hierarchy. However, as the mandate becomes more specialized, subteams will naturally emerge. Larger platform teams typically apply more rigid structures with subteams, managers, and specific domains like observability or site reliability. I personally prefer to organize teams according to North Star that directly correlates with metrics. Perhaps, that is not a model to start with, but in the longer run, I would like to structure the team in a manner that would allow them to quickly quantify the progress they are making toward the key metrics. For example, site reliability is a domain we care a lot about, and I would organize a team around it. Then, we should be looking at the site uptime and have a specific SLA or SLO that would help the team track its progress.
 

Another significant difference that impacts the structure is that the product engineering team works on a shorter time horizon. In the early days, startups tend to iterate fast and have a short time horizon (unless they have a well-defined product and longer-looking product goals). Platform engineering by design works on a longer time horizon and focuses on what it could do irrespective of near-term deadlines. It often entails a systemic change or large refactor that would pay off in terms of velocity and efficiency, but not immediately.
 

Finally, there is a specific set of metrics -- DORA metrics -- specific to DevOps but could serve as an interesting guideline for a broad set of engineering teams. More specifically, DORA includes four key metrics: Deployment Frequency (DF), Mean Lead Time for changes (MLT), Mean Time To Recover (MTTR) and Change Failure Rate (CFR). If you would, for example, be able to establish that there is a bottleneck between a moment when a feature was finished and when it was shipped into production, by fixing only that component, the overall end-to-end process will be more efficient.
 

Lessons learned

Don’t split the team too soon, but don’t wait for too long either. I still believe that in my previous job, we should have done it a bit sooner. One of the things I am genuinely excited about at my current job is that we are splitting up the team just before I think we need to split them, and that is going to end up being quite advantageous. If you can time it, try to do it just before you need to. You want to err on the side of doing it a bit sooner rather than later.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building a New Domain Team
6 April

Thomas Lamirault, Engineering Manager at BlaBlaCar, shares how he built a brand new team by transforming an existing component-based team into a domain-based one.

Building a Team
Thomas Lamirault

Thomas Lamirault

Engineering Manager at Ubisoft

Shipping Products Faster with Confidence
26 March

Ian Logan, VP of Engineering at Rose Rocket, explains why the speed of execution is critical for finding a product-market fit and highlights how to build confidence when shipping fast.

Dev Processes
Team processes
Ian Logan

Ian Logan

VP Engineering at Rose Rocket

Building a DevOps Team and Re-Architecting the Product: A Matter of Priority
26 March

Sankar Nair, VP of Engineering at Novantas, shares how he built a DevOps team and helped architecture the product when the business didn’t consider it a priority.

Dev Processes
Team processes
Convincing
Sankar Nair

Sankar Nair

Vice President of Engineering at Novantas

Increasing Test Coverage
16 March

Guy Baron, Head of R&D at Wix, explains how he increased test coverage by developing and implementing a data-driven test strategy.

Dev Processes
Guy Baron

Guy Baron

Head of R&D at Wix.com

How to Build a Platform Team
9 March

Jeff Miller, Senior Director of Platform Engineering at Yello, speaks of building a platform team and how he applied Domain-Driven Design to organizational development.

Building a Team
Jeff Miller

Jeff Miller

Senior Director, Platform Engineering at Yello (formerly known as RECSOLU)

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.