Back to resources

How to Build a Platform Team

Building A Team

9 March, 2021

Jeff Miller
Jeff Miller

Vice President, Engineering at Yello (formerly known as RECSOLU)

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.

Problem

At some point in a company’s development -- when a startup is maturing, a new product is coming up, or an acquisition is taking place -- a need for a platform team may emerge. The actual scenarios could differ greatly; the new platform team needs to support multiple brands and their shared core features/services, or the team expanded out in the feature sets to differentiate customer-facing and infrastructure features, to name a few.

Actions taken

I would carefully observe either my organization or the organization overall, seeking patterns in development. For example, I would note down if we would commonly get requests to do specific things regardless of their root cause. Once I would identify recurring patterns, I would apply the approach popularized by Eric Evans in his seminal book Domain-Driven Design. Evans argues that the structure and language of software code (class names, class methods, class variables) should match the business domain. While Evans is concerned with how to structure software, I would apply his principles to organizational development. The first thing I would do would be to define what are the common domains we would use across brands or platforms and what would be the features we could develop and roll out to different places.

When building a platform team, I prefer to start small. I would gather a small group of engineers consisting ideally of engineers who had experienced the full scope of the company and had seen a great variety of problems. They could be high performers, but that would be less important than their eagerness to solve the broader problems that affect a great number of people. Giving their best contributors to a newly formed platform team may be a tough pill to swallow for feature teams, but they should be able to see the overall benefit. I would make sure to explain that the platform team will be building in one place things that will be used in many places across the company.

Once you build a common platform, you have to roll it out to the features teams. The most straightforward approach is to implore those teams to use the software you built, explaining how it will benefit their team or department. Another approach -- that tends to be particularly helpful early on in the process -- is to disperse and embed platform engineers into feature teams to help them with integration. For a sprint or two, engineers could be distributed across the organization to streamline and smooth out the integration process.

As the team grows, the need to split the team could become more justified. I would start by building subteams around the technical domain, for example, global components. If you are developing in React, you could have one team that standardizes its components for the rest of the organization to use. They could do security patches that are rolled out across the organization or build toolsets that are installed everywhere. The platform team could be also split by the business domain. For example, a fintech lender could have its sub-teams organized around issues like the identity of its customers, accounting, or communication. I find the latter approach to be more digestible to the business, but it is not the easiest approach to start with since you have to map out all the issues first. Splitting into sub-teams should happen organically following the logic of the team processes, but if that for whatever reason won’t work, you can always resort to the splitting based on the type of development (back-end, front-end, security, etc.).

I find the scope to be the most determining factor when building a platform team. If you are a B2B company with individual business clients, you will need to approach problems from a broader perspective. You will build a generic solution that will allow for standardization, which is rarely the shortest route to the market. While a feature team may cut a corner or two to get it into the MVP state, a platform team will work on projects that are larger, longer, and more sustainable.

Lessons learned

  • For the platform team to be successful, it should be able to address both technical and business challenges. It takes a lot of listening, networking, advocacy, etc., but the more you are able to marry the technical and business side, the more successful your initiatives are going to be.
  • Though I prefer to populate my platform team with more experienced engineers, I am careful not to limit it exclusively to them. That can create a culture of arrogance, “We are the platform team, and we know how to do things” that can stagnate growth. Without juniors on the team, more experienced engineers will have no one to mentor and cultivate their managerial skills. The platform team should be a diverse team, not the elite forces of any type.
  • Don’t try to boil the ocean. While the duration of platform projects is relatively long, don’t overextend it to six months or a year-long target date. If you don’t show some progress or value in a reasonable amount of time, you will have a difficult time justifying your existence. However, set the expectations a bit longer than you would for a feature team. I don’t have a magical recipe number, but if you have just started a team and are still used to estimate on a feature, I would suggest adding a buffer because you are approaching a problem in a more generic way.

Discover Plato

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


Related stories

Managing remote first organization

4 January

I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.

Building A Team
Company Culture
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero