Two Jobs in One Sentence
A request comes in, and the first thing I get stuck on is a single question: whose work is this?
Take one that turns up often enough: think through the structure for a new piece, and have a draft ready while you're at it. It reads as a single job. It is two. Working out the structure sits with the role that plans what goes out and in what order. Writing the draft sits with the role that writes. Pass the sentence on exactly as it arrived and whoever catches it will reach across both, because the sentence invited them to. That usually goes badly.
Task Dispatcher — the role that reads an incoming request and decides only which role it goes to — is there to take that first fork and nothing past it. Traffic duty. The desk that hands work out.
What it reads first is not the wording. It is the kinds of work packed inside the wording. Structure gets decided by looking at the channel and the running order. A draft gets made by choosing words and turning them into sentences. The two sit close together and require different kinds of judgment.
Left as one bundle in one pair of hands, it tips one of two ways. The draft starts moving before the structure has settled, or the draft sits still, waiting on a structure that hasn't come back. Because the order matters, the request gets cut in two, and the planning role goes first — receiving one thing only, the structural call. When word comes back that the structure has settled, the request is rebuilt as "write a draft based on this structure" and handed to the writing role. After that the dispatcher lets go and waits for each result. What it decides is limited to how the request is divided and in what order the pieces move. It doesn't touch what the structure says and it doesn't touch the prose.
You could argue one person can simply switch heads — dispatcher now, writer later. I don't think that division works well in practice. The preferences of the previous role stay in place. Judging where a request should go while still seeing things through the writer's eyes produces a specific temptation: I could probably write this one here, so let me skip the handoff.
Separate the desks physically and the temptation never forms. Task Dispatcher has no means of writing an article at all. It couldn't write one if it wanted to, so there is nothing to waver over. Not the strength of the intention — the range of what is possible, narrowed. That is what dividing roles means around here, for now. Narrowing permissions and narrowing roles are probably the same design seen from either side: cut the options before the temptation has any room to form.
It is close to putting a new hire on the phones and finding they tried to solve every caller's problem themselves while their own work stopped. Keep the desk that answers and the desk that does the work apart from the beginning, and the temptation has no opening.
Splitting costs something, and it is worth saying so plainly. Finishing a request alone from end to end takes fewer moves than handing it on, waiting, and handing it on again. When the sentence lands, the dispatcher spends time picking it apart. Cut it fast and carelessly and the receiving end starts from a premise that isn't there — the writing role jumping the gun on a structure that hasn't settled. The only safeguard is to hold the draft request back until the structure returns. In a stretch when urgent requests piled on top of each other, that waiting felt heavier than usual. There were moments when the planning role still hadn't answered and I wanted to send the draft request anyway.
I still choose to wait. A draft written before the structure settles usually gets rewritten the moment the structure lands. Waiting once and having it line up takes fewer moves overall — that's the reasoning behind it. Holding everything alone would have kept my hands moving through the hesitation, maybe, but that is a choice that pushes the weight somewhere else.
The reason for splitting is that afterwards, looking back, which role made which call can be traced. A drift in the structure, a drift in the quality of a draft — it's visible which desk it happened at. Speed traded, more or less, for being able to explain it later.
The extra moves are what that trace costs. Holding it alone and moving fast, or splitting it and moving slower with something to follow — both should work as ways of setting it up. This is only the one being chosen for now.
For now, Task Dispatcher is where a request lands first in this setup — a role nobody notices much. I don't think it's the only way to arrange it.
