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.

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.

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.

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

I'm the PM side of this debate with my TL. I've tried meeting him on every level of understanding. Graphs, story telling, Jira issues, business cases, ITIL, OLAs and SLAs, customer interviews, user interviews, you name it. He strongly resists having to justify the things he wants to work on. His justifications are usually some combination of "it's too complicated to explain," and "this code is a mess." Problem is, I need to account for their hours. I need to explain why we're spending money on that thing - to people who are even less likely understand what my TL is saying.

I say this not to diminish your frustration but to appreciate that you tried to meet him at his level, and provide some context for what the other side can feel like.

> It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident.

What were the charts that convinced them? Just high load % on your databases?

> metrics gets everyone on the same page, because numbers and charts are easy to understand.

Those are just not to convince a manager though, it gives numbers to set KPIs, or at least some benchmark to evaluate the improvements, and at the end of the day solid reasons to justify promoting the team.

From both sides of the fence, fixing problems that only the engineers on the ground can properly value leads to everyone being miserable in the long run.

>To my mind the only purpose companies hire engineers is to support business.

Lots of hires, especially in places big enough to have dedicated teams for platform work, are for empire building, rather than to support business needs. In these situations, companies hire engineers because a higher-level manager needs to increase their headcount, in order to pad out their CV for their next move.

[0] https://www.investopedia.com/terms/e/empirebuilding.asp

I think you're operating on a different definition of "work".

The OP is discussing tasks to do, you sound like you are discussing things that need to be done. The OP isn't saying there aren't things to be done, they are saying that no one is going to tell them what needs to be done, so they must discover and formalize it.

"Inventing Work" is a bit tongue-in-cheek.

I was thinking the same thing. The word that I would be more inclined to use is used multiple times throughout the article. Discovery.

“Deal with the alligator closest to the boat”