A Staff Engineer's Manual for "Inventing Work"

Originally authored by Sujith Jay Nair (2026)

In the realm of platform engineering, the traditional product management paradigm is often absent. Unlike feature teams, platform teams are typically engineering-led. You won't find a Product Manager handing you a meticulously curated roadmap, nor will you find a direct revenue stream or a competitive market to chase.

Consequently, work does not simply "appear"—it must be invented. The primary challenge for a Staff Engineer is identifying how to amplify the value the platform delivers to its users.

The Framework of Discovery

To "invent work," one must synthesize signals from four distinct vectors. This can be visualized as follows:

---

1. Signals Emitted by the System

Crash-led Discovery

When postmortems are executed with rigor, crashes become blueprints for improvement. While they rarely suggest entirely new features, they often reveal gaps in the current architecture or highlight how users are struggling to maintain workflows during outages.

The Financial North Star

In the absence of a revenue target, the cloud bill serves as your primary metric. However, optimization isn't just about fixing a slow SQL query or reducing VPC traffic. It requires a deeper dive into the P&L (Profit and Loss) statements and vendor contracts.

The goal is to evaluate the $\text{Cost-Benefit Ratio}$: $\text{Value} = \frac{\text{Utility of In-house Control}}{\text{Cost of Vendor Outsourcing}}$

Key Insight: The "Buy vs. Build" decision is not a static event. It is a living strategy that should be revisited as the market, technology, and team composition evolve.

Internal Toil

Toil is the "invisible tax" paid by engineers. While it is a potent signal for necessary work, there is a critical distinction to maintain:

• Internal Toil: Fixing this improves unit economics.
• User Toil: Fixing this improves user experience (UX).

---

2. Signals Emitted by Users

Continuous Discovery

Asking users what they want often results in requests for "faster horses." To avoid this, engage in Continuous Discovery—maintaining a steady cadence of conversations.

The User Interview Checklist:

• Schedule conversations with $N$ users per period (week/month).
• Request a walkthrough of a recent task involving the platform.
• Identify the "hacks" users have implemented to bypass current limitations.
• Analyze the why behind the hack to understand the underlying problem.

Overloaded Use-cases

Some of the best features are discovered when users force the platform to do something it was never intended to do. These overloaded use-cases are essentially free prototypes built by your customers.

To decide whether to officially assimilate these behaviors, apply this logic:

def should_assimilate(use_case):
    if use_case.is_solving_real_problem() and use_case.has_broad_user_base():
        return "Promote to First-Class Feature"
    else:
        return "Leave as User-Hack"

Partner-to-Prototype

While overloaded use-cases are accidental, Partner-to-Prototype is a deliberate strategy. You collaborate with a user to build a solution. This is an exploration, not a guarantee of a permanent feature. The litmus test remains: Does anyone else have this problem?

---

3. Signals Emitted by the Organization

OKRs and Management

• OKRs: These are the most straightforward signals; if it's in the OKR, the work is already "invented."
• The Manager-Repetition Heuristic: If a leader mentions a specific pain point twice in one week, there is an unaddressed anxiety there.

However, be cautious: the higher the person in the hierarchy, the further they are from the actual user. This risks building based on the HiPPO (Highest Paid Person's Opinion).

Migration Debris

Platform shifts follow the "Crossing the Chasm" adoption curve. You will always have:

1. Innovators
2. Early Adopters
3. Early Late Majority
4. Laggards $\leftarrow$ The source of "Migration Debris"

The teams that refuse to move or drag their feet create a long tail of technical debt that requires specific "invented work" to resolve.