A client engagement runs on several email threads, and that’s how it should be. The trouble starts when a fact settles somewhere out of reach of the person who needs it. Nobody ever decided that should happen. Every one of those threads was a sensible email at the moment it was sent.
- A silo isn’t more than one thread. It’s one group holding something another group needs, in a place the second group can’t look.
- Almost every silo forms the moment a thread starts. The recipient list is the whole decision, and it gets made in about four seconds.
- Threads split, merge and change membership right through an engagement. Each of those moves has a correct version and a damaging one, and the damaging ones are usually political rather than technical.
- Being the only person who’s read all of it feels like being indispensable. It’s where this subject quietly leads, and it’s worth avoiding on purpose.
Where the threads come from
Here’s the ordinary version, with everybody behaving sensibly throughout.
The kickoff goes to everyone. The sponsor who signed, the operations lead who owns the process, the finance contact, and your own colleague. Two days later the operations lead replies to you alone. Her question is about shift patterns, and she’d rather keep it off the sponsor’s screen. That’s thread two, and she was being considerate. You write to the finance contact about the purchase order, separately, because invoicing concerns the two of you. Thread three. The sponsor forwards your first update to their own director, with a line at the top you never see. The director asks a question, and the sponsor answers on your behalf. Thread four. You’re off it, and you’ll never know it existed. Somebody composes a new message rather than replying, subject line Quick question, about the pilot. Thread five. You and your colleague have an internal thread about the account. Thread six.
Six threads, four weeks in, and every one of them was reasonable.
The cost shows up later, in four fairly predictable shapes.
The same question gets two answers. You told the operations lead the pilot runs on one site. The sponsor heard three, in a conversation the operations lead never saw. Both statements were right when they were made. It surfaces the day somebody books the second site.
A decision lands away from the person who has to act. The sponsor agrees to something. The person who has to do it is on a different thread. Three weeks pass. You read it as the client being slow. The client reads it as you being slow.
The record gets hard to reconstruct. A disagreement comes up about what was agreed. The sentence that settles it sits in a thread whose subject line is about a purchase order. Finding it costs you an unbilled afternoon.
You become the only integration point. Six threads, one person who’s read all six. Everything routes through your attention. That’s fine on a good week and expensive on a bad one.
Hold on to one distinction. There’s separation you chose, and separation that accumulated. Keeping commercial terms off the working thread is a decision. Keeping the delivery date off it, because the date came up in a call with finance, is an accident wearing the same clothes. The first is organization. The second is a silo. The only difference between them is whether anybody meant it.
So the fix is a deliberate list, thread by thread. Putting everybody on everything produces its own failure, where eight people receive forty messages that concern two of them and stop reading any of it. Thread discipline can’t help there, because the problem is total volume. How much mail a client can absorb before they stop opening it is its own question, and this collection deals with it separately.
Who belongs on this one
Three questions, in this order, before you type a single name.
Who has to do something because of this? They go in the To line, and one name is the target. A To line with four names in it has asked nobody. Each of the four sees the other three and reasonably assumes it’s covered. When two people genuinely have to act, name them in the first sentence with what each one owes. Priya, the depot list by Friday. Marco, confirmation the export runs nightly.
Who is accountable and would be embarrassed to find this out later? They go in copy. It’s a smaller group than instinct suggests. It’s the sponsor, rather than the sponsor’s whole function.
Everybody else waits for the update. They hear it in the periodic update, which exists precisely so that individual threads can stay small.
Under time pressure most people run these questions backwards. You start from who might conceivably be interested, work downwards, and end up with nine names. By then the To line means nothing, and the thread has taught everybody to ignore it from its first message.
That third question rests on something. A thread stays narrow when the wider group has a reliable place to find out what happened, and for most engagements that’s a regular written update. Where one is missing, every thread becomes a broadcast, because it’s everyone’s only chance of hearing anything. Whether your updates actually get read is a real and separate question, and this collection has a piece on it.
One habit is worth the two seconds. Before you send, read your own recipient list and ask what each name is there to do. When the honest answer is that it seemed polite, take them off. Politeness is a way of writing rather than a job on a thread, and the names you add for it are the ones who eventually stop reading you.
One thread per decision
The instinct is a thread per relationship. My thread with Jane, my thread with the finance team. That’s how mail feels from the inside, and it’s the single most reliable way to manufacture silos. The subject then lives wherever the relationship first raised it, rather than where it belongs.
A thread is about a thing. One decision, one deliverable, one problem. It runs from the question to the answer, and everybody who touches that thing is on it.
Name it for the thing, and name it early. Pilot scope: one site or three. Depot cutover date. You’ll find those in eleven months. Catch-up, Notes, Following on and RE: RE: FW: disappear, and so does a subject line that names the meeting rather than the matter. A year later you remember the argument, and the Tuesday is gone.
Put the engagement or client name in it when you run more than one. Three clients each have a kickoff, an invoice query and a scope note. Search tells them apart once you tell it which is which.
Split when the subject genuinely changes, and say that you are. Split the invoicing question out of the pilot thread. One line at the top of the new one takes a moment and keeps both threads readable. A sixty message thread that’s quietly become three subjects is its own kind of silo. Everything in it is visible and nothing in it is findable, which for practical purposes is the same as hidden.
Let a dead thread stay dead, however convenient its recipient list. Replying to a two month old message to reach a handy distribution list is how a decision about the pilot ends up filed under an invoice query. People do it constantly.
Here’s the quick test. Can you write the subject line as a noun phrase naming exactly one thing? If it takes an and, you have two threads.
There’s a limit to all of this. Threads split for human reasons as well as topical ones. A client who wants to ask you something away from their colleagues will carry on doing that, whatever you organize. Let them. Just make sure what comes out of it travels back.
What the copy list says
People read the copy line as a statement about the situation. Almost everybody underestimates how strongly.
Adding a senior name mid thread reads as escalation. Whatever you meant by it. Sometimes escalation is exactly right, and then do it deliberately. The rest of the time, say why in the first line, before anybody decides for themselves. Adding Priya for the budget figure only, no action needed from the rest.
Copying somebody’s manager on a chase is the most common accidental insult in client email. You’re three requests deep and out of patience, so you add their boss. The message that arrives reads as I have reported you, whatever your words say. Do it once and the working relationship is different afterwards. When the chase genuinely needs weight, the honest move is to tell the person first that you’re going to raise it, then raise it.
Copying your own colleague reads as putting something on the record. Usually fine, occasionally awkward, and worth one clause of explanation when the subject is at all sensitive.
Keep blind copy out of covert use on a client thread. The test is simple, and it’s practical rather than moral. If being found out would embarrass you, it’s the wrong tool, and you will be found out eventually, because somebody eventually replies to all. The one clean use is the announced kind, where you tell a thread you’re moving people to blind copy so the closing exchange leaves eight inboxes alone.
The reply-all question settles itself once you see it this way. Reply-all takes the blame. The cause is a list that was wrong when the thread began, and every reply after that inherits the mistake. Fix the To line and reply-all becomes the behavior you want, because it’s what keeps a thread whole.
Adding and removing people
Membership changes throughout an engagement. These two moves cause more damage than anything else in this guide.
Adding somebody hands them everything above. The actual text, including the message where you called the previous project manager’s handover thin, and the exchange about your day rate. It’s the most common accidental disclosure in consulting email. It happens because the add takes one keystroke, and reading forty messages backwards takes twenty minutes.
So before you add anybody to a live thread, scroll to the top and read it as them. One line in there you’d hesitate to send that person today is enough to stop. Forward what’s relevant instead, or better, do the thing that’s usually right anyway.
Summarize and restart. A new thread, a clean subject line, and three lines saying where the matter stands. That’s worth more to a newcomer than an archive they’ll skim past. It also gives everybody a properly named thread, which the old one probably lacked. Keep the old thread for the history, and write in the new one.
When you do add somebody to an existing thread, put one line at the top. Who they are, why they’re here now, and what you need from them. Otherwise they have to reverse engineer their own role out of forty messages, and most people simply won’t. You’ve added a name, and that line is what turns them into a participant.
Removing people has a short rule of its own. Say it out loud. Dropping Marco, this is just the finance detail now. People notice being removed from threads and read it as exclusion, and that one line settles it. Moving somebody to blind copy on the closing message is the polite version of the same thing, and it’s well understood.
One move matters more than the rest. When the client takes somebody off a thread, leave them off. That’s a decision about their own organization, and it’s theirs to make, however obvious it looks that the removed person needs to know. When you think they do, say so to the person who removed them. Adding somebody back into a conversation their colleague excluded them from is remembered for a long time, and it’s difficult to explain afterwards.
One more, because it arrives with no warning. Your day to day contact leaves, and every live thread addressed to them becomes unreachable. The handover inside the client is usually thinner than anybody admits. Ask for the successor to be added to the threads that are still running. Re-send the two or three that matter as new threads, with a short position at the top. Assume nothing was passed on, because it generally wasn’t.
When a thread forks
The commonest fork is small and looks like ordinary mail. You send to five people, and one of them replies to you alone. Half the time it’s deliberate, half the time it’s the reply button. Your first job is working out which.
When the content is ordinary, put it back where it belongs. Bringing everyone back in, and then the substance. People take that in their stride when what comes back is a fact about shift patterns.
When it looks deliberate, leave it where it is. Somebody who dropped four names on purpose wanted a private word, and re-broadcasting it is the fastest way to stop being told things. Answer them where they wrote to you. Then ask, in one sentence: happy for me to put the timing point back to the group, or would you rather raise it yourself? That question settles nearly all of these, and asking is free.
The general form of the rule is worth stating on its own. Ask before you move somebody’s words from a private thread into a group thread. That covers the substance, a paraphrase, and above all a quote. Inside a client organization, the people who tell you what’s really happening stop the moment they see their private remark appear in front of eight colleagues. That one is permanent.
The opposite mistake happens too, and it’s worse. You reply to everyone when you meant to reply to one, and the candid line about the operations lead is now in front of the operations lead. Leave the list alone. A follow-up apology to everybody sends the twelve people who’d skipped it back to read it properly. Deal with it directly and privately with the person affected, that day, and by telephone.
Merging two threads that are about the same thing is easier than it looks, and it’s worth doing early. Pick the one with the better subject line and the fuller list. Paste the essential content of the other into it. Post a single line in the one you’re closing, saying the conversation continues in the other thread. Then actually stop writing in it. Two live threads about one decision eventually produce two different answers, and it’s always at the worst possible moment.
The conversation on the side
Side channels are fine. Several kinds are completely legitimate, and you should use them.
Detail that would waste six people’s attention belongs in a two person exchange. A junior person should be able to ask something away from their director’s eye, and the fact that they do is worth protecting. Your own team’s internal thread is yours. Commercial and personnel matters belong somewhere with a settled membership, rather than on a working thread whose list can change.
One kind corrodes, and it’s easy to recognize. A stakeholder starts using you as a back channel against a colleague. The signals are consistent. Between us. Don’t mention this to Alan. A description of a peer’s failings, and an invitation to agree. You can listen, and listening is often the right thing to do. Stop at becoming an instrument. The moment you’re one, everybody else in the organization eventually works it out, and you’re the last to know they have. Take the substance, decline the alliance, and steer the issue back to somewhere it can actually be resolved. That’s worth raising when we’re all on the call on Thursday, do you want to put it, or shall I raise it as an open question?
One sentence keeps legitimate side channels from turning into silos, and it’s the most useful habit in this guide.
The outcome rejoins the main thread, even when the conversation stays where it is. Confirmed with Jane that the depot closes at four, putting it here so it’s on the record. That single line turns a private exchange into a shared fact, and it leaves the exchange itself private. It takes about eight seconds. An engagement where this happens by reflex stays clear of silos, whatever its thread count.
The corollary is the old one, and it’s still true. Write in a side thread the way you’d write in the main one. Thread membership changes, mail gets forwarded, and the private conversation is one careless add away from being the public one.
The threads you are not on
Most of the email about your engagement is invisible to you. The client’s internal threads are where the actual decisions get made, and your carefully constructed message is one input into a conversation you’ll never read.
That’s permanent, and it’s survivable. What you can do is design for it.
Ask, once, how this organization decides. At kickoff, in plain words: when something like this gets agreed here, who has to have seen it before it’s real? An hour spent on that question saves weeks. Almost nobody asks it, because it feels like an odd thing to ask.
Give your contact something they can paste. They have to represent your position in a room you’re absent from, using a thread that stays closed to you. A position that takes three paragraphs and a caveat gets pasted as their summary, and their summary is what the organization decides on. Write one sentence somewhere in every substantial message that could stand alone as the position. Making any message survive being forwarded to a stranger is a craft in itself, and this collection covers it elsewhere.
Watch for the tells that an internal thread has diverged from yours. A question that assumes something you never said. A decision that arrives with no visible discussion in front of it. A new name appearing on a reply, with no introduction. A phrase you’re hearing for the first time, which usually means it came from a colleague rather than from you. Each one is ordinary on its own. Together they mean a conversation happened elsewhere and reached somewhere different.
When you see one, skip the demand for inclusion. Put your understanding back on the table in writing, plainly, so that the divergence has something to collide with while it’s still small.
The only person who has read it all
Left alone, this is where the whole subject ends up. Six threads, and one person with the full picture, holding it in their head.
It feels like value. An experienced client reads it as a risk, and they’re right. You’re away for two days and four decisions wait. You leave the firm and the account is stranded. A colleague joins the project and takes three weeks to become useful, because what they need to learn lives in your head rather than on a page.
Three repairs, all of them light.
Keep the open items somewhere other than your memory. A running list of what’s outstanding, who owes it, and since when. What it lives in barely matters. What matters enormously is that it sits outside your head.
One thread per decision, as above. The real payoff for that discipline arrives later. Somebody who was absent reconstructs a decision in ten minutes rather than a day.
Write a position down periodically, for a cold reader. Write it for somebody seeing the engagement for the first time, because that’s who will actually need it.
Then the specific case: going away. Tell the client in advance who covers and how to reach them. Hand over the open items in writing rather than in a handover call. And remember that a colleague added to live threads inherits everything above them in those threads, which is the disclosure problem from earlier arriving at the worst moment. Adding a colleague to one clean thread with a summary at the top is a much better week for everybody than adding them to six old ones. Covering for a colleague while you both keep track is a subject the two person firm series takes on properly, and who is holding what is the part of it that matters here.
When the thread is the wrong place
Email is a good container for some of this and a poor one for the rest. A lot of thread management is really an argument about a decision that belonged somewhere else.
A decision with three positions in the room. Email turns that into parallel monologues, each written before the previous one was read, and thirty messages later everybody is where they started. Twenty minutes on a call, and one paragraph written afterwards, settles it. The paragraph is the part people skip, and it’s the part that matters.
Anything that needs one current version. Status against a plan, the open items list, a document being edited by three people. Email holds events. It tells you what changed on Tuesday, and where things stand is a different question. Every attempt to make a thread answer the second one produces a thread nobody can read. Put the state in a shared document, and let the mail carry the pointer and the change.
Where the client already runs the project somewhere else. When the work lives in their project tool or their chat, your email thread is a second record competing with the official one, and it will lose. Work in theirs, and keep email for the things that have to be durable and addressable later: commercial matters, sign-offs, anything you might have to produce in a year.
A conversation that has migrated to chat. This is the most common modern silo, and it costs more than two email threads do. The two systems search separately, so half of your engagement now sits outside the record you keep. Decide out loud which one is the record. And when you’re going to have both, they at least want to arrive in the same place, which is what one feed for mail and chat is for.
Anything sensitive to one party. Rates, personnel, poor performance from somebody’s team. Those go somewhere with a membership you control, rather than on a thread anybody with the send button can change.
And the honest one. When you’re managing nine threads because you’re sending far too much mail, the routing advice above leaves the problem where it is. The volume is the thing to fix, and that question is taken up properly elsewhere in this collection.
The part of this a tool can take
Every judgment above is yours. Who should see what. Which side conversation to protect. Whether a copied name reads as support or as escalation. When to stop typing and telephone somebody. That’s the work itself, and software stays out of it. What software changes is how much you’re holding in your head while you decide, because most of the failures in this guide are failures of recall rather than of judgment.
Knowing what a given thread already contains is the first of those. People add somebody to a forty message chain unread, because reading it costs twenty minutes they’d have to find. In Point every conversation carries a plain account of itself, and a long chain opens at the point it has reached rather than at the top, so what’s actually in this thread takes a moment rather than an afternoon. Six threads across one client become a few minutes of skimming rather than an evening, and which thread said what has an answer you can read.
Finding which of the six holds the thing you half remember is the other half. Point takes a search in ordinary words, so the depot cutover decision is reachable through whatever you happen to recall of it, rather than through a guess at the words somebody put in a subject line eleven months ago. That’s the mechanical part of one thread per decision, and it’s the part people give up on first.
Promises are the third. A thread with five people on it generates commitments in both directions, and the ones that go missing are almost always made in a thread you’d set aside that week. When a message commits somebody to something, it comes back as a dated item, and your memory of which thread it was in stays out of it. The same holds for what you asked of them, with the date of the asking still attached. That register is also the open items list from the previous section, sitting in the one place you’re certain to look. A quiet thread and a finished thread look alike, and threads nobody has answered come back before they go cold rather than after.
The sponsor’s one reply in a week of ninety messages is a triage problem more than a threading one, and marking who actually matters is the cheap fix for it.
Four limits belong here plainly, rather than in a footnote.
Point leaves who belongs on a thread to you. Point holds no map of your client’s organization, no view on whether copying somebody’s director reads as support or as escalation, and no way to know that the operations lead and the sponsor heard different things. Routing is the judgment, and the judgment is the guide.
Point sees your own mailbox, so the threads you are not on stay out of view. The client’s internal conversation remains exactly as invisible as it was, and everything in this category leaves it that way.
Undo covers what Point did, and it stops at the edge of your own mailbox. A message that has already arrived at the far end is beyond any mail client, which bites harder in this subject than in most. The characteristic mistake here is a recipient list mistake, and that’s exactly the kind you’d want back. Each type of action has its own setting for how much Point does unaided, and review is where they begin. A thread carrying several of a client’s people is a good candidate for leaving at review permanently. What that setting actually controls is worth ten minutes before you touch it.
And Point is a layer over your own mailbox rather than a shared one. Three colleagues working the same client inbox together, with assignment and internal comments, is a shared inbox product and a different category, and the comparison with Front sets out where the line falls. The separation Point does offer is between businesses you operate rather than between your clients, which running two businesses from one inbox explains, and it’s worth knowing that before you hope for the other thing.
A multi stakeholder thread is made largely of things people said in confidence about each other. Where that material is permitted to travel deserves a deliberate answer rather than a default one. What to ask a vendor before any of it goes near a model has a guide of its own.
You keep your address through all of this. Point sits on the Gmail or Microsoft account you already use, and every one of those six threads stays where it is. Every capability is listed on benefits, the version of this written for advisory firms sits at Point for consultants, and Point itself is the place to start.
Common questions
How many email threads should one client engagement have?
As many as there are live subjects, which for a normal engagement runs somewhere between three and eight. The number itself is worth little of your attention. What matters is that each thread is about one identifiable matter, has a subject line that names it, and carries everybody who acts on it. A single thread for the whole engagement fails as soon as it passes about thirty messages, because finding anything in it becomes impossible. Twenty threads fail because the same subject appears in four of them and they disagree. If you want one number to watch, watch how many threads are live on the same decision. That answer should always be one.
Should I copy everyone on everything to avoid silos?
No, and it’s the most common overcorrection. Copying everybody trains the whole group to stop reading, and an unread thread is a more complete silo than one they were never on, because everyone believes they were informed. The working alternative is a narrow thread for each matter, plus a regular update that catches the wider group up. That combination keeps your recipient lists honest and keeps everybody in the picture. Put people in the To line when they have to act, in copy when they’re accountable and would be embarrassed to learn it late, and leave everybody else to the update.
A client contact replied to me only and dropped the group. What should I do?
Work out first whether it was the reply button or a decision. When the content is ordinary and factual, put it back into the group thread with a line saying you’re doing so, and people take it in their stride. When it reads at all like a private word, answer where they wrote, and ask whether they’d like the point raised with the group, and by whom. Ask before you move somebody’s private words into a group thread, even when the content seems harmless to you, because you’re the one person on the thread who has to guess how it lands inside their organization.
How do I add a new stakeholder to a long email thread?
Assume that adding them shows them every message above. Then read the thread from the top as if you were them, before you do it. A single line you’d hesitate to send that person today is your answer. In most cases the better move is a new thread rather than the old one, with a clean subject line and three lines saying where things stand, which is more useful to a newcomer than an archive they’ll skim past anyway. When you do add them to the existing thread, put one line at the top saying who they are, why now, and what you need from them.
Is it rude to remove someone from an email thread?
Removing somebody is fine and often correct. Doing it silently is what causes the trouble, because people notice and read it as exclusion. One clause is enough. Dropping Marco, this is only the invoicing detail now. Moving people to blind copy on a closing message is the well understood version of the same courtesy. Be careful with one removal only, and that’s somebody else’s. When the client takes a colleague off a thread, leave them off. That’s a decision about their organization rather than about your email, and reversing it publicly is remembered.
How do I stop being the only person who knows what is going on?
Get three things out of your head and into writing. A list of what’s outstanding and who owes it. One thread per decision, so that somebody who was absent can reconstruct any of them. A periodic statement of position, written for a reader with no history. That combination is also what makes going on vacation possible, because the handover becomes a document rather than a two hour call. Do it before you need it, because the moment you need it is the moment you’re away.
The short version
A consulting engagement runs on several email threads and always will. A silo is a fact that lives where the people who need it can’t see it, and almost every one of them is created at the moment a thread is started. Decide the recipient list deliberately. The To line is for whoever has to act, and it usually holds one name. Copy is for whoever is accountable and would be embarrassed to hear it late. Everybody else gets the periodic update, which is the thing that lets individual threads stay small. Keep one thread per decision rather than one per relationship. Name it for the matter rather than the meeting. Split when the subject changes, and merge the moment two threads start covering the same ground. Treat the copy line as a statement rather than a distribution list, because adding a senior name mid thread reads as escalation whatever you intended. Before adding anybody to a long thread, read it from the top as them, and in most cases summarize and restart instead. Announce removals, and leave the client’s own alone. When somebody forks a thread privately, find out whether they meant to, and ask before their words go back to the group. Let side conversations happen, and send the outcome back to the main thread in one sentence while the conversation stays where it is. Assume the client’s internal threads exist, that you’ll never read them, and that what gets pasted into them is one sentence of yours, so make sure there’s one worth pasting. And make sure the whole picture lives somewhere besides your own head, because the alternative is the failure this whole subject is heading for. The status update that keeps the wider group out of the dark, the recap after a meeting, the scope conversation and the question of how much mail is too much are each taken up separately in this collection.