Duplicate work is quiet and expensive
Distributed teams lose hallway overlap. Nobody sees you already opened the file. Two engineers can implement the same fix, write the same doc section, or chase the same customer report without knowing until merge conflict, embarrassed Slack thread, or wasted review hours.
Duplicate async work feels like diligence from each side. From the system view it is double cost, inconsistent outcomes, and eroded trust in who owns what.
Prevention is cheaper than reconciliation. It lives in visible claims, narrow tickets, and habits that treat silence as unknown, not agreement.
Example: two branches, one bug
Example: Production shows duplicate charges on retry. Engineer A posts in channel "looking at payment idempotency." Engineer B, in another zone, opens the same service an hour later because the ticket was vague and unassigned.
Both branches pass tests. One gets merged. The other is thrown away or worse, partially merged later with conflicting logic.
The waste is not only the thrown-away branch. It is the review time, the context both people loaded, and the story teammates tell: coordination failed here.
Claim work in the artifact, not only in chat
Chat claims evaporate. Ticket assignment, comment with name and intent, or pull request draft linked early survives time zones.
Minimum claim language: who, what scope, expected done by when, what is explicitly out of scope.
"I am taking ticket 8841 payment retry idempotency through merge and staging verify. Not touching webhook signatures in this pass."
That sentence prevents overlap better than a reaction emoji on a thread.
Narrow tickets beat heroic titles
"Fix payments" invites duplication. "Idempotent charge create for POST /v2/charges when client retries within 60s" invites one owner.
If the ticket is wide, split before work starts. Wide tickets are where parallel good intentions collide.
Status updates as coordination, not performance
How to write async status people read is not about impressing managers. It is about making overlap visible early.
Include current hypothesis and next step, not only percent complete. "Reproduced on staging with order 992; next: add idempotency key in ChargeService" tells others not to start the same repro from zero.
When to sync live
Async-first does not mean never talk. When a remote team needs a meeting applies when two people discover parallel work mid-flight and need five minutes to divide scope, not an hour of storytelling.
Convert overlap into a split: one person finishes path A, other takes path B, or one abandons with explicit handoff notes.
Managers and leads: assign or expect claims
Unassigned backlog items in urgent columns are duplicate-work factories. Either assign before the day starts or require public claim before coding.
Praise visible claims the same way you praise fast merges. Culture follows what gets thanked.
Duplicate docs and duplicate decisions
Code is not the only duplicate surface. Two people writing onboarding docs, runbooks, or architecture notes without checking creates conflicting truth.
Use a single ticket for doc work. One owner beats two pages with similar titles.
Decisions belong in tickets with links from chat. Treat meetings as last resort includes not re-deciding in side threads what was already decided in writing.
Research spikes need expiry
"I am investigating latency" without end date lets three people profile the same endpoint. Timebox spikes: forty-eight hours, outcome is a comment with findings and recommendation, then either a build ticket or close.
Spike output should answer "should someone else start this?" explicitly.
Handoffs prevent restart duplication
When you stop mid-task, leave work someone else can continue. Branch name, failing test, next command. Without that, a well-meaning teammate duplicates your half-done exploration.
Blockers reported without passive voice
How to report blockers without passive aggression matters here too. "Still waiting on API keys" hidden in a standup note lets another person build against mock data that will be thrown away.
Name the blocker, owner, and date needed. If keys are late, the ticket should say paused, not silently idle.
Review queue as duplicate signal
Two pull requests touching the same files for the same symptom should trigger a pause, not two approvals. Reviewers are allowed to ask authors to coordinate before deep review.
Reviewers who only comment on style while missing duplicate intent fail the team as much as authors who did not claim.
Example: design question in three DMs
Example: Three engineers ask design for button colour in private messages. Design answers three times with slightly different wording. Product hears three "decisions."
Fix: one ticket, one thread, one decision pasted in ticket body, link shared once in the channel that needs it.
Search before you start
Thirty seconds searching the tracker beats two hours duplicating a branch. Make search habitual before "I'll just fix it quick."
Leaders redirect pings
When a ping arrives without a ticket, redirect: "Is there a ticket? I will watch that." Amplifying private questions multiplies duplicate answers.
Freelancers and clients
Clients sometimes hire two contractors for speed without telling either. Ask at kickoff: "Is anyone else working this area?"
Document your scope in email. When overlap appears, surface it early with options rather than competing silently until invoice time.
Tooling will not save bad norms
Shared boards help only when people update them before work, not after merge. Bots that announce pull requests help when people read them before starting similar tickets.
No tool replaces the sentence "I have this."
Recovering from duplicate work without blame
When overlap happens, focus on merge path and learning, not courtroom. Extract one combined solution, note the process gap, adjust ticket template or claim rule.
Blame cycles make people hide work in private branches, which increases future duplication.
Async guide as team baseline
Shared vocabulary for channels, response expectations, and where decisions live reduces duplicate threads. Async communication for distributed teams is a team document, not a solo preference.
Duplicate async work is a coordination failure, not a character flaw. Write claims where others can see them, shrink ticket scope, timebox research, and treat status as shared map data. The goal is one finished outcome per problem, not two heroic parallel attempts that meet at conflict time. ## On-call and incident overlap
During incidents, duplicate fixes are common because adrenaline outruns tickets. Still open one incident doc with owner roles: investigator, communicator, patch author. Two silent patches to production create rollback nightmares.
After calm returns, merge learnings into one postmortem ticket. Incidents are the highest-cost place to allow duplicate async work.
Interns and new hires
New teammates duplicate work because they lack search habits and fear looking idle. Onboarding should include how we claim work before here is the repo. Pair first tickets with explicit claim comments they can copy.