Here’s a test: could your process run if Slack went down for a day?

If the answer is no—if work would stop, decisions would freeze, tasks would pile up—then what you have isn’t really a process. It’s a continuous conversation masquerading as one.

Real processes don’t require real-time chat to function. They’re designed to work asynchronously, with sync communication reserved for exceptions. And teams that build this way operate more reliably, scale more easily, and don’t collapse when key people are unavailable.

The Chat-Dependent Organization

In many small businesses, Slack (or Teams, or WhatsApp) has become the nervous system. Everything flows through it. Questions, updates, decisions, approvals, complaints—all in the same stream.

At first, this feels efficient. Communication is immediate. Everyone’s in the loop. Questions get answered fast.

But look at what this creates:

History becomes archaeology. Try finding a decision made three months ago. It’s buried in a thread, in a channel, somewhere. Maybe you can search for it. Maybe you remember who said it. Maybe not.

Onboarding requires excavation. A new team member can’t learn by reading documentation—there isn’t any. They have to piece together how things work by scrolling through chat history or asking questions that have already been answered dozens of times.

Decisions live in threads. “We decided to do X” means someone said so in a Slack thread that ten people saw and no one recorded. When the next person asks, someone has to re-explain. Or worse, they make a different decision because they don’t know the first one existed.

Sync becomes mandatory. If information only exists in chat, people have to be online to access it. Miss the conversation and you miss the context. The whole team becomes tied to real-time presence.

What a Real Process Looks Like

A real process can run without chat. It has these characteristics:

Clear trigger. Something happens that starts the process. An email arrives. A form gets submitted. A date hits. The trigger is unambiguous.

Defined steps. Each step has an owner, an input, an output, and a completion criteria. It’s documented somewhere that isn’t a chat thread.

Async handoffs. When one person finishes their step, the next person is notified (not asked, not messaged—notified by the system). They pick up the work when they can.

Recorded decisions. When a decision gets made, it goes somewhere permanent. A project document. A wiki. A shared folder. Not just a message that scrolls away.

Exceptions are exceptions. Chat is for genuinely unexpected situations that don’t fit the process. The normal path doesn’t require real-time coordination.

Designing Out the Chat Dependency

To move from chat-dependent to async-capable, examine each process and ask:

Where are decisions made? If they’re made in Slack, create a better place. This could be a document that gets updated, a tool with decision logging, or even a simple “decisions log” spreadsheet.

What questions get asked repeatedly? These should become documentation. Every time someone asks “how do we do X?” and gets an answer in chat, that answer should also go somewhere permanent.

What requires approval? Build approval into the system, not chat. This might mean a workflow tool, or just a clear rule: “If X, then the owner can proceed. If Y, escalate by email to Z with a 24-hour response expectation.”

What’s blocked by waiting for someone? These are the real bottlenecks. Often they can be solved by clearer ownership, decision authority, or better documentation—not faster chat responses.

The Documentation Habit

The key behavior change is this: when something happens in chat that others might need later, it gets recorded somewhere else.

This doesn’t require heavy process. A simple rule helps: “If it took longer than two minutes to figure out, write it down.” Over time, this builds a knowledge base that reduces chat dependency.

The resistance is usually: “That’s extra work.” But it’s less extra work than re-explaining the same thing six months from now. It’s less extra work than the new hire spending two weeks in confusion because context lives only in old threads.

Documentation isn’t bureaucracy. It’s how knowledge compounds instead of evaporating.

Chat as Exception Handler

Once your processes are async-capable, chat becomes something different. It’s not the primary communication channel—it’s the exception handler.

Use chat for:

Genuinely urgent situations (define “urgent” strictly)
Complex discussions that need rapid iteration
Social connection and team culture
Problems that don’t fit any existing process

Don’t use chat for:

Routine status updates (put these in a shared document)
Decisions (make them in a recorded place)
Questions that have documented answers (point to the documentation)
Approvals (build them into your workflow)

When chat is reserved for exceptions, it becomes useful again. Signal is high. Noise is low. Messages actually matter.

The Implementation Path

If your team is deeply chat-dependent, changing overnight is disruptive. Here’s a gradual path:

Start with one process. Pick something repetitive where chat currently coordinates work. Document it. Create clear handoffs. Try running it async for two weeks.

Build the documentation habit. After every chat discussion that produces useful information, someone writes a brief summary somewhere permanent. Start with one person doing this consistently.

Set response expectations. Announce that non-urgent chat messages will get responses within four hours (or whatever timeframe works). This begins to break the instant-response expectation.

Create dedicated channels. Move recurring topics (project status, client updates, decisions) out of general chat and into specific places—documents, databases, or at least dedicated channels with clear purposes.

