Killing ghost tasks: SSoT for small teams

A ghost task is one that Jira, Linear, and Slack all describe differently — and nobody knows which version is true. A typical small team carries ten to twenty of them at any moment, and they cost about three hours per Builder per week to maintain.

The fix is to have one source of truth. Every team agrees with this sentence and then ignores it for two years. Here's the actual playbook.

How ghost tasks form

Ghost tasks don't appear because anyone wants them. They appear in three predictable steps:

Step 1. The team starts on Tool A. Someone joins from a previous job where Tool B was better. They start using Tool B for "their" projects.

Step 2. A status meeting needs a snapshot of all projects. Someone makes a Notion doc that copies from both tools. The doc is now a third source.

Step 3. A decision happens in Slack. It contradicts Notion. Nobody updates either tool. The truth lives in the DM.

Six months later you have four sources, none of them right, and the lead spends Monday rebuilding a status dashboard from screenshots.

Why "we'll just keep them in sync" fails

The most expensive belief on small teams is that two tools can be kept in sync by discipline. They can't, because synchronisation is a tax on every change and the tax compounds:

• Each tool has its own state model — "in progress" in one is "doing" in another.
• Each tool has its own permissions — some changes only some people can make.
• Each tool has its own latency — what's updated in Linear at 11pm isn't in the Notion doc until Tuesday's review.

There is no level of discipline that survives the tax. The tax wins by month four.

The same logic applies to bidirectional integrations between PM tools. They look like they solve the problem; they actually just move the disagreement into the integration layer, where it's harder to see.

The SSoT test (four questions)

To decide if you actually have a single source of truth, ask:

1. If two people disagree on task status, which tool wins? If "it depends," you don't have an SSoT.
2. Where does a new hire learn what the team is working on? If the answer involves more than one URL, you don't have an SSoT.
3. Where does the standup get its updates? If it's "everyone says," your humans are the synchronisation layer.
4. When a task moves to "done," what other places update? If the answer is "you also have to..." — that's the synchronisation tax.

A real SSoT answers question 1 with a name, question 2 with one URL, question 3 with "we read the board," and question 4 with "nothing else."

A migration that doesn't burn the team

If you decide to consolidate, here's a four-week migration that's worked for three of the teams we run with:

Week 1 — Pick the source. One tool. No "we'll evaluate" — pick. The criteria is which tool's data model matches your work, not which one has the most features.

Week 2 — Mirror, don't migrate. Run the new tool in parallel. Don't move tasks. Watch which tool the team actually opens when something changes. The truth shows up.

Week 3 — Migrate by current sprint only. Move the next two weeks of work to the SSoT. Don't try to backfill history — historic tasks aren't ghost tasks, they're just history.

Week 4 — Delete the others. Not archive — delete. If you can't bring yourself to delete, you'll keep maintaining them. The discipline is the deletion.

This is also the order Aura 4 onboarding follows. The result is a single board the team reads instead of standup.

When to keep two tools (and when not to)

There are legitimate cases for two tools. The lines are sharper than people pretend:

Keep two tools when they serve genuinely different jobs that don't overlap. Issue tracking for a specific repo plus an ops board for the whole team is fine — they're for different audiences.

Don't keep two tools when the same task could live in either. That's the configuration that creates ghost tasks. There is no middle ground; if a task could live in either tool, eventually it'll live in both, half-updated.

A useful rule of thumb: a team of fewer than 20 people, doing work that touches both engineering and ops, should have one task tool. Adding a second is a decision you'll regret in nine months.

The summary, for an eng lead

If you suspect you have ghost tasks:

1. Take a single project. List every place where its status is recorded. That's your number.
2. Run the SSoT test (four questions) on that project. Note where you fail.
3. Pick one tool. Migrate two weeks of work. Delete the others.
4. Don't trust your discipline to keep two tools synchronised. It won't.

If you want a tool that's designed to be the single source from day one — real-time, local-first, audit-friendly — that's what Real-time Sync is for.