Platform teams rarely get a product roadmap or revenue metric that says what to build next. Sujith Jay Nair frames a staff engineer’s role as “inventing work”: reading signals, assembling evidence, and choosing which opportunity deserves attention.
The signals come from four directions:
- Systems: postmortems, cloud and vendor costs, and recurring team toil
- Users: observed workflows, concrete pains, workarounds, overloaded use cases, and joint prototypes
- The organization: OKRs, repeated leadership concerns, and the long tail left behind by migrations
- The industry: documenting the current system, comparing adjacent designs, and importing lessons after the market has tested them
The distinctions matter:
- Crashes and OKRs arrive with an argument, but they are lagging indicators.
- Manager repetition carries internal standing, not necessarily evidence.
- User requests identify pain but should not dictate the solution.
- Overloaded use cases are unusually strong because users have already built working prototypes.
- Writing down an existing architecture can reveal decisions whose original reasons have expired.
The staff-level skill is not producing a longer backlog. Signals are abundant; the hard part is explaining why one deserves investment over the other ten, instead of letting the loudest outage or highest-paid opinion win.