Review weekly. In your team sync, ask: “What happened in chat this week that should be documented? What questions got asked that should have had documented answers?”

The Cultural Shift

Moving away from chat dependency is partly technical and partly cultural.

The technical part is building the documentation, the workflows, the async-capable processes. That takes time and deliberate effort.

The cultural part is changing expectations. People need to believe that not being instantly available is okay. That reading documentation before asking is expected. That async responses are normal, not slow.

Leaders set this tone. If the founder responds to every Slack message in thirty seconds, the team learns that’s the expectation. If the founder models async behavior—responding in batches, protecting focus time, pointing to documentation—the team learns that instead.

The goal isn’t to eliminate chat. It’s to make chat optional for operations. Systems that require real-time coordination are fragile. Systems that work asynchronously are resilient.

Design for resilience.

Async Communication for Small Teams — The broader case for async-first communication.
Why Constant Availability Slows Teams Down — Understanding the hidden costs of real-time expectations.

Croatian Translation

Evo testa: bi li vaš proces mogao raditi da Slack prestane raditi na jedan dan?

Ako je odgovor ne—ako bi rad stao, odluke bi se zamrznule, zadaci bi se gomilali—onda ono što imate zapravo nije proces. To je kontinuirani razgovor koji se maskira kao proces.

Pravi procesi ne zahtijevaju chat u realnom vremenu da bi funkcionirali. Dizajnirani su da rade asinkrono, sa sync komunikacijom rezerviranom za izuzetke. I timovi koji tako grade operiraju pouzdanije, lakše skaliraju, i ne propadaju kad ključni ljudi nisu dostupni.

Chat-ovisna organizacija

U mnogim malim tvrtkama, Slack (ili Teams, ili WhatsApp) je postao živčani sustav. Sve teče kroz njega. Pitanja, updatei, odluke, odobrenja, pritužbe—sve u istom toku.

Na početku, ovo se čini učinkovito. Komunikacija je trenutna. Svi su u toku. Pitanja se brzo odgovaraju.

Ali pogledajte što ovo stvara:

Povijest postaje arheologija. Pokušajte pronaći odluku donesenu prije tri mjeseca. Zakopana je u threadu, u kanalu, negdje. Možda možete pretraživati. Možda se sjećate tko je rekao. Možda ne.

Onboarding zahtijeva iskopavanje. Novi član tima ne može učiti čitajući dokumentaciju—nema je. Moraju slagati kako stvari funkcioniraju scrollajući kroz povijest chata ili postavljajući pitanja koja su već odgovorena desetke puta.

Odluke žive u threadovima. “Odlučili smo napraviti X” znači da je netko to rekao u Slack threadu koji je deset ljudi vidjelo i nitko zabilježio. Kad sljedeća osoba pita, netko mora ponovno objasniti. Ili još gore, donesu drugačiju odluku jer ne znaju da prva postoji.

Sync postaje obavezan. Ako informacije postoje samo u chatu, ljudi moraju biti online da im pristupe. Propustite razgovor i propustite kontekst. Cijeli tim postaje vezan za prisutnost u realnom vremenu.

Kako izgleda pravi proces

Pravi proces može raditi bez chata. Ima ove karakteristike:

Jasan okidač. Nešto se dogodi što pokreće proces. Email stigne. Forma se podnese. Datum nastupi. Okidač je nedvosmislen.

Definirani koraci. Svaki korak ima vlasnika, ulaz, izlaz i kriterij završetka. Dokumentirano je negdje što nije chat thread.

Async primopredaje. Kad jedna osoba završi svoj korak, sljedeća osoba je obaviještena (ne pitana, ne messengirana—obaviještena od sustava). Preuzimaju posao kad mogu.

Zabilježene odluke. Kad se donese odluka, ide negdje trajno. Projektni dokument. Wiki. Dijeljeni folder. Ne samo poruka koja odscrollava.

Izuzeci su izuzeci. Chat je za istinski neočekivane situacije koje ne pristaju u proces. Normalni put ne zahtijeva koordinaciju u realnom vremenu.

Dizajniranje bez chat ovisnosti

Da prijeđete s chat-ovisnog na async-sposobno, ispitajte svaki proces i pitajte:

Gdje se donose odluke? Ako se donose u Slacku, stvorite bolje mjesto. To može biti dokument koji se ažurira, alat s bilježenjem odluka, ili čak jednostavna “decisions log” tablica.

Koja pitanja se postavljaju ponavljano? To bi trebala postati dokumentacija. Svaki put kad netko pita “kako radimo X?” i dobije odgovor u chatu, taj odgovor bi također trebao ići negdje trajno.

