How Platform Engineers Invent Their Own Work — Signals From Systems, Users, the Org and Industry

A platform team has no product manager handing it a roadmap. There is no revenue line to follow, no market to lose. Work does not exist unless an engineer invents it. That is the central idea of “A Staff Engineer’s Guide to Inventing Work,” a post making the case that signals for what to build next already exist.

The piece argues that those signals arrive from four directions: the systems themselves, the users of the system, the organization, and the wider industry. The writer, who signs off as a staff engineer, wants to make that invention easier by naming the sources of those signals.

Signals the System Emits

Crashes are the most immediate signal the writer calls out. Postmortems, when done right, point to what to fix or what to replace. Sometimes they point to something new to build too, especially if you watch how users adapted during a long-running outage. The writer warns against a bias toward the loudest and most recent failures, calling crash-led discovery a “maximally lagging indicator.”

Cost is another obvious signal. The cloud bill replaces a revenue north star. The writer goes beyond database optimization and traffic cuts, asking readers to check their team’s vendor contracts and cloud bill line-items, or ask someone with access to the cost centers. The core lesson: buy-versus-build is not a one-time decision. Scope, team membership, technology, and markets all shift, and revisiting that choice is allowed.

Toil is the third signal. Every team has work that repeats without end, and it is almost never prioritized. The writer admits this is a point many readers already know, but still worth noting. The trap: fixing your team’s toil improves unit economics, while fixing your users’ toil improves their experience. The two are not the same problem.

Signals the Users Emit

User interviews are a trap, the writer argues. Asking people what they want often gets you faster horses, not a vision of the future. But that is no excuse to stop talking to users. Continuous discovery means having an ongoing conversation:

1. Talk to N users per week/month/quarter.
2. Walk them through their most recent task involving the platform.
3. Ask for their top three pains.
4. Ask what solving those pains would mean to them.
5. Ask who else has the same problem.
6. Interrogate their hacks — almost every real problem already has one.
7. Push back on their suggested solutions, and see if they fit your current design.
8. Document the pains, indexed by how often they come up.

Solution space design is a separate forum, the writer insists. The interview stays committed to understanding the problem.

Overloaded use-cases are the writer’s favorite heuristic. Some platforms get pressed into service for tasks they were never designed for. The writer asks readers to understand why users choose the platform over alternatives, even when the platform was never meant for the job. Those use-cases act as prototypes built by the users themselves. The litmus test: who else among your users has the same problem?

Partner-to-prototype is the deliberate version of the same idea. Instead of discovering overload after the fact, the team and the users work together to build a prototype on the platform. A prototype is not a promise that the feature becomes official. It is a joint exploration. The litmus test remains the same: who else among your users has the same problem?

Signals the Org Emits

OKRs are listed here for completeness. If your team has set one, or had one handed down, you have already invented that item of work. The writer moves on.

The Manager-Repetition Heuristic is simpler. If you hear your manager, or their manager, or anyone further up the chain, talk about something twice in a week, there is likely an unaddressed concern behind it. The writer recommends taking notes in 1:1s, or reading the LLM-generated ones. This is the weakest of the heuristics, in the writer’s opinion, because the higher up the hierarchy, the farther from the actual work.

A Comparison of the Signals

What This Means for Platform Teams

The post’s central argument is that platform teams need to be proactive about finding work. Without a product manager handing them a roadmap, they have to look for signals in the systems, the users, the organization, and the industry. The writer offers concrete methods for doing that, from crash postmortems to user interviews to OKRs.

The strongest signals come from the users, the writer suggests. Overloaded use-cases and partner-to-prototyping both treat user behavior as a prototype of what the platform could become. The litmus test — who else has the same problem — turns individual complaints into collective evidence.

The weakest signal is the manager-repetition heuristic. The writer’s own judgment is explicit: the higher up the hierarchy, the farther from the actual work. That is why the writer recommends taking notes in 1:1s and reading LLM-generated ones, even if the heuristic itself is weak.

Why This Matters Now

Platform teams are everywhere now. Cloud bills have replaced revenue targets for many of them, and the work of building value for users is not handed down from above. The signals the writer describes are real, and the methods for reading them are practical rather than vague.

The writer does not offer vague platitudes about innovation. They offer concrete steps — postmortem pattern recognition, user interviews, contract reviews, and OKR tracking — that anyone on a platform team can start using tomorrow.

The weakness of the manager-repetition heuristic is worth noting. The writer does not pretend it is strong. That honesty adds weight to the other signals, which the writer clearly favors.

The post offers real, actionable advice for a problem that platform teams face daily: how to find work to do when nobody hands you a roadmap.

Source material: “A Staff Engineer's Guide to Inventing Work,” sujithjay.com.

Hacker News · platform engineering · roadmap · signals · staff engineer