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.

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.

Somewhat true. Platform teams have to be engineering & product led. I run a platform team and we work very closely with our customers to understand what problems they are facing and identify platform level solutions for those problems. But we are still hampered by the team not using the platform for their everyday work, reducing the empathy they have towards its papercuts. However, being purely product focused can lead you astray of your users. Our PMs invent capabilities that no one really asked for ignoring the rather large backlog of capabilities that they already need. That's also bad.

The problem with every platform team is that, impact is hard to nail down. Does X using your platform Y to generate revenue mean your platform Y has indirect impact same as X? Most companies don't think so and end up destaffing their platform teams. Until, the destaffing ends up in much more inefficiency because everyone is inventing their own crooked wheel, spending time on the same capabilities and detracting from product development.

> 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.

>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.

[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

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.

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.

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)

> 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.

> It's precisely because of this framing and mentality that platform teams don't actually serve people

I agree. When I was on the platform team (despite it not being called that at the time) our thinking was that feature developers were our customers. And our production was the tools they used. This meant not necessarily aligning production being only what was in production for customers of the company, but also in any service we provided to developers. This mentality had to be instilled into the team, and we had to remind people of this frequently, but it worked well.

> 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.

As a platform team member:

"almost never a product manager handing you roadmap"

Oh well wake me up from my dream vacation.

I'd rather engineers invent practical work than product make broken promises for things they don't understand.

It mentions toil and postmortems, which are pretty relevant to the teams you work with.

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.

> It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident.

What were the charts that convinced them? Just high load % on your databases?

> metrics gets everyone on the same page, because numbers and charts are easy to understand.

Those are just not to convince a manager though, it gives numbers to set KPIs, or at least some benchmark to evaluate the improvements, and at the end of the day solid reasons to justify promoting the team.

From both sides of the fence, fixing problems that only the engineers on the ground can properly value leads to everyone being miserable in the long run.

>To my mind the only purpose companies hire engineers is to support business.

Lots of hires, especially in places big enough to have dedicated teams for platform work, are for empire building, rather than to support business needs. In these situations, companies hire engineers because a higher-level manager needs to increase their headcount, in order to pad out their CV for their next move.

[0] https://www.investopedia.com/terms/e/empirebuilding.asp

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.

I thought this was going to be an article about slacking off with style

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

Agreed. A better framing would be "defining work".

It was clearly a "tongue-in-cheek" framing. Got me interested at least!

In their defence, requirements engineering sounds somehow reactive to me, while "this thing" is kind of proactive, for what it's worth.

I was thinking the same thing. The word that I would be more inclined to use is used multiple times throughout the article. Discovery.

> "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.

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.

i thought the whole article was satire… till i realised it wasnt

yeah I thought the post was going to be satirical

“Deal with the alligator closest to the boat”

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.

> 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.

`maximum-scale=1` on the meta viewport tag.

At least you are getting a lot of fun for it! I have always wanted to join the platform team in my org...

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.