Što zahtijeva odobrenje? Ugradite odobrenje u sustav, ne chat. To može značiti workflow alat, ili samo jasno pravilo: “Ako X, onda vlasnik može nastaviti. Ako Y, eskaliraj emailom na Z s očekivanjem odgovora u 24 sata.”

Što je blokirano čekanjem na nekoga? To su prava uska grla. Često se mogu riješiti jasnijim vlasništvom, autoritetom za odluke, ili boljom dokumentacijom—ne bržim odgovorima u chatu.

Navika dokumentiranja

Ključna promjena ponašanja je ovo: kad se nešto dogodi u chatu što bi drugima moglo trebati kasnije, zabilježi se negdje drugdje.

Ovo ne zahtijeva težak proces. Pomaže jednostavno pravilo: “Ako je trebalo duže od dvije minute da shvatim, zapišem to.” Tijekom vremena, ovo gradi bazu znanja koja smanjuje chat ovisnost.

Otpor je obično: “To je dodatni posao.” Ali to je manje dodatnog posla nego ponovno objašnjavanje iste stvari za šest mjeseci. To je manje dodatnog posla nego novi zaposlenik koji provodi dva tjedna u konfuziji jer kontekst živi samo u starim threadovima.

Dokumentacija nije birokracija. To je način kako se znanje slaže umjesto da isparava.

Chat kao handler iznimki

Jednom kad su vaši procesi async-sposobni, chat postaje nešto drugo. To nije primarni komunikacijski kanal—to je handler iznimki.

Koristite chat za:

Istinski hitne situacije (strogo definirajte “hitno”)
Složene rasprave koje trebaju brzu iteraciju
Društvenu povezanost i timsku kulturu
Probleme koji ne pristaju nijednom postojećem procesu

Ne koristite chat za:

Rutinske status updatee (stavite ih u dijeljeni dokument)
Odluke (donosite ih na zabilježenom mjestu)
Pitanja koja imaju dokumentirane odgovore (usmjerite na dokumentaciju)
Odobrenja (ugradite ih u vaš workflow)

Kad je chat rezerviran za izuzetke, ponovno postaje koristan. Signal je visok. Buka je niska. Poruke zapravo znače.

Put implementacije

Ako je vaš tim duboko chat-ovisan, promjena preko noći je disruptivna. Evo postupnog puta:

Počnite s jednim procesom. Odaberite nešto repetitivno gdje chat trenutno koordinira rad. Dokumentirajte to. Stvorite jasne primopredaje. Pokušajte to voditi async dva tjedna.

Gradite naviku dokumentiranja. Nakon svake chat rasprave koja proizvede korisne informacije, netko napiše kratki sažetak negdje trajno. Počnite s jednom osobom koja to radi dosljedno.

Postavite očekivanja odgovora. Najavite da će nehitne chat poruke dobiti odgovore unutar četiri sata (ili koji god vremenski okvir funkcionira). Ovo počinje razbijati očekivanje trenutnog odgovora.

Stvorite namjenske kanale. Premjestite ponavljajuće teme (status projekta, updatei klijenata, odluke) iz općeg chata u specifična mjesta—dokumente, baze podataka, ili barem namjenske kanale s jasnim svrhama.

Pregledajte tjedno. Na vašem timskom syncu, pitajte: “Što se dogodilo u chatu ovaj tjedan što bi trebalo dokumentirati? Koja pitanja su postavljena koja su trebala imati dokumentirane odgovore?”

Kulturna promjena

Odmicanje od chat ovisnosti je dijelom tehnički i dijelom kulturni projekt.

Tehnički dio je izgradnja dokumentacije, workflowa, async-sposobnih procesa. To zahtijeva vrijeme i namjeran napor.

Kulturni dio je promjena očekivanja. Ljudi moraju vjerovati da nije biti trenutno dostupan je u redu. Da se očekuje čitanje dokumentacije prije pitanja. Da su async odgovori normalni, ne spori.

Lideri postavljaju ovaj ton. Ako osnivač odgovara na svaku Slack poruku u trideset sekundi, tim uči da je to očekivanje. Ako osnivač modelira async ponašanje—odgovarajući u batchevima, štiteći vrijeme za fokus, upućujući na dokumentaciju—tim uči to umjesto toga.

Cilj nije eliminirati chat. Cilj je učiniti chat opcionalnim za operacije. Sustavi koji zahtijevaju koordinaciju u realnom vremenu su krhki. Sustavi koji rade asinkrono su otporni.

Dizajnirajte za otpornost.

Povezano

Asinkrona komunikacija za male timove — Širi argument za async-first komunikaciju.
Zašto konstantna dostupnost usporava timove — Razumijevanje skrivenih troškova očekivanja u realnom vremenu.