Why do so many people in this forum not understand the article. He is not literally inventing work. He is finding out what work needs to be done by reading the signals. Users and customers don't often know or care about the requirements of your system (are users and customers going to tell Facebook what it needs technically to handle a surge in users for its new AI that gives everyone on Earth a private VM to mess around in?). That's why you hire engineers. To figure out what needs to be done to keep serving the product, which is what users actually care about.

To answer your question, it's because the article isn't written well

Which is deeply ironic, given the content.

I got it instantly. Maybe because I also am one of those people who go around finding problems in the product that are seemingly invisible to the product manager, team lead, CEO, etc.

It IS hard to try to explain an alien concept to someone when you yourself in fact understand it.

Well at least you don't call it "inventing work," right? I'm on a platform team too, would cause a lot of wtfs if someone said that in a meeting.

I also don't think it's excusable to say it's hard for others to understand. The good SWEs I've worked with knew how to explain what they do to partner teams.

It's clearly tongue in cheek to address the misconception that this is what engineers do

I've called it "do the right thing, wait to get fired". That's not my invention though :P

> Why do so many people in this forum not understand the article

because hn (the culture) rewards (with fake points) being contrarian.

Upvoted for being a contrarian to contrarianism.

I think a lot of the commenters here may already have a negative perception of Platform teams. That they are a byproduct of big tech org inflation, a sign that the companies aren't serving their users, etc. The initial hook of "inventing work" then indulges these pre-conceived notions, and you end up with rants on how engineers have lost the plot.

Personally, I found the article well written. Platform teams ultimately want the overall company to succeed. Their leverage - and mandate - is through helping the engineering org ship safer, faster, and more efficiently. The signal recommendations mentioned by the author are spot on from my experience, and I appreciated reading their perspective.

> Why do so many people in this forum not understand the article

I understand it deeper than you think.even maybe deeper then author think he does.

The only singals that matter i already mentioned. Everything else must submit to this ultimate goal. If that’s the case there is no reason to invent anything even metaphorically speaking. And platform requirements arise naturally to exact extent the user problem justifies, not more not less etc.

This is probably a fundamental philosophical division between “engineers” who love to engineer for the sake of engineering, who are arrogant enough to treat their trade as an art form even.

And between mere mortals, regular engineers, who are hungry for solving real world problems as efficiently and quickly as possible.

Instead of figuring out the mess and navigating the peculiarities of another “platform team” in a big org.

> In a good “ideal” org the only source of requirements should be users, aka customers, aka real people, user facing products, teams etc.

There are many other source of requirements that matter a lot. One heavily underestimated one is employee frustration. A frustrated employee is less productive and is at risk of leaving the org which incurs huge costs.

A few other ones: environmental impact, social impact, security, ethics, data safety/privacy, regulamentory compliance.

You might say that all these eventually end up as a requirement from users, for example "an employee leaving because he is frustrated means it takes longer to deliver features to a customer". But that is a very roundabout way of looking at it.