This article is a good demonstration of what is deeply wrong with today’s corporate IT. And why any big enough company will sooner or later rotten. And why work at such a company these days feel so meaningless and mundane.
For example
> Thankfully, the signals that help us to invent work are already out there, and they arrive from four directions - from the systems, from the users, from your organization, and from the industry. What follows is a guide to reading each of them.
In a good “ideal” org the only source of requirements should be users, aka customers, aka real people, user facing products, teams etc.
There must be no room for speculations and “engineering” (aka over engineering), nor performance review driven development.
I would personally fire anyone “inventing” work. Even if it’s myself.
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.
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.
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.
aristofun · · focus · HN ↗
For example
> Thankfully, the signals that help us to invent work are already out there, and they arrive from four directions - from the systems, from the users, from your organization, and from the industry. What follows is a guide to reading each of them.
In a good “ideal” org the only source of requirements should be users, aka customers, aka real people, user facing products, teams etc.
There must be no room for speculations and “engineering” (aka over engineering), nor performance review driven development.
I would personally fire anyone “inventing” work. Even if it’s myself.
aprilthird2021 · · focus · HN ↗
mahboi · · focus · HN ↗
Gareth321 · · focus · HN ↗
boxed · · focus · HN ↗
It IS hard to try to explain an alien concept to someone when you yourself in fact understand it.
mahboi · · focus · HN ↗
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.
aprilthird2021 · · focus · HN ↗
boxed · · focus · HN ↗
mathisfun123 · · focus · HN ↗
because hn (the culture) rewards (with fake points) being contrarian.
oblio · · focus · HN ↗
crakhamster01 · · focus · HN ↗
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.
aristofun · · focus · HN ↗
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.
DanielHB · · focus · HN ↗
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.