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

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

10x engineer or 10x impact?

26 May

Hiring 10x engineers is hard for most companies. It’s a tough battle out there for talent. So how should most companies approach building their team?

Building A Team
Leadership
Hiring
Coaching / Training / Mentorship
Vaidik Kapoor

Vaidik Kapoor

VP Engineering - DevOps & Security at Grofers

How to Streamline Your Recruitment Process for Quick and Effective Hiring

26 May

Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.

Scaling Team
Building A Team
Hiring
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

How to Maximize Employee Retention in Engineering Teams

25 May

Vimal Patel, Founder and CTO at iMORPHr, shares how he retained all of his employees since beginning his software development company in 2019.

Building A Team
Company Culture
Hiring
Retention
Psychological Safety
Vimal Patel

Vimal Patel

Director of Engineering at iMORPHr

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.