In internet company R&D, there’s a common archetype: the engineer drowning in demands. Back-to-back meetings all day, hundreds of unread messages, a backlog that only grows. At the end of the day, it feels like everything got touched but nothing got done. Meanwhile, the high-value long-term work you know matters — value analysis, key technical challenges, system refactoring — never gets started.
If this lasts a week, it’s just a busy stretch. If it persists for months, you need to step back and solve the problem differently.
Why This Happens
The internet industry moves fast, so this isn’t a one-week problem: organizations constantly restructure and chase new growth, iteration cycles are short, and business dependencies are complex. Demands are generated faster than any individual can absorb them. The harder you chase, the further behind you fall. Eventually you’re stuck in the weeds, unable to discover new value.
Since you can’t finish everything, the real question isn’t how to finish it all — it’s deciding what to do and what to skip, so you can carve out time for long-term, high-value work.
How do you break out? My recommendation: build a working principles document. Below is what it should contain, why, and how to use it.
How to Do It
The document isn’t complicated. Call it “Working Principles” or something softer like “How to Work With [Your Name].” Put the link in your team wiki or chat profile so anyone with a request can find it.
Section 1: Define your scope. State what you’re responsible for and what you’re not. This lets requesters quickly determine whether they’ve found the right person.
Section 2: Prioritized short-term requests. This is what requesters care about most.
First, lay out your priority principles by category. For example: production incidents > committed deliverables > items blocking others > new business requests > internal optimization and exploratory work. This establishes the overall ordering.
Then within each category, rank by value and urgency, and place them in a table:
| Type | Item | Estimated Value | Estimated Effort | Urgency | Requester | Expected Delivery |
|---|---|---|---|---|---|---|
| … | … | … | … | … | … | … |
Four key points:
- The most important column is “Estimated Value.” If something has no value, urgency alone doesn’t justify doing it.
- The ordering commits to delivery sequence — items higher up will be completed before items lower down — but it does not promise that everything will eventually get done.
- Always estimate expected delivery dates, and include some buffer, because higher-priority requests may arrive at any time.
- When a new request comes in, re-sort according to your principles, update delivery estimates, and notify anyone affected.
Section 3: Reserve time for high-value work. Short-term requests carry built-in urgency. If you can never finish them, you’ll never have time for long-term work. So the document must explicitly state when long-term work happens. Two common approaches:
- Block two hours every day.
- Block one or two full days per week.
Defend the time allocation as a hard floor. If high-value work falls short in a given period, make it up at the start of the next day or week.
Section 4: Handle trivial requests on the spot. For anything solvable in under ten minutes without a context switch, just do it immediately. Ten minutes is a reference threshold — adjust to your situation, but you must have a concrete number, otherwise everything becomes “trivial.” For must-do-today trivial items, commit to batching them in a fixed time slot before end of day.
With these four sections, the document is complete.
Make It Public
Principles that aren’t shared don’t resolve conflict — they just defer it. But once the document is public, the dynamic flips. As long as the principles are reasonable, requesters will read Section 1 and self-filter, then look at Section 2 to understand your reasoning and timelines.
If someone insists their request is more important, they now need to argue why it should jump the queue — which means making a case against every item ranked above theirs. The burden of justification shifts to the requester, not you. This also gives you a defensible way to push back when your manager drops in something unimportant.
Applying It
People stuck in execution mode share a common habit: they accept every request without weighing it. Their first reaction to any incoming task is “what is this and how do I solve it” — skipping the prior question of “should this be done at all, and how important is it?”
So for every incoming request:
- Invest the effort to determine exactly which section and category it falls into, and where it belongs in the order. This requires communicating around the principles you’ve established, understanding the request deeply, and explaining the reasoning to the requester when needed.
- Identify where the document doesn’t fit reality, and continuously refine both the document and the principles. Turn exceptions into standard cases, and make the standard cases more effective.
Measuring Effectiveness
You need a set of metrics to verify the system is actually working. I recommend three layers, from low to high:
| Layer | What to Watch | Typical Metrics |
|---|---|---|
| Execution | Request flow | Weekly new requests, weekly resolved, backlog size, average delivery time |
| Structure | Time allocation | Actual ratio of long-term vs. short-term work, trivial-task ratio, number of queue-jumps |
| Value | Value delivered | What was the highest-value output each cycle, and did it come from long-term or short-term work? |
The three layers are progressive. But the one that truly matters is the value layer — the other two exist to diagnose which link failed when something goes wrong. Looking only at execution is misleading: high throughput might just mean you’re rapidly processing low-value requests. Looking only at structure isn’t enough either: spending time on long-term work doesn’t guarantee you produced anything new.
Closing
Before this document exists, you and your requesters have no shared frame of reference — every new request triggers a fresh priority negotiation from scratch. Once the document is published, disputes have a ruleset to reference, and communication shifts from repeated one-on-one explanations to collective trade-offs against a shared set of principles. The work still won’t all get done, but the feeling of being dragged along will stop. You can step back and focus on value.