Platforming

It's always a good idea to know what type of engineering team you're in.

The type of team tells you all sorts of things, like why it is creating things in the first place, who those things are intended to serve and how those things are being created.

In my experience, there are two types of engineering teams that are, by far the most common in the industry.

Knowing what they are and understanding the different mindsets between the two is important to ensure that both you and the other members of the team are aligned.

Welcome to the Mushroom Kingdom

The first type of team is a service team. This team supplies a set of capabilities directly to the business, probably even to the user, and are fully and wholly responsible for those capabilities.

For example, a team that is responsible for maintaining and extending a piece of legacy on-premises software is a service team, but so is a team that owns an internal API that captures metrics and places them in a data lake for others to consume.

Other teams might be reliant on the capability that a service team is exposing, so the service team still exists inside an ecosystem of sorts, but it's unlikely that they are at the centre of a massive spiderweb of dependencies.

Service teams are the bread and butter of any organisation that relies on the engineering of software to make money and serve its users.

Going Underground

The second type of team is a platform team. This team also supplies a set of capabilities to the business, but that's where things get a bit more tricky.

The capabilities offered by a service team have value by themselves. It's an on-premises app or a data collecting service or something.

The capabilities offered by a platform team have no value by themselves. No-one builds a platform and then stops there, pats themselves on the back and falls backwards onto their ridiculously oversized pile of money.

Platforms exists to enable other teams to accomplish things.

Ideally, the existence of a platform makes it easier for those other teams to deliver capabilities, though sometimes that might not be true, and the platform is focused on standardisation or consistency rather than effectiveness of delivery.

Platform teams are often directly at the centre of the spiderweb of dependencies. Many many teams rely on them accomplish their own goals and deliver the capabilities that they are responsible for.

And that sort of responsibility can be daunting.

Treetops Time

Service teams and platform teams must operate with an entirely different mindset.

First of all, a platform team must go into every situation keeping in mind that the resulting software system needs to be supportable without them getting involved.

If something happens to the capability being provided by a team that is using the platform, the platform team can't be the ones who have to investigate, diagnose and then fix the problem. If they did, they would create a massive bottleneck, completely nullifying any of the scaling benefits that platforms can provide.

Not all of the platform needs to be supportable by any random engineer in the company though, just the parts that the service teams are interacting with all the time. The core can still be an arcane conjunction of insanity that only the people in the platform team understand.

Though I wouldn't recommend it.

The second difference in mindset between a service team and a platform team is that the platform team must design for extension.

This might seem more like an architectural requirement than anything else, but architecture starts in the minds of the engineers who build and maintain the system, so if they aren't considering that angle consistently, it's not going to happen.

The desired outcome is that change to the system in question must not only come about as the result of the platform team writing new code. Other teams should be able to write code of their own that slots into the capabilities of the platform at pre-defined points. If that isn't available, the platform team is once again making themselves a bottleneck.

The last difference in mindset that I can think of is always being aware of onboarding.

A service team doesn't really need to think about onboarding all that much. They might get new people in the team from time to time, but that situation can usually be dealt with via solid documentation or, in a pinch, sharing of tribal knowledge. It doesn't even matter if there are rough edges, because the volume of people who need to understand and work around them is low.

Not so with a platform.

You don't have any control over when people want to start using your system, so any path to enable and empower them needs to be clearly designed to help them achieve their goals without making any assumptions about how much they know.

If you're not keeping this in mind on a day-by-day basis, you'll end up with a platform that is hard to adopt, which will ultimately hurt its ability to actually provide the value to the business that it was aimed at providing.

The Showdown With Bowser

You should familiarise yourself with the two main types of engineering teams, regardless of whether you are an Engineer, an Engineering Manager or some other crazy sort of creature (cough Technical Program Manager cough).

The differences between the two are meaningful, and a misunderstanding about the type of team that is necessary or misalignment between members of the team can lead to all sorts of crazy problems.

As a more concrete example, the teams that I am a part of, have been transitioning from service to platform over the last few years.

It's not an easy transition. People take a long time to change how they think about things and how they approach problems, and that's delayed even further if you don't realise that a shift in mindset is necessary.

The good news is that we're trending in the right direction.

Which is to the right if you've ever played a platformer.

Hopefully our princess is not in another castle.