The Two‑Action Rule That Stopped Me Opening Tabs Like They Owed Me Money
Before I open a new tab or app I must name the next two actions and a time budget. It killed my tab sprawl, cut context switches, and taught me what actually needs my attention.
Written by: Rohan Deshpande
It was 11:27pm and I was “researching” why a feature I shipped had a race condition. My browser had 27 tabs. My laptop fan hummed. Slack pings from two timezones blinked in the corner. I couldn’t finish the thing. Instead I kept opening more tabs — Stack Overflow, a blog, the repo, a Twitter thread — because opening felt like progress. It wasn’t. I was simultaneously doing everything and nothing.
That pattern lived with me for years. Morning: three-minute inbox triage turns into two hours of link hopping. At work: I start a bug fix, then pull a dependency update, then skim a spec, then drop everything to reply to a message. The cost wasn’t just lost time. Context switches left half-done code, missed edge cases, and evenings where I felt I had worked hard but shipped nothing meaningful.
So I invented a tiny rule. It sounds obvious, but it had teeth.
The Two‑Action Rule Before I open a new tab, app, or file I have to say aloud (or type) two things:
- The immediate next action I will take there.
- The follow-up action I will take right after that.
And a time budget: how long I will spend (usually 5–25 minutes).
Example: I want to open a GitHub issue. I must be able to say: “Open issue → copy stack trace to the description.” Time: 10 minutes. If I can’t name both steps clearly, I don’t open it now — I add it to my “Review Later” list (a simple note in Obsidian/Notes or a Trello column).
Why it works Naming two actions forces specificity. Opening a tab is vague progress. Saying “open X” plus “copy Y” makes the task real and bounded. The time budget turns curiosity into a mini-sprint. It stops me from falling down related links because the follow-up is fixed.
A few small practical bits that make it stick:
- I use Cmd/Ctrl+Shift+T to reopen a tab when I need it, but I rarely keep things open for discovery. Reopening costs nothing and preserves friction.
- For Slack and email, I created two inboxes: “Now” and “Later”. Messages I can resolve in ≤5 minutes go to “Now”. Everything else goes to “Later” with a note of the two actions required. The “Later” list is my trade-off ledger.
- I set browser shortcuts for three tabs I actually need all the time (CI, error tracker, docs). They are an explicit exception, not the rule.
This isn’t a time-blocking facelift. It’s a decision filter. It distinguishes “I will do this now” from “I might do this later.”
Where it improved real work On-call nights became less frantic. When the pager buzzed, I would say the two actions out loud before switching context: “SSH to server → check last 50 lines of journalctl.” It focused the triage and stopped me from opening five dashboards and guessing.
I stopped starting large edits in the middle of a debug. That stopped half-baked commits and rollbacks. Code reviews improved: I opened a PR only when I could say “run tests → check diff for X”. No more accidental context creep.
Caveats and the week it failed me The rule is blunt. It fails when signals are legitimately urgent or when the environment requires constant monitoring. I learned that the hard way.
A month in, I ignored a “small” Slack channel where the infra team posted deploy statuses because I had put it in “Later”. That afternoon a deploy failed in production. The infra lead DM’d me and asked why I wasn’t watching the channel. I had a defensive list of two-action justifications — none of which mattered at 3pm when pages stacked up. I had to admit I misapplied the rule.
How I fixed it: I added a simple exception layer. Channels and contacts tagged “monitor” bypass the rule during business hours, and critical alerts have explicit escalation paths (pager or call). The rule became a guideline, not a straightjacket.
Another limitation: serendipitous learning dries up. I used to stumble into new papers or tools by following rabbit holes. The Two‑Action Rule makes discovery deliberate — which is good for shipping, worse for exploration. I now schedule two discovery windows a week. Different muscle.
How I actually use it (not the idealized version)
- Use a physical sticky or a note. When tempted to open something, write the two actions and the time on the sticky. It’s visible and adds a tiny pause.
- If something needs more than 25 minutes, convert it into a calendar block. Otherwise it competes with everything else.
- Keep one “panic” exception: a small set of channels and people that can ring through. Define it and tell your team.
- If you work across slow office internet (I do, in a Bengaluru startup with flaky VPN), the friction of reopening tabs matters. I keep a local “quick links” note for things I do genuinely need frequently.
An honest trade-off The biggest trade-off is initial slowness. For two weeks I felt like I was doing less. I was. I was also focusing more. Managers noticed quicker pull requests with fewer follow-ups. Peers noticed I stopped half-responding in meetings because I wasn’t mentally tab-hopping. But some colleagues saw me as less nimble on Slack, which I had to explain away with a note: “I respond faster to important threads.”
What I walked away with This rule taught me to treat attention as a finite currency. The trick wasn’t to be omnipresent. It was to be present where it mattered. The Two‑Action Rule is less about discipline and more about clarity: if you can’t name the next two moves, it probably doesn’t deserve your immediate attention.
I still open tabs. I still get pulled into rabbit holes. But now I decide with a sentence and a timer. That tiny friction is the thing that finally stopped me opening tabs like they owed me money.
Question: what’s the smallest decision filter you use that actually changes your day? I’m still curious.