A four-step audit for finding the design flaws in how your team talks to each other, and the exact rewrites that fix them.
Deploy is green, staging looks clean ✅
Nice, thanks for turning that around so fast.
Hey — can you talk?
Illustrated with Slack. The same four steps run in Teams, email, tickets, or wherever your team actually argues.
From a talk at LDX3 New York by Rebecca Koniahgari, Founder, BRYGE AI
The framework
It's not a training module. There's no quiz at the end. It's a spreadsheet. It just happens to have colors.
Find
Locate the channel where the real work, and the real friction, happens.
Log
Pull the last 20 threads into a simple, anonymized 3-column sheet.
Assess
Read for ten patterns hiding in plain sight, and rewrite each one.
Group
Sort by pattern to see your team's actual communication defaults.
One channel, chosen on evidence
The busy one. Where questions get asked and decisions get made.
Not the loudest channel. The one with the most back-and-forth, where questions get asked and decisions get made.
Six channels from the same workspace. Which one would you audit?
What you're looking for
Pick a channel to score it.
Not on Slack? Same rule. Teams, a shared inbox, pull request comments: whatever surface your team actually argues in is the one to audit.
Paste each message exactly as written. Paraphrasing means your brain has already started fixing the problem before you have measured it.
Pull each message into the sheet. Watch what happens to the names.
We've been seeing inconsistencies in the API responses. Might be worth taking a look when you get a chance.
@Priya can you check the migration script, also is the pricing copy final?
Noted.
Whenever you get a chance, no rush at all — could you look at the staging deploy? 🙏
Empty. Log a message to start the sheet.
You're not grading anyone's writing. You're looking for the same failure modes, wherever they show up, and fixing each one on the spot.
Three of these are in the talk. The other seven turn up in the log anyway, so they're here too. Same treatment for each: what it is, what it costs, and the rewrite.
The ten patterns
Keep scrolling. The patterns move sideways, one at a time, until you have been through all ten.
Messages that create urgency without explaining what the urgency is. You send it and move on. They're left holding a question they can't answer: is this urgent? Is something wrong? What did I miss?
Someone reading "can we talk?" can't tell whether to finish what they're doing or drop it, so many drop it just in case. That is a fair response to a message carrying no signal about scale.
The tell: A container ("can we talk") with no contents: about what, how urgent, how long.
The shift
Name the size before you ask for the time.
Can we talk for 15 minutes this week? Not urgent. I want to discuss the API review.
Context first, request last. The reader has to hold everything in working memory before they even know what they're being asked to do, so the message gets reread, or missed entirely.
Journalism and the military fixed this decades ago: ask first, context after. The reason is working memory: every sentence before the ask gets held onto in case it turns out to matter.
The tell: You can't tell what you're being asked to do until the last sentence.
Lead with the ask. Put the context underneath.
We've been seeing inconsistencies in the API responses over the last few days. Might be worth taking a look when you get a chance.
Can you investigate the API response issue today? Context: intermittent failures over the last few days, possibly the caching layer.
The words say one thing; the meaning depends on what the reader assumes. They carry subtext (frustration, correction, a nudge) that isn't actually in the words.
Some styles lean on shared context to carry meaning; others need it stated. Most teams never pick one, so everyone is expected to read the room correctly, every time, with no key.
The tell: The words are neutral, but the message clearly isn't, and you can't say why.
Say the subtext out loud.
I've seen this. I'll make the change by Thursday.
"No rush!" attached to something that is actually blocking. The softener is meant kindly. What it does is break the link between your words and your stakes.
Hospitals know what happens when most alarms turn out not to matter: people stop responding quickly to the ones that do. Your urgency markers work exactly the same way.
The tell: The message plays down the timeline while the work behind it holds something up.
Let the softener match the stakes.
Whenever you get a chance, no rush at all — could you take a look at the staging deploy? 🙏
This one is blocking: staging is down and the release can't go out until it's fixed. Can you pick it up this morning? If you're deep in something else, say so and I'll find someone else.
Three requests packed into one paragraph. One gets answered. The other two look ignored, and the person who missed them gets labelled unresponsive for a problem the formatting created.
A paragraph is processed as one unit, so everything inside it competes for a single slot of attention. A numbered list creates three separate handles instead: three things that can each be ticked off.
The tell: More than one request, and fewer than one list.
One ask per line. Number them.
Hey! Can you take a look at the migration script when you get a sec, also is the pricing page copy final, and did we ever hear back from legal on the DPA?
Three separate things: 1. Migration script: can you review it by Thursday? 2. Pricing copy: is it final? Yes/no is fine. 3. DPA: any word from legal? No action needed if not, just checking.
"Let's circle back." No owner, no date, no condition for closing. You have filed it away. They are still holding it open, because nobody told them they could put it down.
Unfinished tasks sit differently in memory than finished ones, which is why an unresolved thread resurfaces at 11pm. You closed the item socially. They cannot close it at all.
The tell: It ends the conversation without ending the thing the conversation was about.
Close the loop, or name who is holding it.
Good point — let's circle back on this.
Parking this until after launch. I'll re-open it in the Oct 2 planning sync. That's on me. Nothing for you to hold.
One decision spread across a DM, a thread reply and a Jira comment. Knowing what was decided requires having been in three rooms at three different times.
Reassembly is work, and you handed it off without saying so. Switching between tools is not free, and whoever joins next month holds none of the three fragments.
The tell: You cannot answer "where was this decided?" with a single link.
One canonical place. Everything else points at it.
Yeah we're going with option B — see my DM for the reasoning, and I left the numbers on the Jira ticket.
Decision: going with option B. Putting it all in one place: • Lower migration risk • Ships about two weeks sooner • Roughly 8% more expensive, signed off by Dana I'll point the Jira ticket back at this message.
"Do you think we should refactor this?" when the decision is already made. The grammar says open question. The intent says done deal. They spend real effort on an answer nobody wanted.
The wasted answer is the small cost. The real one: people learn to read every question you ask as already decided, so the day you want their judgement, you get agreement.
The tell: You know what you want to happen, and you phrased it as though you did not.
Say it's decided, then ask for the part you actually want.
Do you think we should refactor the payments module this quarter?
Decision made: we're refactoring payments this quarter, so not asking for a yes/no. What I do want from you is where you'd sequence it and what you think breaks first.
A request with no why attached. It arrives with no weight, so it cannot be ranked against anything else on the list. It either jumps the queue or sinks to the bottom.
To place your request, someone has to know what happens if it slips. Without that they are guessing, and ranking is already one of the most expensive things a taxed brain does in a day.
The tell: It says what and when, but never why it outranks the rest of the queue.
Attach the why.
Can you update the onboarding docs?
Can you update the onboarding docs by Friday? Two engineers start Monday and this is the first thing they'll read. If Friday is tight, tell me and I'll cut the scope.
Decided in standup. Never written down. The decision now exists only in the memories of whoever was in the room, awake, and not mid-thought about something else.
Text can be re-read, searched and quoted; speech cannot. The record is lost to everyone who processes better in writing, and blame lands on whoever "didn't know."
The tell: The most reliable copy of the decision is somebody's memory.
Write it where it can be searched.
We already decided this in standup on Tuesday.
Writing up Tuesday's standup decision so it's searchable: we're shipping v2 without SSO. Owner: Priya. Revisit date: Nov 1. Shout if that doesn't match what you remember.
Sort the rows by pattern and count them. What you are looking for isn't a villain. It's a default.
Reading your twenty rows
Threads often carry more than one pattern, which is why these add up to more than twenty.
Sharing it back
Share the patterns, not the anonymised-but-still-obvious quotes. Frame it as "here's what our channel defaults to," never "here's what you did wrong." The moment it reads as a callout, the audit stops being useful.
Running it again
Re-run in a quarter, or whenever the team changes shape: new hires, a new manager, two teams merging with two different cultures. The patterns will move. That's the redesign working.
Run it in one sprint
Day 1
30–45 min
Find the channel. Log the last 20 threads.
Days 2–3
async
Assess each row against the ten patterns. On your own time.
End of week
15 min
Group by pattern. Share back with the channel owner.
Get the audit log
No email. No account. The sheet to fill in, with the whole framework along for the ride.
Twenty numbered rows, ready to fill
All ten patterns, with the tell for each
The shift, and what a good version is made of
Opens in Sheets, Excel or Numbers. Nothing to sign up for.
Coming next
An agent that points the four steps at your channel on a schedule, so the audit keeps running after the sprint you gave it ends.
A weekly pass over one channel
Find, Log, Assess, Group: the four steps on this page, run against your threads on a schedule you set.
The ten patterns flagged in your own messages
Not examples. Your threads, with the pattern named and the rewrite sitting next to it.
One shift a week, not a report
Whatever repeated most, and the single change that clears it. Nothing to read cover to cover.
First access when it opens
The waitlist gets in before it goes public, and helps shape what it flags.
One email when it launches. No sequence, no newsletter, and nothing shared.