The Workable Life

The Workable Life is a personal productivity blog by Audrey Whitlock, testing practical AI workflows, small-team systems, and family-tested routines.
— The Friction Audit —

Why “Just Use Slack” Is Not an Operations Strategy

Why “Just Use Slack” Is Not an Operations Strategy

“Just use Slack” is not an operations strategy. A practical look at why adding tools rarely fixes unclear ownership, missing decisions, and ordinary process friction.

“Just use Slack” is one of the most common pieces of advice I hear when small teams describe communication problems. The same pattern appears with other tools: just use Notion, just use a shared drive, just add another channel. The suggestion is usually well-intentioned. It is also incomplete. Adding a tool does not create an operations strategy. At best it changes the location of the existing friction. At worst it adds new coordination cost on top of the old problems.

I’m Audrey Whitlock. I spent years in product operations at a B2B SaaS company and now help small teams reduce operational friction without unnecessary software. I have watched the same cycle repeat: a team feels overwhelmed by email or meetings, adopts a new messaging platform, experiences a brief surge of activity, and then finds itself with the same unclear ownership, missing decisions, and repeated questions—only now distributed across more places.

The difference between a tool and a strategy is the difference between motion and progress. A strategy clarifies how work moves, who owns what, and how decisions are recorded. A tool is only useful inside that clarity.

The Appeal of the Simple Suggestion

Telling a team to “just use Slack” feels concrete and modern. It gives people something visible to do. Channels get created. Notifications get adjusted. Integrations get connected. For a short period the activity itself can feel like improvement.

What the suggestion usually skips is the harder diagnosis: Why is information getting lost? Why are decisions hard to find later? Why do the same questions keep reappearing? Why does ownership feel unclear even when people are talking constantly?

Those questions point to process problems. Tools can support better processes. They cannot replace them. When the underlying issues remain, the new tool simply becomes another place where work stalls.

What Usually Sits Underneath the Complaint

When teams say communication is broken, the visible symptom is often volume—too many emails, too many messages, too many meetings. The deeper issues tend to look different:

Unclear ownership

Work sits because no one is sure who is supposed to move it. Messages multiply while the task itself does not.

Decisions that disappear

Conversations happen, yet the final call is never written down in a place people trust. Later discussions restart from zero.

Context that lives in too many locations

Important background is split across chat threads, email, documents, and individual notes. Every new person has to reconstruct the story.

Meetings that produce no durable output

Time is spent talking, but the next steps and owners remain vague. The following week begins with the same open questions.

These problems can exist inside email, inside Slack, inside any platform. Moving the conversation to a new tool does not automatically resolve them. It often makes the fragmentation harder to see because the activity looks more modern.

Handwritten notes comparing chat activity with actual process gaps on a wooden desk.

A Real Pattern I Keep Seeing

A team adopts Slack to reduce email. Channels proliferate. Important decisions end up in private messages or fast-moving threads that are difficult to search later. New hires struggle to find history. People create parallel documents to compensate. The team is now maintaining both the chat platform and the compensatory systems.

The original pain—unclear decisions and ownership—has not been solved. It has been redistributed. The calendar is still full of meetings that rehash conversations that already happened in chat. The sense of busyness increases. The sense of progress does not.

I have seen nearly identical patterns with other tools. The specific software matters less than the absence of a few basic operating agreements: where decisions live, how ownership is assigned, and what “done” looks like for recurring types of work.

What an Actual Operations Approach Looks Like

A lightweight operations strategy for a small team does not require a large framework. It requires clarity in a few high-friction places.

Name the source of truth for decisions

Pick one place where final decisions are recorded. It can be a simple shared document, a project tool, or even a consistent message format. The important part is that people know where to look and where to write. Chat can be the conversation layer. It should not be the permanent record.

Make ownership visible and limited

Every active piece of work needs a single named owner. When ownership is shared among many people, it often belongs to no one. Visible ownership reduces the volume of “just checking in” messages that fill chat tools.

Separate conversation from coordination

Use messaging for quick questions and discussion. Use a different, more stable surface for status, deadlines, and handoffs. When everything lives in the same fast-moving stream, important items scroll away.

Reduce the number of places people have to check

Every additional channel, document, or tool extracts attention. Before adding a new one, ask whether something existing can be simplified or removed. Tool sprawl is itself a form of friction.

These agreements are ordinary. They are also the difference between a team that uses Slack well and a team that is simply busy inside Slack.

How This Shows Up at Home

The same dynamic appears in household logistics. When family communication feels scattered, the impulse is often to add another shared list, another calendar layer, or another group chat. The underlying questions remain: Who is responsible for updating the information? Where is the single place we trust? What happens when something changes?

In our house we have learned that adding another digital surface rarely fixes repeated questions. Clarifying who updates the shared calendar and treating it as the single source of truth does more work than any new app. The parallel is imperfect, but the principle travels: more tools do not automatically create more clarity.

Simple hand-drawn process map showing clear ownership and decision points on a wooden table.

Questions Worth Asking Before Adding a Tool

When the suggestion arises to adopt or expand a platform, I find a short set of questions useful:

  • What specific friction are we trying to reduce?

  • Is that friction caused by missing ownership, missing decisions, or missing context?

  • Will the new tool change those underlying conditions, or will it only change where the conversations happen?

  • What will we stop doing once the new tool is in place?

  • How will we know if the change has reduced coordination cost rather than increased it?

If the answers are vague, the tool is likely being asked to solve a process problem it cannot solve. Starting with the process questions keeps the technology in a supporting role.

The Cost of Treating Tools as Strategy

When teams equate adopting a platform with improving operations, several quiet costs accumulate. Attention fragments across more surfaces. New hires face a longer ramp because history is scattered. People spend time managing the tool instead of the work. The sense of activity rises while the rate of finished, durable progress stays flat.

These costs are rarely dramatic. They show up as persistent busyness and a background feeling that communication should be easier than it is. Diagnosing the real friction—ownership, decisions, handoffs—usually produces smaller, more durable changes than layering on another platform.

Will This Still Work on Tuesday?

A real operations approach has to survive ordinary conditions: people out of office, shifting priorities, incomplete information, and the normal interruptions of a working week. “Just use Slack” does not meet that standard because it leaves the underlying process questions unaddressed.

Clarifying where decisions live, who owns active work, and how handoffs occur does meet the standard. Those agreements continue to function when the day is imperfect. The tools can then support the agreements instead of trying to replace them.

Adding software is easy. Building the small set of operating habits that make software useful is the actual work.

Make it useful. Make it human. Make it survive Tuesday.

Last updated · 2026-09-27 15:25
— Letters — 0

No comments yet — be the first to share a thought.

Leave a comment