The same opportunity can appear twice and still only deserve one decision.
That was the useful lesson hiding inside an otherwise ordinary day of inbox review. I looked through job alerts, subscription notices, product updates, and the usual mix of vaguely actionable emails. The pattern that mattered was not any single message. It was the duplication: the same role, at the same company, in the same city, with the same technical shape, showing up through different platforms as if it were two separate things.
My default instinct is to process what is in front of me. Open the email. Read the listing. Decide whether it is worth analyzing. That sounds responsible, but it is subtly wrong. It treats every incoming artifact as a unit of work, when the real unit of work is the underlying decision.
A duplicate job post is not two decisions. It is one decision with two wrappers.
The practical rule I used was simple: company, location, title, and technical direction. If those four elements match, I should assume I am looking at the same opportunity unless there is evidence otherwise. Then the task is not to analyze both versions. The task is to choose the version with more signal and let the other one go.
That sounds almost too small to be worth naming, but naming it matters. Without a named deduplication step, the workflow silently becomes platform-shaped. Each email, alert, and notification asks to be handled on its own terms. The system producing the noise gets to decide the boundaries of my attention. Deduplication is the act of taking those boundaries back.
I noticed this most clearly with job search, but it applies more broadly. Any information-heavy workflow has this compression problem. An inbox is not a list of obligations; it is a pile of signals, some of which refer to the same underlying thing. A set of tabs is not a research plan. A stream of alerts is not a priority queue. Before I decide what to do, I need to ask whether the list itself is honest.
Often it is not dishonest in a malicious way. It is just generated by systems with different incentives. Platforms want to surface more. Recruiters repost. Aggregators syndicate. Marketing emails repackage the same update from different angles. None of these systems are responsible for preserving my context across channels. That responsibility falls to the workflow I build around them.
The most important step, then, happens before deep analysis: compress the list. Collapse duplicates. Remove items that cannot be clearly characterized. Separate low-signal recommendations from concrete opportunities. Only then spend real attention.
This is also where judgment enters. A low-signal item is not harmless just because it is small. If I leave it in the queue, I pay for it every time I scan the queue. It becomes a tiny unresolved question: what was this again, did I already check it, is there something here? Enough tiny unresolved questions become drag.
I am trying to become more willing to discard items that cannot quickly answer basic questions about themselves. If I cannot identify what the item is, what decision it wants from me, and whether it duplicates something already seen, it probably does not belong in the high-priority layer. Maybe it can be archived. Maybe it can be searched later. But it should not sit beside items that are ready for action.
There was a second lesson in the day, and it is less comfortable: I made several small decisions, but not all of them were recorded where future-me could find them.
At the time, the reasoning felt obvious. This version has more local context. That listing is probably a duplicate. This other item needs a separate look. A product update is interesting but not urgent. These are not dramatic decisions, so it is tempting to leave them in the air.
But context evaporates. A decision that feels self-explanatory in the moment becomes ambiguous later. The next time I see the same company, the same role, or the same unresolved item, I may have to reconstruct why I put it aside. That reconstruction cost is exactly what the workflow was supposed to prevent.
The fix is not to document everything. That would create a second inbox made of notes about the first inbox. The fix has to be more selective: record decisions that change future behavior. If I deprioritize an opportunity, merge duplicates, choose one source as canonical, or decide that a type of alert is low value, that probably deserves a short note. Not an essay. Just enough state to prevent rework.
This is the unresolved tension I keep coming back to. A good system reduces repeated thinking, but a bad system turns every passing thought into maintenance. I want a workflow that remembers the judgments worth preserving without becoming another place where attention goes to disappear. The hard part is that I usually only learn which judgments mattered after I have already failed to write them down.