Chances are you don't need a platform team...

How to minimize your platform and maximize user value

Platform teams are all the rage nowadays. But when do you really need a platform, let alone a whole team to build and operate it? Where do their responsibilities start and end? How much are they in control of workload teams? How do they work together with architects and business owners? These are some of the questions we try to answer in this article.

A tale of two models

In the beginning you will likely have just a few software engineers in your company. They all sit together at a group of desks and interact with each other on a daily basis. This can be seen as your first vertical team. They work together to build a product and ship it to customers. They make decisions in the team and do not have to worry about anything else. They are fully autonomous.

Now your company is doing very well and you are hiring more engineers. They no longer fit in a single team and you have to create another one. You now have multiple independent autonomous teams that each work on their own (part of a) product and ship it. To optimize similar capabilities and share knowledge, they talk to each other in an informal way, sometimes structured in “guilds”, “chapters”, whatever.

At a certain point, you get to a size where the model described above is no longer feasible, especially in an enterprise environment where there is a lot of outside influence on your engineering department. There is more need to standardize, or engineers simply want to focus on their core expertise instead of being responsible for an entire product. This is where you can switch to horizontal teams, where each team is responsible for a layer of one or more products.

Often you end up with layers for core infrastructure, platforms, and workloads (services, APIs, data engineers, ML engineers). It is this layer of “platforms” that is often difficult to define, but we will try anyways.

You likely don’t need a platform

By far the easiest way to answer these questions is to not have a platform, nor a team to operate it. Start off simple with an infrastructure team and workload teams. The infrastructure team manages all shared public cloud infrastructure like organization structure, networking, security policies and (audit) logging. The workload teams build and maintain their products on top of this shared infrastructure. This pattern of “cloud enablement” allows the workload teams to remain fairly independent and flexible, while not having to spend time and energy on figuring out how to securely configure a corporate cloud network.

So when do you need a platform team? Let’s say that 4 workload teams have chosen to use Kubernetes as their delivery method. You will notice that each of these teams will spend significant time finetuning and securing Kubernetes instead of shipping real end user value. This is a case when a “Container Platform” team could be introduced to reduce wasted time and simplify the work of the workload teams. A similar case can be made when having multiple teams of data engineers that just want to focus on writing algorithms to turn that data into value, so all the data and machine learning operations could be consolidated into a “ML Platform” team.

The Platform Team equation

Let’s try to generalize the examples above. Autonomous teams invest a considerable amount of effort in achieving autonomy. They need to familiarize themselves with the technology choices and stack, make decisions, and dive into topics beyond their primary focus. There comes a point where it becomes logical to introduce a horizontal layer within the organization to offer a specific level of abstraction. This threshold is reached when the sum of energy spent by each team exceeds the energy spent by a platform team to create the same value. Note that this includes the energy spent on aligning between workload and platform teams, so 4 times 1 does not equal 1 times 4!

Platforms are abstractions

Different teams have different needs, and different needs require different solutions. There's truly no magic, one-size-fits-all platform that can solve all your problems.

Think about a Machine Learning team; they often work differently from other teams in your organization because they need different tools and often even a different compute and storage layer. If you need to build this team a platform, it won't be the standard workload team platform that you can simply copy and paste for them. Building a good platform means that you’re meeting your users in the middle and address their needs. While this probably results in maintaining separate platforms for different target audiences quickly, it's not a bad thing. It’s a bad thing if they all depend on the same Pandora's box and you all of the sudden have a one-size-fits-all monolith platform running.

Platforms don't necessarily need to be large and complicated or packed with customized APIs; they can take various shapes and, at times, even may consist of just a few cloud resources that provide the right abstraction for a team.

Effective platform teams offer other teams the right abstraction, and this shouldn’t be a single standardized abstraction. These off-the-shelf solutions provided by a platform team should come in different levels of abstraction and can be represented using the concept of a wave. There are higher levels of abstraction that aim to offer extensive standardized solutions, and lower levels of abstraction that focus on providing a simple set of instructions, or building blocks — to help reduce the time it takes to deliver value for a team.

The goal should be to offer a range of abstractions without overloading the choices. Talk to the workload teams, understand their preferences, and offer them the right abstraction.

Platforms are Not Invented Here

When considering to add a platform layer and a team to build it, do not hire a bunch of engineers that like to throw out everything that is already available in the market and build their own thing. The level of “Not Invented Here” syndrome in platform teams tends to be fairly high. A buy-over-build mentality is often the better choice for your organization. Just a few of the problems with home-grown solutions are:

• Requiring engineering capacity on something that is not the core business of the company.

• Needing maintenance as the underlying platform (for example a public cloud) is updated.

• Increasing the dependency of the rest of the organization on the team that is responsible for the custom tool.

• Making onboarding of new engineers who are familiar with industry standard tooling more difficult.

• Lack of community of (open source) developers to witness and fix security issues and bugs.

Instead, look for the best (open source) industry tooling available and contribute to it.

Conclusion

Platforms and platform teams can give your organization a useful abstraction so that your other teams can focus on their core expertise. But don’t build a platform for the sake of it. Make sure it adds value in your organization and set it up in such a way that you are not limiting the engineering freedom of other developers. Consider topics like the communication overhead, providing the right level of abstraction, and custom tooling before deciding that a platform team should be brought to life.