Rendered at 10:59:21 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dabedee 17 hours ago [-]
> Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.
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.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
DanielHB 2 hours ago [-]
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.
aleqs 14 hours ago [-]
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.
majormajor 9 hours ago [-]
I don't think they're making any claims about non-platform teams never having similar work-invention problems.
They're just saying a good platform team engineer cares about their users.
Which is fairly at-odds in spirit with the quoted idea of "there's no market to lose."
The original article does say "talk to your users" but it also de-emphasizes this by having it among an apparent laundry list of other signals: crashes, costs
Focus on cost without talking to your users - aka the people who care about the spend? You might spend a lot of time reducing a number that isn't very important right now. Focus on crashes but don't talk to your users? You might address some things with easy workarounds ("i hit retry") while ignoring much more painful toil. This is captured in the details for those sections, but not in the headlines.
There's also some interesting stuff in there in some of the bullets, like overloaded use-cases and partner-to-prototype, but again, that's just more specifics on how to talk to your users.
I think the article would be a lot more helpful to a lot more people if it was a "Guide to Talking to Your Users" and then framed each of those specifically as: user discovery, and how to talk about the given part.
carlmr 5 hours ago [-]
>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.
> 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.
Rapzid 15 hours ago [-]
I've led a number of platform teams over the past decade and we've always treated it like a product with internal and external customers.
alper 2 hours ago [-]
> Being product-led means caring about your users
Show me a platform team with a full product setup and I'll show you a platform team with over capacity.
Not to mention the average level of PMs will take a team like this down if you can even find one who can understand the type of work that the team is doing.
sharts 16 hours ago [-]
Maybe at large orgs. I’ve never found a platform/engineering led teams to engage in work that didn’t amplify the work of other teams.
hibikir 10 hours ago [-]
I have seen it, over and over again, in relatively small orgs (under 500 devs) where the wrong kind of people are handed the job of platform lead. Project after project people don't want to use. The platform jobs in those places were handled by technical skill, but it was attached to disinterest of how others work. So even when they were sent in the general direction of a useful problem to solve, things rarely pan out, because they don't like to talk to their users. Therefore they write the tools they would want to use and are interesting to build instead.
Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.
mahboi 8 hours ago [-]
I worked at a big company where the actual platform teams were serving the internal users ok, but then there was some middle layer of org-specific platforms that strangled entire projects. Eg some kind of custom database someone invented.
My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.
leokennis 3 hours ago [-]
> The fix for having no market is to act like the teams you serve could leave.
My nomination for this months "clarity of thought and ability to express it eloquently" medal.
hintymad 12 hours ago [-]
You'd be surprised how VPs love to insert PMs. A famous game platform company, for instance, had two PMs for their storage team, one PM for their data team, one PM for the compute team, one PM for their dev tools team, if I remember correctly (the numbers could be larger, but won't be smaller)
icedchai 12 hours ago [-]
I was at a small company that had as many PMs as engineers. There was also a "director" in a different department with one report.
hyperpape 16 hours ago [-]
It mentions toil and postmortems, which are pretty relevant to the teams you work with.
dabedee 16 hours ago [-]
Yes. Which is why I don't really understand how any of it needs inventing. I'd rather read about how to find out what those teams actually need; and also how to tell when the answer is to build nothing new at all.
zem 11 hours ago [-]
by "inventing" they mean that no one higher up in the org is going to tell you what your team needs to be working on, you need to do user research and discover the issues for yourself, and then come up with the right set of features that will solve those issues.
viccis 4 hours ago [-]
As a platform team member:
"almost never a product manager handing you roadmap"
Oh well wake me up from my dream vacation.
dirtbag__dad 9 hours ago [-]
> The continuous struggle is to find ways to increase the value our platform provides to the users of the system.
IME as a staff+ platform engineer*, it is dead obvious what increases user value. What is truly challenging is building a story around why anything should be worked on at all, when platform sits the furthest from customers.
I previously worked with a seasoned PM from FAANG who had low technical chops but somehow placed themself in the final decision maker seat for platform work.
They relentlessly blocked work that I described repeatedly in details: data quality was hurting, latency was dog shit, etc. But “bad data model? What do our customers care about our data model and pipelines that are confusing to maintain?”
It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident. At that point, we finally had the same understanding of the problem at the highest level and I was granted (lol) approval.
This admittedly took me almost a year to figure out. Others just trusted my judgement. The takeaway for me was really good tho. Even technical people probably don’t know wtf is going on in your domain, and metrics gets everyone on the same page, because numbers and charts are easy to understand.
* Platform is used too broadly so hard to say what the author exactly means by this.
Gareth321 3 hours ago [-]
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.
fsloth 15 hours ago [-]
"that work does not exist unless an engineer invents it."
This is so strange. To my mind the only purpose companies hire engineers is to support business. The staff engineer should not need a project manager to tell what is interesting for business aspects - even though the goals are likely mostly technical.
I do realize this does not hold up always. But to me if you can't provide some reasoning for your work in business metrics you are participating in an academic exercise.
devmor 13 hours ago [-]
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.
juancn 17 hours ago [-]
I use the "what's going to kill us next" philosophy.
Figure out what that is and do something to avoid it.
Wash, rinse, repeat.
r3trohack3r 14 hours ago [-]
“Deal with the alligator closest to the boat”
nmehner 1 days ago [-]
"inventing work" = "requirements engineering"
"Inventing work" is a strange phrase to use imho.
arealaccount 18 hours ago [-]
I thought this was going to be an article about slacking off with style
Insanity 17 hours ago [-]
Well I was thinking more align the lines of pure "promoware". I.e, find something to build that'll get you promoted but is useless beyond that.
giancarlostoro 15 hours ago [-]
Just tell everyone Claude is still working on it, even if you don't use AI.
qrush 18 hours ago [-]
Agreed. A better framing would be "defining work".
theanonymousone 17 hours ago [-]
Or "proactive engineering"
pradn 15 hours ago [-]
It was clearly a "tongue-in-cheek" framing. Got me interested at least!
theanonymousone 17 hours ago [-]
In their defence, requirements engineering sounds somehow reactive to me, while "this thing" is kind of proactive, for what it's worth.
mytydev 24 hours ago [-]
I was thinking the same thing. The word that I would be more inclined to use is used multiple times throughout the article. Discovery.
nmehner 16 hours ago [-]
Agree. Discovery is probably an even better term.
groestl 17 hours ago [-]
I think it's a fundamental difference in philosophy. Does the work exist, and you discover it? Or does it start existing as soon as you think about it? This person seems to subscribe to the latter world view.
gloryjulio 17 hours ago [-]
Requirements engineering still applies to senior engineers. You are given a problem and you need to work out the requirements and the path to completion.
But for staff engineers, they need to to discover the scope themselves. That's where "inventing" coming from. Not saying inventing is a good word here, but requirement alone is not enough for staff level's work
nmehner 16 hours ago [-]
"Requirements Engineering", "Writing Code", "Writing Documentation" are all areas of work that are independent of seniority in my point of view.
I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.
Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.
If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.
gloryjulio 16 hours ago [-]
You are not talking about the expectations in terms of the corporate levels. Staff and senior have clear definitions in tech companies. A staff(l6) is the team lead who is required to find the scope for himself and team. That's in his job description. If he can't do that he would get pipped or fired.
A senior(l5) is the tech lead on the project level. He is not in charge of handling the team's scope. As long as he handled his own projects well, he would usually pass the review cycle. The difference is crucial. At staff and above, the engineer's responsibility is vastly larger than a senior's.
I am not saying a senior can't do a staff's job - that's how he get promoted once he demonstrated that he is operating at a staff level, i.e "inventing" scope for his team. But a senior's scope is much smaller than a staff's.
This applies to almost all US medium to large tech companies
cush 17 hours ago [-]
yeah I thought the post was going to be satirical
tessierashpool 13 hours ago [-]
> "Inventing work" is a strange phrase
The author used an LLM. The first paragraph has two em dashes (turned into hyphens) and a typical overlong list. The second paragraph has an em dash the human author turned into a semicolon, and the third has one he turned into a colon. The fourth paragraph does the colon substitution several times.
The fifth paragraph is so obviously machine-generated I don't understand why people are even discussing this blog post at all:
This is the other cost - invisible to many, sometimes including the ones who handle the toil work. Every team has toil, and it is almost never prioritized. But you already knew this one, so I won’t spend more words to say that toil is an important signal that there is work waiting to be discovered.
If all you want to do is post prompt outputs on your blog, I think a) you should be honest about it and b) you have an obligation to write very interesting prompts.
Might even be more useful to just share those.
aristofun 10 hours ago [-]
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.
DanielHB 1 hours ago [-]
> 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.
aprilthird2021 8 hours ago [-]
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.
crakhamster01 3 hours ago [-]
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.
mahboi 8 hours ago [-]
To answer your question, it's because the article isn't written well
Gareth321 3 hours ago [-]
Which is deeply ironic, given the content.
mathisfun123 6 hours ago [-]
> Why do so many people in this forum not understand the article
because hn (the culture) rewards (with fake points) being contrarian.
oblio 52 minutes ago [-]
Upvoted for being a contrarian to contrarianism.
stephbook 15 hours ago [-]
The article content is both true and framed strangely.
Does the author think "product customers" hand you a tidy list of requirements the stupid programmer automatons just have to translate into code? Obviously not. Customers also don't know what they want, or could want. Famously, they claim to want faster horses.
Then the author goes on to list "crash led discovery", as if this was so different from prioritizing bugs in prod. Or, If you have no idea, just improving efficiency. Or talking to customers, err, users.
All of this is true and none of this is any different from any of the other software, just translated into other lingo.
estetlinus 5 hours ago [-]
When I worked as a props assistant (movie set), I required approval for my overtime. I remember my boss once saying ”Linus, it feels like your inventing your own overtime” (he was not wrong). Is that what’s happening in platform teams worldwide?
At my last company it took ~4 weeks to get a storage container because they were so overwhelmed with work and blocking precisely the whole company.
sigbottle 16 hours ago [-]
I wonder how this applies to personal projects. I find it hard to motivate myself to just "study a textbook". I do do so, but it almost always feels useless compared to actually doing something. It doesn't have to be grand, but it needs to be something I can at least "trick" myself into believing it's useful.
Well, right now, I'm pretty happy and have a personal project that I'm very eager to have done and polished and see the result of. Hopefully life keeps throwing more of them at me. It's been a constant issue for me though.
MustangMatt46 11 hours ago [-]
Why won't this site allow me to zoom on mobile? On desktop it works fine.
syngrog66 8 hours ago [-]
in broadstrokes its about doing more work biased to longterm and tech debt paydown rather than nearterm and tech debt accum in the race to market
aaroninsf 17 hours ago [-]
I feel seen, but agree, I would have used "identifying and prioritizing work"...
...but I will admit, it does sometimes feel inventive, and when I describe what I do, it does feel... inventive... in some sense. Particularly "no one in the org asked me to..."... instead it's almost always, identifying and getting ahead of needs, or, responding to overlooked friction/problems, etc...
ferguess_k 16 hours ago [-]
At least you are getting a lot of fun for it! I have always wanted to join the platform team in my org...
skrtskrt 15 hours ago [-]
> no revenue line to follow, and no market to lose
Two paragraphs later, the topic is:
> Cost
I mean this is just incredibly lazy thinking and writing.
There's always a cost line to follow, just because there's "not a revenue line" means absolutely nothing it just sounds pithy.
And if you cut your cost hard enough, you will put platform stability in danger, or hamstring your engineering org's ability to test and iterate, which will make you lose your market.
Again, incredibly lazy thinking and writing.
froh 5 hours ago [-]
missing the point are we
when systems engineers through intelligent restructuring of low level data structures save 1 TB of ram for their company without loss of productivity that is unrelated to revenue and market but still improving the bottom line.
if FB puts strings shorter than 64 bytes not on the heap but into the string control data via a union, that's in the same category of saving costs without adding a single new feature.
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.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
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.
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.
They're just saying a good platform team engineer cares about their users.
Which is fairly at-odds in spirit with the quoted idea of "there's no market to lose."
The original article does say "talk to your users" but it also de-emphasizes this by having it among an apparent laundry list of other signals: crashes, costs
Focus on cost without talking to your users - aka the people who care about the spend? You might spend a lot of time reducing a number that isn't very important right now. Focus on crashes but don't talk to your users? You might address some things with easy workarounds ("i hit retry") while ignoring much more painful toil. This is captured in the details for those sections, but not in the headlines.
There's also some interesting stuff in there in some of the bullets, like overloaded use-cases and partner-to-prototype, but again, that's just more specifics on how to talk to your users.
I think the article would be a lot more helpful to a lot more people if it was a "Guide to Talking to Your Users" and then framed each of those specifically as: user discovery, and how to talk about the given part.
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...
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.
Show me a platform team with a full product setup and I'll show you a platform team with over capacity.
Not to mention the average level of PMs will take a team like this down if you can even find one who can understand the type of work that the team is doing.
Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.
My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.
My nomination for this months "clarity of thought and ability to express it eloquently" medal.
"almost never a product manager handing you roadmap"
Oh well wake me up from my dream vacation.
IME as a staff+ platform engineer*, it is dead obvious what increases user value. What is truly challenging is building a story around why anything should be worked on at all, when platform sits the furthest from customers.
I previously worked with a seasoned PM from FAANG who had low technical chops but somehow placed themself in the final decision maker seat for platform work.
They relentlessly blocked work that I described repeatedly in details: data quality was hurting, latency was dog shit, etc. But “bad data model? What do our customers care about our data model and pipelines that are confusing to maintain?”
It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident. At that point, we finally had the same understanding of the problem at the highest level and I was granted (lol) approval.
This admittedly took me almost a year to figure out. Others just trusted my judgement. The takeaway for me was really good tho. Even technical people probably don’t know wtf is going on in your domain, and metrics gets everyone on the same page, because numbers and charts are easy to understand.
* Platform is used too broadly so hard to say what the author exactly means by this.
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.
This is so strange. To my mind the only purpose companies hire engineers is to support business. The staff engineer should not need a project manager to tell what is interesting for business aspects - even though the goals are likely mostly technical.
I do realize this does not hold up always. But to me if you can't provide some reasoning for your work in business metrics you are participating in an academic exercise.
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.
Wash, rinse, repeat.
"Inventing work" is a strange phrase to use imho.
But for staff engineers, they need to to discover the scope themselves. That's where "inventing" coming from. Not saying inventing is a good word here, but requirement alone is not enough for staff level's work
I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.
Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.
If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.
A senior(l5) is the tech lead on the project level. He is not in charge of handling the team's scope. As long as he handled his own projects well, he would usually pass the review cycle. The difference is crucial. At staff and above, the engineer's responsibility is vastly larger than a senior's.
I am not saying a senior can't do a staff's job - that's how he get promoted once he demonstrated that he is operating at a staff level, i.e "inventing" scope for his team. But a senior's scope is much smaller than a staff's.
This applies to almost all US medium to large tech companies
The author used an LLM. The first paragraph has two em dashes (turned into hyphens) and a typical overlong list. The second paragraph has an em dash the human author turned into a semicolon, and the third has one he turned into a colon. The fourth paragraph does the colon substitution several times.
The fifth paragraph is so obviously machine-generated I don't understand why people are even discussing this blog post at all:
This is the other cost - invisible to many, sometimes including the ones who handle the toil work. Every team has toil, and it is almost never prioritized. But you already knew this one, so I won’t spend more words to say that toil is an important signal that there is work waiting to be discovered.
If all you want to do is post prompt outputs on your blog, I think a) you should be honest about it and b) you have an obligation to write very interesting prompts.
Might even be more useful to just share those.
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.
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.
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.
because hn (the culture) rewards (with fake points) being contrarian.
Does the author think "product customers" hand you a tidy list of requirements the stupid programmer automatons just have to translate into code? Obviously not. Customers also don't know what they want, or could want. Famously, they claim to want faster horses.
Then the author goes on to list "crash led discovery", as if this was so different from prioritizing bugs in prod. Or, If you have no idea, just improving efficiency. Or talking to customers, err, users.
All of this is true and none of this is any different from any of the other software, just translated into other lingo.
At my last company it took ~4 weeks to get a storage container because they were so overwhelmed with work and blocking precisely the whole company.
Well, right now, I'm pretty happy and have a personal project that I'm very eager to have done and polished and see the result of. Hopefully life keeps throwing more of them at me. It's been a constant issue for me though.
...but I will admit, it does sometimes feel inventive, and when I describe what I do, it does feel... inventive... in some sense. Particularly "no one in the org asked me to..."... instead it's almost always, identifying and getting ahead of needs, or, responding to overlooked friction/problems, etc...
Two paragraphs later, the topic is:
> Cost
I mean this is just incredibly lazy thinking and writing. There's always a cost line to follow, just because there's "not a revenue line" means absolutely nothing it just sounds pithy.
And if you cut your cost hard enough, you will put platform stability in danger, or hamstring your engineering org's ability to test and iterate, which will make you lose your market.
Again, incredibly lazy thinking and writing.
when systems engineers through intelligent restructuring of low level data structures save 1 TB of ram for their company without loss of productivity that is unrelated to revenue and market but still improving the bottom line.
if FB puts strings shorter than 64 bytes not on the heap but into the string control data via a union, that's in the same category of saving costs without adding a single new feature.