Decisions in a DM Do Not Exist

Alexander Chua
6 min
Decisions in a DM Do Not Exist

The short version

  • A decision only two people can see gets made twice.
  • One shared channel per relationship beats a group thread, because a channel keeps its history when the people in it change.
  • Anything about a person stays private. The test for everything else is whether it changes what gets built.

A decision made in a direct message has not been made. Two people hold a version each and nobody else can search it. We run one shared channel per client relationship, and anything that changes what gets built is said there.

Why do decisions made in DMs get made twice?

Because the record is private and partial. The two people in the thread each remember a version, and neither sits anywhere the designer or the person covering next week can read. When the work reaches them, they make the call again on their own judgement.

Nothing looks broken while it happens. The page stops matching what the client asked for, and the correction arrives later as feedback.

Where each kind of message belongs, and how it fails somewhere else:

What is being saidWhere it belongsWhyFailure mode elsewhere
A yes or no that unblocks workShared channelIt is a decision, not a chatWork restarts on somebody’s memory of it
Copy or design feedbackShared channelThe next editor needs the reasoningThe same note given twice, differently
Scope or price changeWritten confirmation outside chatIt changes the agreementTwo versions of what was agreed
Weekly status and blockersShared channel, weeklyEveryone reads the same thing at onceOnly whoever asked gets told
Feedback about a personA call, then a DMIt is about a personA correction with an audience
Anything a new joiner needsChannel or the project docThey cannot search your DMsOnboarding by interrogation

Why does everyone keep using DMs anyway?

Because they skip the audience. Writing in a channel means phrasing the thing for people who lack the context, which takes the sender longer than the DM would have. That saving is real, and the cost it creates lands later, on somebody else.

Our team does not share a working day. An answer typed at the end of one person’s evening arrives while the people who need it are asleep, and by morning it sits in a thread they have no way to search.

What does one channel per relationship look like?

One channel named for the relationship and not for the project, with both companies sitting inside it. We run 8 client accounts across 11 brands.

Where one owner runs several products, each brand is treated as its own account, because each one needed its own voice and its own ICP. An approval on one brand’s copy tells you nothing about the next one.

What goes in the channel: the ask, the answer, the blocker, the link to the thing that shipped. Every account gets delivery every week, and the questions that come out of that week go to the channel rather than to whichever of us the client was already talking to. The test is whether somebody who joins the account later would need the thread to understand why the work looks the way it does.

What still belongs in a private message?

Anything about a person. Performance, pay, a complaint about somebody’s work, the personal reason behind a missed deadline. Those start on a call and continue in a DM. Moving one of them into a shared channel gives an audience to something that needed a conversation.

Commercial negotiation sits in the same bucket until it is agreed, and then the agreed version moves somewhere permanent. Retention is a setting somebody else controls, so chat history is not a contract.

A decision in a DM does not exist for anyone else.

What do you do when a client keeps sending DMs?

Answer, then post the answer in the channel and tag whoever it affects.

The people this protects are not in the thread at all. Whoever covers the account next week reads the channel, and so does whoever joins the account later, because neither of them can search a conversation they were never in.

Related reading: what belongs in a client update and running a team across time zones.

Frequently asked questions

Why should work decisions not be made in direct messages?

Because the record is private and partial. Only the two people in the thread hold it, each with a slightly different version, and nobody who picks the work up later can search for it. The decision then gets made a second time by whoever implements it.

What is the difference between a shared channel and a group message?

A channel has a name and a purpose, and its history survives people joining or leaving. A group message is a fixed set of people, so adding somebody starts a new thread with no past attached. Context does not carry over when the group changes.

How many channels should one client relationship have?

One, named for the relationship rather than for a project. Projects end and their channels go stale while the relationship carries on. Where a single owner runs several brands, each brand is treated as its own account, because a voice and a buyer that work for one of them do not transfer to the next.

What should stay in a private message at work?

Anything about a person: performance, pay, a complaint about someone's work, the personal reason behind a missed deadline. Commercial negotiation stays private until agreed, then the agreed version moves somewhere permanent. Everything that changes what gets built belongs in the shared channel instead.

How do you get a client to stop sending direct messages?

Answer the message, then post the answer in the shared channel and tag whoever it affects, so the record ends up somewhere the next person on the account can read it.

Is chat history a reliable record of what was agreed?

No. Search is not the same as a record, and retention is a setting somebody else controls. Anything that changes scope, price or the contract gets confirmed in writing outside chat. The channel is where decisions become visible, not where the agreement is stored.

Sources

  • Chua Network delivery data across 8 client accounts (internal fact bank)
  • Chua Network engagement records, anonymized (internal experience bank)
Alexander Chua

Alexander Chua

Co-Founder, PipelineRoad. Building companies and observing the world across 40+ countries. Writing about company building, go-to-market, capital formation, and the lessons in between.

More about Alexander

Newsletter

Chua Network Letter

Occasional essays on company building, global observations, and clear thinking. No spam. No SEO bait.