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

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Senior Engineering Manager at Curology

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Effective Hiring Practices: Asking the Right Questions

23 June

Josef Starychfojtu, VP of Engineering at Mews, delves into his interviewing tactics for recruiting the best-suited candidates.

Building A Team
Hiring
Josef Starychfojtu

Josef Starychfojtu

VP of Engineering, Platform at Mews