Once and For All

And... we’re back to our exciting series on how to structure engineering organizations! Our ultimate goal? To finally answer your kid’s FAQ: “Mommy, daddy, where do platform teams come from?”

In episodes I and II we covered two fundamentalist approaches of how we could structure an engineering organization: horizontal (by function) and vertical (by product). As it turned out, neither was perfect. And then, I left you hanging. Again. Sorry.

So what is the one true answer then? TELL US.

No promises, but we’ll wrap this trilogy up looking at a third option, and that will be it! Unless I sell out, and license this trilogy to Disney, in which case you can expect a wild (but undoubtedly equally entertaining) set of spin-offs and prequels.

Summarizing my summary of summaries:

• Horizontal organizations are great at producing consistent, coherent products, with a lot of reuse of knowledge and software/hardware components. However, this comes at the cost of speed due to coordination and communication overhead. We looked at Apple as an example of a company organized this way.
• Vertical organizations are great at moving fast and scaling up. This comes at the cost of replication of work and a less coherent suite of products. We looked at Amazon as an example of a company organized this way.

So what if we want it all, what if we want to have our cake and eat it too?

Yeah, that’s not going to happen. But to get closer, we do have options.

We can go hybrid.

I know, who saw that one coming 🤯

Let’s use our vertical setup as a starting point, but then tweak it a little bit. Vertical teams go fast. Speed is good, most of the time. What were the issues again?

Replication of work... Less coherence in product and UX...

🤔

What if... and I’m just spitballing here... we look across our organization and apply some elemental engineering practices. Let’s do some refactoring. Extract method!

Perhaps all teams need a build pipeline, and don’t need to reinvent their own particular brand of wheel. Extract!

Perhaps all teams seem to rely on a widget called a “button,” and if we’re building one of them fancy things, we may as well make that button look the same everywhere to avoid customers wondering what this particular monstrosity is that they’re looking at. Extract!

Perhaps, having a debate on the particular state management library to use (or more controversially: deciding on tabs versus spaces), is more of a distraction than a helpful debate to have when you’re trying to deliver a feature. Extract!

If we pull these responsibilities out of the vertical teams, naturally they’ll have more time to ship stuff. Although they’ll have less fun discussing tabs versus spaces. Trade-offs.

To do this, we’ll set up some more horizontally operating teams — we’ll call them platform teams — and have them solve these common problems once, and for all.

Their priority would not be speed, but scalability and reusability.

As an example, looping this all the way back to where we started two weeks ago, we could kick off a QA (Quality Assurance) Platform Team.

The QA Platform team would be in charge of the QA test pipelines as well as QA processes across the company. They’d make sure, once and for all, that all the tests that are written by the feature teams run in a reliable way, ensuring those pipelines can scale.

This way, not every team has to reinvent this particular wheel every time. Wouldn’t that be nice? The QA Platform Team’s product is the QA Platform, and its customers are other (feature or platform) teams.

One of the QA Platform’s products is essentially: “Insert your tests here, we’ll make sure they run and will get you the results back in a timely fashion.”

Each product team will still be responsible for maintaining its own desired level of quality, but should be much more efficient at it with the tools and processes provided by the QA platform team, once and for all.

As obvious of a win as this may seem at a first glance, we should be clear that we’re reintroducing coordination cost once again. However, that added cost should be offset with the value that the platform teams provide to the teams.

Beside the coordination cost, we have to pull out people from our product teams to resource our platform teams. Sadly, nothing comes for free. There’s opportunity cost to everything. There’s no silver bullet (beside Silver Bullet).

What are some of the common platform team traps? What could possibly go wrong in this amazing new hybrid setup?

There are two risks that are top of mind:

1. A disconnect between platform teams and its customers
2. Becoming a blocking bottleneck

The customer disconnect can happen naturally. Platform teams tend to have experts in them. And experts are more likely than some to think they know it all.

“I know what the peoples need! I shall create it for them, and they shalls enjoy it. You’re welcome, peoples!”

Yep, that’s how experts talk. If you don’t talk like that, you’re not an expert. Just sayin’.

In a previous company I worked at, platform teams worked for years on internal products that... as it turned out, nobody wanted. Ultimately, the whole platform organization was shut down. Focus on the customer should apply across the board, also for platform teams. And a platform team’s customers are other teams. “Build it and they will come” is a phrase originating from a fantasy movie called Field of Dreams. Unless really understanding customer needs, the risk is high that when you build it, nobody will come.

Becoming a blocking bottleneck is the second trap. A former colleague of mine (who worked at Amazon for many years) told me that “2 > 0” is Amazon company policy. What does “2 > 0” mean? It’s better to have two implementations of something than none. I love that, and it’s one of the biggest traps of platform teams.

If there’s a problem to be solved that has something in the critical path involving a platform team, you run a good risk that the problem will never be solved.

Why?

Product team: “To implement this feature, we will need widget A. Widget A is something other products will likely also need down the line.”

Platform team: “Yep! This is on us, we’ll take this.”

Product team: “When? We’ll need it next quarter.”

Platform: “I don’t know, it not a priority now, we’ll get to it at some point. Patience please.”

The result: it doesn’t happen at all, the product team is blocked, and decides to move on to other things.

The way to avoid this problem is either to avoid putting platform teams in the critical path and just have the feature team whip up widget A (or an initial iteration of it) first, and later hand it off to the platform team. Or, to properly coordinate and negotiate priorities well in advance. Making sure that platform teams are appropriately focused on customers really helps here.

And there you have it, the hybrid organizational structure many engineering organizations employ: a mix of product teams and platform teams. It’s not perfect, it’s not without its traps, but it strikes a reasonable balance between speed, scalability and consistency.

If you’re interested in this topic and would like to learn more, the standard work on this topic is Team Topologies. There they identify four distinct types of teams, not just two.

Maybe if Disney subsidizes another trilogy, I’ll write more about the missing two.