- Platform sounds like "everything that doesn't fit into a vertical slice of business" - that is a _hell_ of a lot of work for any team.

- Business hates and underfunds these teams because they are often blamed as being a blocker because of the previous statement. They are a pure cost center too. Career suicide joining them.

- Unless you have a very motivated team lead you will end up doing the work of the most aggressive and loud team leads from other teams. Anyone good at playing politics will dictate your roadmap.

- Given the first statement, how do you hire someone for these teams? If they are responsible for platform evolution, upgrades, CI + CD, making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise. You would need to pay someone a lot to do this right? Well no - because of point 2.

The idea of a platform team is one of those weird things that sounds obvious and clearly needed - until you marry the idea to that of any org that has layers of management + politics and a misunderstanding of the long tail effects of platform work.

An interesting thing that happened at our company when we ended up having a platform team was that the "Can do" attitude of our previously homogenous group of mobile devs stopped over night - "That's a platform role" became a common refrain.

> An interesting thing that happened at our company when we ended up having a platform team was that the "Can do" attitude of our previously homogenous group of mobile devs stopped over night - "That's a platform role" became a common refrain.

This has more or less been the case for my entire tenure at my current company. Sure, I want to do X, but we're crunched for time almost always. And there's another team that probably handles X. So it would be irresponsible/wrong of me to work on X when someone else can handle it faster and "owns" it. Except, who owns it? Whose team do I contact? That, I never know. It's a shifting, amorphous creature that lives around the app development team; I am required to communicate with it but I don't know how. Ultimately I end up with many micro-blockers where I don't know if a given task is something I should be learning myself or passing off to someone else.

The platform team you describe sounds more like DevOps ("upgrades, CI + CD, ....").

The platform teams I've seen at scale are more focused on providing APIs and services for a business domain. Such as, you can have a platform team for KYC/KYB that develops integrations to document verification providers, and then have stream aligned teams that sit on top of that platform and use it in a product to onboard users. Or in payments, a platform team can manage all of the underlying banking integrations, and then a product team can use these APIs to develop a product that lets users pay for things online. I once managed a platform team that managed the internal ledger for a virtual wallet/venmo type company. There weren't many product features there, but they had to deal with scaling our transaction processing capacity, ensuring idempotency of money transfers, and providing an easy to use API for product teams to integrate with. For more academic/research minded software engineers, it's an awesome team to be on.

You stopped just before the bit that made your comment pointless, the very next words;

> making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise

That is the root problem with Martin Fowler and his ilk, always ignoring management, politics and existing reality.

See Project Managers becoming 'scrum masters' rather than neatly disappearing.

Platform teams are similar, they sound plausible, but as you say the reality is pretty miserable. 'Enabling' others to do work eventually looks a lot like doing the work.

Interestingly, I've seen the exact opposite. Platform is the team that they see, and they do a tremendous amount of the total work. I guess maybe that's the difference; the teams you worked on didn't write much useful code.

What I've seen is platform being the "elite" place to work, or at least the one where you can do cool things. Otherwise you're working with "cookie cutters". Most specific content, in our case written for individual customers was not as important! There are many customers and projects, but theoretically only one platform. Projects come and go. However, platform being responsible for most of the code that determines basic functions, puts you at their mercy.

The infrastructure and base code was a huge deal. The other teams were fat... it does cut either way though.

All of those are downsides, yes, but platforms still need to be built for organizations that are at scale so the focus needs to be on how to improve the process of building them, not on how to avoid them.

Only small companies can silo everything into verticals.

I'm really curious about the usual inter-team patterns .. (or even in-team). Politics is a morbid fascination.. cause I hate it but I have to walk around it so.. the more I know.

My 2c's are that platform teams are a silo for expertise on how anything is run at a company and can become a bottleneck for other teams when getting things done. In an ideal scenario the product team can consume resources via an API, but in my experience resources are only assigned via a ticketing system and the associated communication barriers this creates leads to friction.

Having worked at smaller companies (~ 500 people) in different stages (series-A, unicorn and post IPO) I very much like the idea of a lean platform team that defines the interfaces that are used to control interaction between different modules, and with external services.

Yes it creates friction and reduces velocity at ticket level but it prevents misalignment errors in UAT and production. This can be solved somewhat by having dedicated product owners in each module but it's often not feasible for smaller companies and brings in too much non-technical chatter.

For example, if your product acts as a metadata repository as well as a task execution engine it is important that the execution engine modules access the metadata only using streamlined (and maintained) internal APIs and not hit the database or maintain duplicate metadata for different engines. This way you actually improve velocity at milestone/release level because you're free to make changes to the metadata codebase without breaking features in various downstream execution engines.

In my experience, with a well-scoped platform team, the integration phase of a release gets significantly smoother with fewer defects. YMMV based on product type and company size.

I led a large (50 people+) platform org - Organizations struggle with modern backend systems and cloud, and find themselves in a cyclical loop of hiring, reorganization and reprioritization. I just wrote about it here a few days ago: https://klo.dev/evolution-of-cloud-infrastructure-and-platfo...