You describe the toxicity I have experienced working in the product team vs a platform team.

If you don't find it interesting to build products with whatever tool is most adequate (excel some times) maybe you should not work at a company building products. At least you should understand that you are part of the support team not the main guy.

And yes, moving to GitHub from Jenkins is maybe objectively a good choice. But if it stalls product development for 6 months, is that objectively-objectively a smart move? It could of course be, but it requires more situational awareness than "is this tool better".

Platform teams also need to make calls where the experience might be worse for some but collectively better for the company.

This is normally where you see the product engineers start to freak out.

That's the point I was trying to highlight in the "Treating product engineers as customers" sin section – the duality goes both ways. Sometimes the best thing for the company is to make the lives of product engineers better, sometimes it's to make them worse. You do whatever is best for the company, not for the product engineers.

but platform engineers are so far down the chain, it's hard for them to associate their work value to actual customer's benefits.

This is what we are discussing. A company can also choose to organize it some other way.

Yes, I agree. It was more decided to go from Product Team -> [Product Team, Platform Team] and then everyone deep tech wanted to leave the Product Team, so it reversed again later. Guess if it's from the start, you can say indeed you should not work for a company building products. Anything thing is; platforms in themselves don't really sell. The products built with them sell, so what do you work for if you want to just build platforms (want to build game engines, not games as a comparison these days).

> Many technical people find platforms far more interesting than trying to convert an excel sheet to a user viable product.

Perhaps in part because they feel, deep down, that an Excel sheet is superior in terms of user-friendliness, capabilities and ergonomics, to whatever the "user viable product" company is trying to sell? A platform may serve different purposes, so the technical challenges, even if self-inflicted, don't seem pointless.

> Perhaps in part because they feel, deep down, that an Excel sheet is superior

In my experience these folks are the exception rather than the rule. To recognize when, and when not, to use Excel vs. buying/building/subscribing to specialized software, takes a certain kind of real-world experience as a user and/or stakeholder that many engineers surprisingly lack, even long into their career.