How to Build a Platform Team

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.