Slack measures messages sent. We built the opposite.

Relay is the new team communication layer inside T2D3 OS: threads that end, an inbox that only counts what needs you, and delivery rules the software actually enforces. Here's why we built it, and what we refused to build.

In October 2024, I did something I don't recommend: I counted our productivity in the form of individual messages. One month of Slack in our company channels came to roughly 50,000 messages. That's about 2,500 per working day. Everyone was busy. Everyone was responsive. Then I lined the activity up against output, and the correlation ran backwards — our noisiest month produced three strategic decisions, while a quiet August with half the team on vacation produced five.

Less communication, more progress. I wrote that story down in a new book I'm drafting, The Currency of Mortality, and I've been unable to unsee it since.

I've seen teams try the standard fix. Silent Mornings — no Slack before noon — lifted measured productivity by roughly 40 percent. The team hates it for two weeks, and then something better than compliance happens: they stop asking how they'll coordinate, because most of the coordinating turns out to be anxiety wearing a work costume.

The tool isn't broken. It's working as designed.

Stewart Butterfield described Slack in 2016 as "a central nervous system for teams." He was right, and that's the problem. Nervous systems react. They interrupt. They treat every stimulus as urgent because they can't tell the difference.

Follow the incentives and the design makes sense. A chat tool reports its health in daily active users and messages sent. The more you're interrupted, the better its numbers look. An average Slack user checks it about every 6 minutes, sends about 70 messages a day, and keeps it open around 9 hours.

That's not communication. That's captivity with a green dot.

The Doist team — the roughly 100-person remote company that makes Todoist — lived this in 2015, drowning in their own real-time chat, and did something radical: they built Twist, a communication tool organized around threads instead of streams. Their team distills their approach into four defaults.

1. Written, so thinking has to complete before it ships.
2. Public, so nobody needs to be "kept in the loop."
3. Patient, so a considered answer tomorrow beats a reflexive answer in six minutes.
4. Permanent, so the conversation becomes documentation instead of evaporating scroll.

Those four defaults taught us most of what we needed. Building Relay, we added a fifth: Finished. Every conversation should end.

Why this lives inside T2D3 OS

T2D3 OS exists to raise a team's signal-to-noise ratio. We mine signal from your customers, your interviews, your market; we assay its quality; we turn it into a GTM foundation your whole company executes from. It would be absurd to do all that and then hand the team's daily coordination to a tool whose business model is noise.

There's a second reason, and it's structural. In a separate chat tool, a conversation floats free — three weeks later nobody remembers what was decided, so you have the conversation again. Inside the OS, a Relay thread attaches to the thing it's about: the task, the strategy module, the OKR, the decision. When the thread resolves, the resolution stays welded to the work. Your communication tool becomes your documentation, searchable forever, exactly where the next person will look.

What Relay actually does

Threads, not streams. Every Relay thread has a subject, an audience, and an end. It's open until someone resolves it, decides it, or honestly closes it as drifted — and then it becomes part of the permanent record. There is no infinite channel to fall behind on.

An inbox that counts obligations, not messages. Relay never shows you an unread count. It shows threads that need your input — and the only way a thread gets there is that someone explicitly asked you, or you own the decision. Reading obligates nobody. And if you're the wrong person to ask, one click on Pass declines it, visibly and guilt-free, so the ask moves to someone who can answer it.

Urgency that costs the sender, not the receiver. A normal thread carries a 72-hour response norm. Marking one time-sensitive moves that to 24 hours — and requires you to type a one-line reason that everyone in the thread will see. Urgency inflation dies in daylight.

A Communication Contract the software enforces. Every person sets delivery windows (at most 4 a day), quiet hours, focus blocks, and vacations. Relay batches everything to those windows: one digest at 9 am, one at 3 pm, silence in between. If you already saw a thread in the app, no email follows. If you're on vacation, senders are told honestly at compose time — and nothing gets through. In Beyond Busy this is called the communication contract, with a rule we took literally: it isn't policy, it's code.

No presence, anywhere. No green dots, no typing indicators, no last-seen. Presence indicators exist to make attention legible to other people, and legible attention gets taken.

Decisions as first-class citizens. A decision thread carries a record — context, options, decision, rationale, and one directly responsible individual — and every decided thread lands in a searchable decision log. "Why did we drop that pricing tier?" becomes a lookup, not an archaeology dig.

The metrics we refuse to ship

Relay measures threads resolved, decisions made, and time-to-decision. It will never show messages sent per person, response-speed rankings, streaks, or any leaderboard of who answers fastest. Those metrics train exactly the behavior we built Relay to end. A communication tool should brag when its numbers go down.

Relay ships to every tier of T2D3 OS, because a calm team isn't a premium feature. It's the point.

Discussion Items:

Bring these to your next leadership conversation — ideally as a written thread, to practice what this post preaches.

• Count one month of messages in your current chat tool, then count the decisions that month actually produced. Compare the two numbers out loud.
• List the last five times someone marked something urgent. How many were urgent for the receiver, and how many were just anxious for the sender?
• Identify where your team's decisions live today. If a new hire asked why you chose your current pricing model, could anyone find the answer in writing?

Questions to Ask:

• How many hours of deep work did your calendar actually contain last week?
• What would break, honestly, if every internal message waited 24 hours for a reply?
• Who on your team is performing responsiveness instead of producing work — and did the tools teach them to?

Choose the defaults

Twenty-five years ago we let email eat the workday. Ten years ago we let chat eat what was left. This time we get to choose the defaults.

Relay is rolling out inside T2D3 OS now, starting with our own team — the same way we test everything. If you want the thinking at full depth, keep an eye out for my new book behind it: The Currency of Mortality, from T2D3 Publishing. And if you'd rather just work this way, start free on T2D3 OS today and open your first thread. Make it one that ends.