A Staff Engineer's Guide to Inventing Work
A guide for platform staff engineers on how to systematically discover and prioritize internal engineering work using signals from systems, users, organizations, and the industry.
summary is enough The piece offers a useful categorization of engineering signals, but the core concepts are standard discovery practices wrapped in provocative terminology.
summary
Platform engineering teams lack traditional product managers and revenue lines, forcing engineers to proactively discover what to build next. The piece categorizes eleven signals across systems, users, the organization, and industry trends to help staff engineers identify valuable work. These signals range from lagging indicators like postmortems to leading indicators derived from external industry shifts. Using this framework helps engineers navigate an empty backlog by choosing signals with strong reasoning rather than chasing the loudest complaints.
key points
- Platform teams are engineering-led, meaning engineers must proactively discover and define their own roadmaps rather than relying on product managers.
- Signals can be drawn from four distinct directions: systems, users, the organization, and the industry.
- Overloaded use-cases serve as an ideal leading signal because users have already prototyped a solution in production for a problem the platform wasn't designed to solve.
who should read it
Platform engineers, staff engineers, and engineering managers working on internal infrastructure teams.
discussion skeptical
consensus
Most discussion objects to the phrase inventing work as promoting make-work, preferring terms like requirements engineering or discovery.
pushback
A minority argues that framing platform teams as detached from business metrics leads to dysfunctional, inward-looking engineering silos.
> 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 …
It challenges the premise that platform teams should be engineering-led rather than product-led, arguing that ignoring user retention creates dysfunctional internal silos.
Generated by an LLM from the article and thread. Check the sources before relying on it.