The brief that arrived in whatever shape you liked
The situation
The business teams complained that content took too long to arrive. Underneath the complaint was an assumption: the writers were the constraint.
Requests reached them through two doors. Long-form documentation came in as briefs written however each product contact preferred: sometimes a summary, often fragments, occasionally a link and a hope. Campaign copy and everything else came in through a system intake whose boxes were roughly defined: requesters could stuff long chunks into whichever box would take them.
Both doors delivered the same object: an unstructured slab. A writer had to reconstruct the request before answering it, then hunt for the few facts that actually decided the piece. Downstream, the slab stayed a slab. It was hard to read back on the content system, made translation alignment more intricate, and let proofreading slips through more easily. Each symptom sat with a different team, each team was measured on its own piece, and nobody owned the shape.
The diagnosis
I worked on two processes, and I arrived at them from opposite directions.
The one I chose. I did not start with the worst-performing process. I started with the most expensive one. Long-form documentation consumed more hours per piece than anything else the team made, so a single point of improvement there was worth more. That is where I sent the diagnostic attention, and I did not send myself.
The writer who handled that documentation had been doing it daily for years. Nobody in the building understood it better, including me. So I set the questions rather than the answers. I asked what was actually breaking or had room to streamline; she did the analysis and came back with several candidate fixes; we went through them together and chose which ones to build. My job was to name the target, then read what she brought back with a different set of eyes.
The one that arrived. A peer lead raised that long unbroken blocks of text were making his translators' review unworkable. Once I looked, the cost was not his alone. The same slabs were slowing everyone in the chain, from the business owner reading a draft back on the system to the proofreader checking it before it shipped. The cost ran across the whole chain.
This door had a different disease. Its requests did not arrive tidy: one might be a single line of UI text; the next ran to 3,000 words of terms and conditions. The form treated them almost identically, and a writer opened each submission with little idea of what to expect. The requester knew. The form gave them nowhere to say it.
Nobody needed to write faster. The two doors had two different problems: documentation briefs arrived without the facts that decided a piece, and the general form flattened every kind of request into the same box. The cure had one shape. Both doors had to let people hand over what they already knew, instead of inviting a braindump and paying everyone downstream to organise it.
The mechanism
Two moves, one principle.
The documentation standard. Its owner wrote it, and the work ran into the requesting side rather than stopping at our own door. Requests came in through a template that acted as a guardrail. The business owners marked the talking points themselves, so the facts that decided a piece arrived with the piece. The support team fielding the underlying questions was trained on the new shape, rather than sent a document whose gaps invite assumptions. Its owner also went beyond the original ask and built an onboarding guide, so any writer picking up that documentation could start without close guidance.
The intake architecture. I proposed splitting intake into fields per format. The three of us who managed the flow argued it through, and then I defined the field set for each format. A livestream request, for instance, asked for far more than the script: everything from the fields needed to host a session on YouTube down to the essential details. I did not do that at my desk. I went to the colleagues who handled each type of material most often, sometimes in other departments, because they knew which parts of a request are always present and which are decoration.
Three properties carried both moves, and all three transfer:
Fixed, not suggested. Only the people who already structured their briefs follow a guideline asking them to, so the fields were fixed wherever structure decided the piece: a field that accepts only a headline gets a headline. Not every request needed that. Some needed a UX patch and nothing more.
Designed for the chain, not the writer. The structure that helps a writer is the same structure that lets a business owner read a draft back, lets a proofreader work against a source, and lets a translation be reviewed a paragraph at a time instead of a chapter at a time. One change, paid for four times.
The requester's load is bounded, and it is the part only they can carry. Marking the talking points costs the person who owns the product little and saves everyone else a search. Filling six labelled fields is easier than composing a document. I also stopped short of the finest segmentation the chain would have enjoyed: fields granular enough to be perfect are granular enough to be abandoned. Adoption is a design constraint, not a rollout problem.
What changed
Requests arrived carrying their own structure. Writers started with the deciding facts in hand instead of tracking them down, and work moved through review and translation in segments that could be checked against each other. New product contacts produced usable briefs on their first attempt instead of their third, because the form taught them the format on the way in. Long-form production time came down sharply within two months.
Then it compounded past its own brief. The cut came first. After it, the guide its owner had built became the cornerstone of an onboarding kit for the most intricate part of the work, which demands product knowledge, technical writing and cross-departmental communication at once. A standard written to stop a hunt for facts became the onboarding material.
What transfers
Most quality problems in a content operation are intake problems. When output disappoints, inspect what enters the machine before who works inside it.
Two habits follow. Attack the most expensive process rather than the most visible one, because leverage and noise rarely sit in the same place. When a problem is raised by someone else's team, put it through that same test: what it costs across the chain.
Then find who already knows. The person doing the work daily holds knowledge no outsider's diagnosis will reconstruct, so point them at the target and become their second pair of eyes instead of their author. This is not delegation for capacity. It is the only way the standard ends up better than the one you would have written, and the only way it survives you leaving.
I was not the best writer in that team, and the work did not need me to be. It needed someone "lazy" enough to keep looking for the one point where a small change moved everything downstream.
