7 ms·

> and now hes blogged multiple times about platform teams - which - having been on one - don't work. I’d love to hear more about your experience with a platfor

> and now hes blogged multiple times about platform teams - which - having been on one - don't work. I’d love to hear more about your experience with a platform team and why you say they don’t work.

throwaway85858 3y ago
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.
- jitix 3y ago
  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.
AJRF 3y ago
- 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.
- lightbendover 3y ago
  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.
- mkarazin 3y ago
  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.
  - AJRF 3y ago
    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
- digging 3y ago
  > 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.
ashiban 3y ago
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-platform-engineering-organizations/ https://klo.dev/evolution-of-cloud-infrastructure-and-platfo...

throwaway85858 3y ago

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.

jitix 3y ago
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.

AJRF 3y ago

- 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.

lightbendover 3y ago
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.
mkarazin 3y ago
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.
- AJRF 3y ago
  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
digging 3y ago
> 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.

ashiban 3y ago

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-platform-engineering-organizations/ https://klo.dev/evolution-of-cloud-infrastructure-and-platfo...