Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Building a Platform Team

Building A Team
Dev Processes

27 February, 2021

Max Countryman
Max Countryman

Director of Engineering, Platform at Pathstream

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

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Alignment
Product
Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

The Problem-Solving Process: A Modern, Data-Driven Approach for Engineering leaders

28 October

Sudheer Bandaru, CEO at Insightly Analytics, recalls how he formed a company for carrying out data-driven solutions to daily engineering problems.

Dev Processes
Team Processes
Sudheer Bandaru

Sudheer Bandaru

CEO at Insightly Analytics

Taking The Lead As A Manager In Crisis

14 October

James Tobias, Senior Product Manager at Mapware, unveils a riveting journey to build a product from ground zero successfully.

Product Team
Product
Dev Processes
James Tobias

James Tobias

Senior Product Manager at Mapware

Strategic Ways to Stop Losing Customers

13 October

Mary Fisher, Software Engineering Manager at DrChrono, shares how diligently she worked with teams within her organization to retain customers.

Alignment
Innovation / Experiment
Product
Dev Processes
Convincing
Tech Debt
Prioritization
Mary Fisher

Mary Fisher

Software Engineering Manager at DrChrono

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.