Untitled

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.

Somewhat true. Platform teams have to be engineering & product led. I run a platform team and we work very closely with our customers to understand what problems they are facing and identify platform level solutions for those problems. But we are still hampered by the team not using the platform for their everyday work, reducing the empathy they have towards its papercuts. However, being purely product focused can lead you astray of your users. Our PMs invent capabilities that no one really asked for ignoring the rather large backlog of capabilities that they already need. That's also bad. The problem with every platform team is that, impact is hard to nail down. Does X using your platform Y to generate revenue mean your platform Y has indirect impact same as X? Most companies don't think so and end up destaffing their platform teams. Until, the destaffing ends up in much more inefficiency because everyone is inventing their own crooked wheel, spending time on the same capabilities and detracting from product development.

You're assuming product people don't 'invent' work, which is faaaar from true. The more technical the area, the more nonsense 'product' generates, that engineering then has to either redo, clean up or fight. The 'product' people on 'product-led' teams also generally own the internal comms and marketing (internal) side of things, which often has the effect of silencing engineering (and many other negative side effects). (Not always but often imo) Engineers should understand their customers and their product (whether internal or external), should understand their metrics, and should be able to make intelligent, informed decisions. Sticking a non-technical 'product' (aka marketing) person into the mix is generally net-negative imo.

>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. Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn. Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside. If that wasn't possible we built what we needed ourselves. If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart. And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm. If you don't have a project-0 to test those assumptions against, you don't need to start that platform. [0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

> Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. And where do product people get ideas for new features? If you're Microsoft you look at what successful competitors are doing. If you're anyone else you look at customer pain points, exactly as described in the article.