Stop CC-ing your SMEs, part 2
Six weeks after we said stop CC-ing your SMEs on every email, here are the patterns that have actually shown up in disciplined teams. The replacement was not a tool — it was a queue.
Six weeks ago we argued that the dominant SME-collaboration pattern in proposal work — CC the engineering lead on every email, hope they read it, escalate to their manager when they do not — is a productivity hole that has been measured and re-measured at 48% of teams’ top complaint for five consecutive years (Qorus). The post said stop. Several readers wrote back with the obvious follow-up: stop and do what.
This is the field-note follow-up. It is not a vendor pitch. It is the pattern we have seen replace CC-driven SME workflows in disciplined teams. The replacement is not a tool. It is a queue.
The pattern
A queue is a single, ordered, named place where an SME finds the proposal questions waiting for their input. Not their inbox. Not a Slack channel. Not a shared folder of Word docs. A queue.
The queue has three properties.
It is the only place. If a request for SME input is not in the queue, it does not exist. This is the rule that makes the queue work. The first time a proposal manager bypasses the queue with “quick favor on Slack,” the queue fails. The second time, the queue is dead. Discipline on the proposal-manager side is the load-bearing part.
Each item has a named writer. The proposal manager has already drafted a starting point — a paragraph from the KB, a prior bid’s answer, a structured set of bullet points the SME is being asked to validate. The SME is reviewing, not authoring. This is the single biggest shift. SMEs do not have time to write proposals. They have time to fix paragraphs that are 70% right.
Each item has a deadline. Not a vague “this week.” A specific date and time, attached to a downstream production gate. “Needed by Tuesday 2 PM for Wednesday’s pink team.” When the SME sees the queue, they see what is at stake if they do not move.
What the queue actually looks like
In the disciplined teams we have observed (across several customers and a few internal beta runs), the queue is one of three things, and the choice does not seem to matter much.
It is a Notion page with a status column. Or it is a Linear project with each SME-review item as a ticket. Or it is the Review tab inside a proposal tool where the SME logs in and sees their assignments. The substrate varies. The shape — single place, drafted starting point, named deadline — does not.
What does seem to matter: the queue is not an email. Email defeats the queue because email also contains everything else the SME’s company is asking them to do. The queue has to be a distinct place the SME visits when they are doing proposal-review work, mentally separate from the rest of their day.
What changed when teams adopted the queue
We have heard four specific patterns hold across the teams that adopted some version of this in the last six weeks.
SMEs respond faster. Not because they are working harder — because the request is sized correctly. A 40-second decision on a pre-drafted paragraph is something an SME can do between meetings. A 30-minute “write a paragraph for me from scratch” request gets pushed to “I will get to it tomorrow,” and tomorrow does not happen until the proposal manager escalates.
Escalation drops. Proposal managers stop having to ping the SME’s manager because the queue has a public deadline. The deadline either gets met or it gets renegotiated explicitly. Either outcome is better than the silent slip that the CC-driven workflow produces.
Reuse goes up. When the proposal manager is required to draft a starting point for every SME review, the most efficient way to do that is to retrieve the closest prior approved answer from the KB. Which means the KB gets exercised on every bid, which means stale content gets flagged on every bid, which means the KB is more current six weeks later than it was at the start.
The proposal manager’s week looks different. Less time in chase mode. More time in capture and review mode. The work moves from “where is Sarah on requirement 4.2” to “is this draft good enough to hand to Sarah for a 40-second decision.”
The CC-driven pattern still has a place
It is not “never CC an SME.” Sometimes the SME needs context only available in a thread of emails. Sometimes a CC is the right way to keep an SME informed without requiring action. The argument is narrower: do not run the SME-input workflow on CC. Do not let CC be the dominant channel for getting information out of the people who hold it.
The queue is the dominant channel. CC is supplemental. Slack is supplemental. Email threads are supplemental. The queue is where the work lives.
What we would tell you to try this week
If your team is currently CC-driven, do not roll out a new tool. Build one queue, one place, with one rule that requests live there. Run it for two bids. The bid’s outcome is not what you are measuring; the SME response time and the number of escalations are.
If those two metrics improve, the queue is doing what it is supposed to. If they do not improve, the queue is just a new place where the same workflow happens, and the substrate was not the problem.
Part 3 of this thread will land sometime in the fall. By then we should have data from a few more teams on whether the queue pattern holds at scale. For now: try the queue. Measure two bids. Report back.