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

🔥

Back to resources

How to Build a Platform Team

Building A Team

9 March, 2021

Jeff Miller
Jeff Miller

Senior Director, Platform 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

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

Managing New Team Members

6 October

Harsha Shekar, Engineering Manager at Atlassian Corporation Plc, explains how he brought up and eased new members into his team, while navigating through multiple challenges.

Building A Team
Collaboration
Motivation
Harsha Shekar

Harsha Shekar

Engineering Manager at Atlassian

Building an Organization From the Ground Up

19 September

Arpan Dalal, Sr. Director Engineering at RepairPal, speaks of his effort to build an organization from the ground up in a brand new domain of the mom-and-pop gardening space.

Product
Building A Team
Impact
Arpan Dalal

Arpan Dalal

Sr. Director Engineering at RepairPal

Scaling Teams to Make Better Decentralised Decisions via Documents and Tenets

6 September

Kirsten Zverina, Head of Product at Abethos Ventures, shares some decision-making mechanisms like FAQs and tenets, that can help reduce the pain of scaling teams.

Product Team
Scaling Team
Building A Team
Team Processes
Kirsten Zverina

Kirsten Zverina

Head of Product at Abethos ventures

Getting Ready for a Cold Start

25 August

Alex Oleinikov, Software Engineering Manager at People.ai, shares how he started a team from scratch and what he had to put in place before the first hires began to arrive.

Mission / Vision / Charter
Building A Team
Alex Oleinikov

Alex Oleinikov

Software Engineering Manager at People.ai

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.