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.
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 nobody else is even talking about it:
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.
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
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.
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.
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.
...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...
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.
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.
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.