In R&D work across the internet industry, there is a recognizable type: too many requests to handle, days consumed by back-to-back meetings, hundreds of unread messages in chat, and a backlog that only grows. At the end of a busy day, it feels as if they have done everything and accomplished nothing. Deep down, they have long known that a few long-horizon, high-value tasks deserve their time: value analysis, tackling hard technical problems, and system refactoring. Yet these are precisely the tasks they never have time to begin, let alone advance.
If this lasts only a week, it can still be treated as a busy stretch. If it goes on like this for months, you need to break out of it and solve the problem another way.
Why This Happens
The internet industry moves too fast for unfinished work to remain a one-week problem. Organizations keep adjusting and finding new sources of growth. They experiment, make mistakes, and adapt quickly. Business structures and dependencies are complex. As a result, requests naturally arrive faster than one person can work through them, and the more you chase, the slower you get. Eventually you get stuck in day-to-day work, unable to find new value or make incremental gains.
Since you cannot get it all done, the key is not how to finish it but how to decide what to take on and what to turn down. That frees you to think about long-term, high-value work in parallel.
So how do you actually break out? My suggestion is to solve the problem with a working principles document. The rest of this article covers what to put in it, why it is worth writing, and how to use it.
How to Do It
The document is not complicated. You can call it Working Principles, or something gentler, like A User’s Guide to [Your Name]. The link can go in the team wiki or in your chat status, so every requester can find it.
Section 1: Define your scope. Spell out what you are responsible for and what you are not. Make sure a requester can quickly tell whether they have found the right person.
Section 2: Rank short-term requests. This is the part requesters care about most.
First, based on your own situation, set out priority rules for each request type. For example: production incidents > committed business deliverables > collaborative work that blocks others > new business requests > internal optimization and exploratory work. That establishes the overall order.
Then, within each type, rank items by value and urgency, and put every request in the table below:
| Category | Item | Value estimate | Effort estimate | Urgency | Requester | Expected delivery time |
|---|---|---|---|---|---|---|
| … | … | … | … | … | … | … |
Four points to keep in mind:
- The value estimate is the most important column in the ranking. If an item has no value, urgency alone does not make it worth doing.
- The ranking promises delivery order, not completion. Items higher up will be finished before items lower down. That does not mean everything will eventually get done.
- Every item needs an expected delivery time, with some slack, because a higher-priority request may still arrive at short notice.
- When a new request comes in, re-rank the list and adjust delivery times according to the principles. Notify everyone affected.
Section 3: Set aside dedicated time for high-value work. Short-term requests carry built-in urgency. Once you cannot finish the short-term requests, you will never have time for long-term, high-value work. So the document must state clearly when you will do long-term work. Two approaches are common:
- Two fixed hours every day.
- One or two fixed days every week.
Protect a minimum share of your time for high-value work. If you fall short of that minimum, make up the time at the start of the next day or week, before anything else.
Section 4: Handle quick tasks on the spot. If you can solve something in ten minutes or less without a context switch, do it right away. Ten minutes is a reference point. You can adjust it to your situation, but there must be a definite number; otherwise everything qualifies as a quick task. For quick tasks that must be handled the same day, commit to handling them as one batch in a fixed slot before you leave work.
Once you have written these four sections, the working principles document is complete.
Publishing It
If people cannot agree on the principles, conflicts will continue. But once the principles are public, the situation reverses. As long as the principles make sense, a requester will read Section 1 first and decide whether to ask at all. Then they will look at Section 2 to see why you ranked their request the way you did and when you expect to deliver it.
If they still insist their request matters more, they have to explain why it should jump the queue. That means arguing against every request ranked above theirs, one by one. You no longer have to explain why delivery is slow. That puts the burden of justification on them. The same approach also gives you a firmer basis for keeping your boss from dropping an unimportant task on you at short notice.
Applying It
People stuck in execution tend to share one bad habit: they take on whatever comes their way, without weighing how much it matters. Their first reaction to any request is always “What is this about, and how do I solve it?” Yet they avoid thinking about “Should this be done at all? How important is it? When should it be done?”
So for every request, do two things:
- Make the effort to work out exactly which section and type it belongs to, and how it should be ranked. That means working from the principles in the document: talk the matter through, understand it properly, and give the requester the explanation they need.
- Analyze the parts of the document that no longer fit the current situation well. Keep improving the document and the principles. Gradually turn exceptions into standard cases, and make the standard cases work better.
Measuring
You also need a set of metrics to check whether it is really working. I suggest looking at three layers, from low to high:
| Layer | What to watch | Typical metrics |
|---|---|---|
| Execution | Request flow | New requests per week, requests resolved per week, backlog size, average delivery time |
| Structure | Time allocation | Actual share of time spent on long-term versus short-term work, share of time spent on quick tasks, number of times someone jumped the queue ahead of you |
| Value | Value delivered | Highest-value output of each retrospective, and whether it came from long-term or short-term work |
The three layers build on each other. But the value layer is the one that really matters. The two layers above are there to pinpoint which link failed when something goes wrong. Looking only at the execution layer will mislead you, because high throughput may just mean you are clearing low-value requests quickly. Looking only at the structure layer is not enough either. Spending time on long-term work does not mean you have produced anything new.
Conclusion
Before you write this one-page document, you and your requesters have no shared basis for deciding priorities. Every new request means negotiating its priority from scratch. Once the document is up, you have rules to refer to when disagreements come up, and communication shifts from repeated one-on-one explanations to trade-offs around the same principles. You still cannot get it all done. But you stop being pushed along, and you can step back and look at value.