> 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.
Previously I worked at a very large company, my team was mostly isolated form the rest of the tech stack of that company.
Suddenly came a mandate to try to integrate our systems together, the first goal was to use their authorization system (which involved, I kid you not, setting up 3 separate EKS clusters that talked to each other and if the main one goes down, all go down) that the core Platform team of the company was setting up.
Worse even, the plan was to use us as "guinea" pigs for their new systems before rolling out to the rest of the company because our team was smaller and therefor wouldn't be as impacted by problems on their side.
I was vehemently opposed to this, all our other experiences with their stuff was just a huge amount of pain. I remember clearly a meeting we had where I said: "Why would I use your stuff that is not well documented and that I don't understand when I can use open source stuff that is documented and that I can understand". Their only argument was that said they would have internal support for us.
I came up with this concept that I tried to push on to them, that their stuff shouldn't be this monolithic tower of babel monster, but instead should be a buffet where I can pick and choose what to use. Our requirements were very different from their stuff and I didn't want to run into problems because of stuff that had 0 benefit to us.
I ended up leaving that job mostly because of this.
I've had similar fights over the years, on both sides of the discussion.
"If our internal design system is barely half as well documented than Bootstrap then teams will still use Bootstrap. We should take a page from Bootstrap's documentation and include as much detail as we can, on everything."
"As a platform team, your product is this API my app calls. My beta environment should be pointing to your Production, never your beta environment. If that means you need to support better multi-tenant from the same 'app', then you need better multi-tenant. Your outage impacts my testing, which impacts my velocity, which impacts my deadlines. Your backwards incompatible updates need to be planned and scheduled and rolled out like a Production update, every time."
Product mentality is still very useful in platform development. If you can't sell your platform on its documentation and its stability and you must sell your platform on mandate and top-down control, you probably aren't doing as much to help your engineering culture as you think you are.
Yeah, you get what I was trying to get at. It also helps to think about open source (and even paid) alternatives as competition.
Although my main problem was that they were designing these very generic solutions (that were both super complex and very brittle) that can fit every scenario when my _actual_ scenario was very simple. I couldn't get my point across that I didn't want to buy-into their full platform because of risks and complexity on my side, but that I would be open to buy-into small solutions if I saw the need for them in our product.
In any case this company platform team had this mentality that the company should operate like google, trying to build these massive all-in-one solutions that everyone under the company should use. When in practice it would never work because of the sheer amount of people required on their side to pull that kind of initiative off (on top of other considerations like ROI, downtime-risk, etc).
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.
DanielHB · · focus · HN ↗
Suddenly came a mandate to try to integrate our systems together, the first goal was to use their authorization system (which involved, I kid you not, setting up 3 separate EKS clusters that talked to each other and if the main one goes down, all go down) that the core Platform team of the company was setting up.
Worse even, the plan was to use us as "guinea" pigs for their new systems before rolling out to the rest of the company because our team was smaller and therefor wouldn't be as impacted by problems on their side.
I was vehemently opposed to this, all our other experiences with their stuff was just a huge amount of pain. I remember clearly a meeting we had where I said: "Why would I use your stuff that is not well documented and that I don't understand when I can use open source stuff that is documented and that I can understand". Their only argument was that said they would have internal support for us.
I came up with this concept that I tried to push on to them, that their stuff shouldn't be this monolithic tower of babel monster, but instead should be a buffet where I can pick and choose what to use. Our requirements were very different from their stuff and I didn't want to run into problems because of stuff that had 0 benefit to us.
I ended up leaving that job mostly because of this.
WorldMaker · · focus · HN ↗
"If our internal design system is barely half as well documented than Bootstrap then teams will still use Bootstrap. We should take a page from Bootstrap's documentation and include as much detail as we can, on everything."
"As a platform team, your product is this API my app calls. My beta environment should be pointing to your Production, never your beta environment. If that means you need to support better multi-tenant from the same 'app', then you need better multi-tenant. Your outage impacts my testing, which impacts my velocity, which impacts my deadlines. Your backwards incompatible updates need to be planned and scheduled and rolled out like a Production update, every time."
Product mentality is still very useful in platform development. If you can't sell your platform on its documentation and its stability and you must sell your platform on mandate and top-down control, you probably aren't doing as much to help your engineering culture as you think you are.
DanielHB · · focus · HN ↗
Although my main problem was that they were designing these very generic solutions (that were both super complex and very brittle) that can fit every scenario when my _actual_ scenario was very simple. I couldn't get my point across that I didn't want to buy-into their full platform because of risks and complexity on my side, but that I would be open to buy-into small solutions if I saw the need for them in our product.
In any case this company platform team had this mentality that the company should operate like google, trying to build these massive all-in-one solutions that everyone under the company should use. When in practice it would never work because of the sheer amount of people required on their side to pull that kind of initiative off (on top of other considerations like ROI, downtime-risk, etc).