Managing projects in Slack: chat is a stream, work is a state

A bug gets reported in a channel at 4pm. Three people reply. One says "I'll take it". Somebody adds a 👍. The conversation moves on, because it is 4pm and there is other work.

Six weeks later a customer hits the same bug. Nobody can find the thread. The person who said they would take it remembers saying something and is fairly sure they were waiting on someone else. The bug had been open for six weeks and was never open anywhere, because there was nowhere for it to be open.

Chat is a stream, work is a state

Slack is not a project tracker, and the reason is structural rather than a missing feature. A stream is optimised for what is new: its ordering is time, its unit is a message, its job is to move information while the information is fresh. Slack is very good at that, which is exactly why work migrates into it.

State has a different job: answering "what is true now" to someone who was not there — next quarter, or on their first day. Its unit is an item rather than an utterance, and the question is not "what did people say" but "what is outstanding, and whose is it". The medium has no way to represent an open item, only a message that once mentioned one. The owner, the current state and whether any of it is still true live in the memory of whoever was in the channel at 4pm.

The case for managing projects in Slack, made properly

Chat-first is not a mistake, and for what Slack is for — unblocking someone, asking whether a migration is safe to run, deciding in ninety seconds what would have been a meeting — it beats every tracker ever built. A team that files an issue for every question is slower to work with and more annoying. Chat is part of the record, too. TazeTSchnitzel put the fair version on Hacker News: it is "no substitute for proper documentation, but it is very useful to be able to find and link to the conversation that led to creating a ticket" (news.ycombinator.com).

So the argument is not about using less Slack. It is about which artefacts have to outlive the conversation they were born in.

Five ways work gets lost in Slack

1. The decision that exists only in a thread nobody can find. You agreed not to support Safari 15. Six months later someone asks why the polyfill is there. The reasoning was written down once, in a reply.
2. Ownership implied by a 👍. A reaction is not an assignment. It might mean "I'll do it", "I saw this" or "good idea", and afterwards nobody can tell which — including the person who added it.
3. The same question answered three times, because the answer is not retrievable anywhere. The third answer differs from the first, unnoticed.
4. Search that finds the words but not the outcome. ryukoposting: "you can't figure out what word (or synonym thereof) to search for that will give you the results you need" (news.ycombinator.com). Keyword search over a stream returns messages. You wanted the conclusion.
5. The person who was on holiday cannot catch up on state. Two thousand messages in time order, and no view of what changed on the things they are attached to. Scrollback is a transcript, not a status — which is why catching up has to be a pull rather than a scroll.

On Slack's free plan the loss is enforced: "you'll be limited to the most recent 90 days of message and file history", and anything over a year old is deleted (slack.com). A decision whose only record is a message has an expiry date.

Slack agrees, and shipped something about it

Slack has not ignored any of this. Lists, launched on 19 August 2025, puts task tracking with assignees and due dates inside chat, and any message can be added to one from its conversation (slack.com). The launch post's diagnosis is this essay written by the vendor: "People assigned to tasks have their conversations about the work outside of the project management tool", with CEO Denise Dresser framing the fix as making it so "those loose next steps shared in a project channel can be tracked across a team" (slack.com).

Two caveats. Lists are "available now on paid Slack plans" (slack.com), so the free-tier teams most exposed to this do not get them. And a list inside chat is still somewhere someone has to choose to write, which is the actual problem.

The boundary, which is smaller than a policy

The instinct after a week like that is to write a rule about what goes where. Rules of that shape go unfollowed, because they ask people to classify every message they send. Name a small set instead, and let everything else stay in chat:

• Anything with an owner. The moment a sentence contains a name and a future tense, it is an item. "I'll take it" is the trigger.
• Anything a customer noticed, especially if it is trivial, because trivial things are what nobody remembers reporting.
• Any decision you would have to re-litigate. If you would need the reasoning to defend the choice in three months, a thread is not where it lives.

The mechanism is one habit rather than a process: whoever says "I'll take it" files it before closing the tab and pastes the link back into the thread. Thirty seconds, by the person holding all the context, at the only moment they hold it. A policy needs enforcing; a habit only needs doing.

The tracker does not have to be where a discussion starts. It has to be where it ends up.

Where we come into it

We build an issue tracker, so read this as the interested party arguing its own case.

What Kevta does here is narrow. Issues carry comments and full history, so the discussion and the state are one object rather than two records somebody keeps in sync, and the issue key is stable, so pasting it into a thread still resolves next year. It also has no Slack integration today — nothing posts into a channel, there is no "add to Kevta" on a message, and moving something across is a copy-paste. That is a real cost against the habit above, and the reason the habit has to be cheap. Nor does it help with work you never file, which is why nobody updates the project board.

The boundary is the part that holds whatever you pick, and it is shorter than most teams assume — roughly what a five-person team needs and no more. Kevta is in beta; if you want the version where discussion and state are one record, join the waitlist.