> Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.
It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
I have seen it, over and over again, in relatively small orgs (under 500 devs) where the wrong kind of people are handed the job of platform lead. Project after project people don't want to use. The platform jobs in those places were handled by technical skill, but it was attached to disinterest of how others work. So even when they were sent in the general direction of a useful problem to solve, things rarely pan out, because they don't like to talk to their users. Therefore they write the tools they would want to use and are interesting to build instead.
Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.
i think that speaks more to the politics of “handed the job of platform lead.”
i’m many orgs the leads of any team are often people that are primarily interested in linkedin bullet points and being gently fondled and groomed by upper management.
this happens in product and dev teams as well. consistently.
I worked at a big company where the actual platform teams were serving the internal users ok, but then there was some middle layer of org-specific platforms that strangled entire projects. Eg some kind of custom database someone invented.
My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.
dabedee · · focus · HN ↗
It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
sharts · · focus · HN ↗
hibikir · · focus · HN ↗
Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.
sharts · · focus · HN ↗
i’m many orgs the leads of any team are often people that are primarily interested in linkedin bullet points and being gently fondled and groomed by upper management.
this happens in product and dev teams as well. consistently.
mahboi · · focus · HN ↗
My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.