How to Explain Technical Work to Editors (2026)

Learning how to explain technical work to editors is mostly about running your explanation in the reverse order of how you built it. An editor wants the decision, the finding, the confidence level and the next step in the first minute; the method, the data pipeline and the code come later, on request. Get that order right and a technical briefing stops feeling like a status report and starts producing a commission.

This is aimed at data journalists, news app developers, graphics and visual journalists, engineers sitting inside a newsroom, and any specialist who hands work to someone who has to decide what runs and what does not. Most of the failures I have seen are not failures of expertise. They are failures of sequencing.

Before the detail, here is the short version. Seven moves, in this order:

1. Name the editorial decision first. Not the finding, not the method: the choice you want the editor to make.
2. Describe the reader’s problem in plain language. Say who is stuck, what it costs them, and what changes if you fix it.
3. Give the finding as one sentence an editor can repeat. If they cannot say it back to a desk editor, it is not finished.
4. Say what you are unsure about, out loud. Error bars, missing data, edge cases. Editors respect a stated limit more than a confident claim.
5. Show the tradeoff, not the preference. Two real options, what each costs, and what you would pick.
6. Show what the finished work looks like. A prototype, an annotated mockup, a before-and-after chart. A picture settles arguments prose starts.
7. End with the handoff. The decision, the next action, the owner, the date you need an answer by, and an invitation to interrogate the method.

What You Need Before You Walk In

Four things. Most briefings that go badly are missing one of them, usually the first.

The editor’s first 90 seconds

An editor arrives with a deadline, a slot to fill, a legal or standards question they are already anticipating, and about ninety seconds of patience. They want four answers: what did you find, why does it matter to our readers, how sure are you, and what do you need from me.

That is the whole job. Method details sit behind those answers like receipts.

A one-sentence takeaway

Write the sentence before the meeting, not during it. It is the sentence the editor will repeat in a budget meeting, in a Slack channel, or to a skeptical colleague. If you cannot write it in under 25 words without a technical term, the story is not framed yet.

The constraint list

Every project has a deadline, a headcount, a legal standard, an accessibility bar, a hosting budget and a set of people who have to sign off. Write them down. Editors are not blockage to route around; they are the person holding the schedule and the risk register, and showing you know the constraints is what earns you a faster yes.

A read on their technical ceiling

Small newsrooms often have one person wearing several hats, including an editor with no data background at all. Ask in advance what level they want. Some editors want the significance test explained; others will stop you at “model” and need to hear about a spreadsheet instead. Guessing wrong is the single most common cause of a briefing that lands in the wrong register.

One framing I find useful: treat yourself as an advocate for the reader rather than an advocate for the content. That matters more than any template, because your job in the room is to make the reader’s situation easy to act on, not to defend your toolchain.

Step-by-Step: How to Explain Technical Work to Editors

Start With the Editorial Decision

Open with the choice, not the work. “I need you to decide whether we ship the interactive on the main site or run it as a standalone page” is a briefing. “I built a pipeline that scrapes the council dataset” is a status report.

Separate decisions that need the editor’s input from details that only need awareness. Usually there are one or two of the first kind, and everything else is context. Saying that out loud saves the meeting: “There is one decision here. The rest is so you can sanity-check me.”

Describe the User Problem in Plain Language

Translate the technical objective into a concrete problem a reader has. Not “our data pipeline is fragile” but “when a councillor changes their register, our numbers are wrong for about a day and we do not know which page is affected.”

Short sentences, familiar nouns, one real example. If the sentence would survive a translation into another language without losing meaning, it is usually clear enough.

Describe the Approach Without the Jargon

Say what the approach does, why it fits this problem, and what the team will build. Not what you used. An editor does not need the tool name to make a decision, but they do need to know whether the result is maintainable after you move on.

Here is the translation table I keep open. The middle column matters most, because that is the question the term triggers in the editor’s head.

Technical term	The question it triggers	Plain-language rewrite
Web scraping	Is this legal, and can we be sued?	We collect the public pages the agency publishes and turn them into a spreadsheet we can sort. The source is public, the collection is automated and slow enough not to disrupt their site.
Machine learning model	Is it a black box, and who do we blame when it is wrong?	The computer learned patterns from past examples and applies them to new records. We can show the examples it was trained on, and we check a sample by hand every week.
Statistically significant	Does that mean it is real or did I get fooled?	The gap is larger than the wiggle we would expect from random variation. It could still vanish with different data, so we will say “likely” rather than “certainly” in the copy.
Confidence interval	How wide is the error bar?	The honest range around our number. If we say 340,000 permit applications, the real figure is somewhere between 310,000 and 380,000, and we should write it that way.
API	Is this a thing that breaks on a holiday?	A public feed the organisation updates automatically. We check it twice a day, and if it goes quiet we have a fallback that runs off a downloaded copy.
Database normalisation	Why is the data model mentioned at all?	We cleaned out duplicate and conflicting records before counting, so one person does not appear twice.
Reproducibility	Can anyone check this?	Anyone on the team can rerun the analysis tomorrow and get the same numbers, because the steps and the source files are saved.
CDN	Will this load for a reader on a train?	The files sit on a network of servers close to the reader, so the page loads quickly outside our own city.

A useful test: if the plain rewrite is boring, keep it. Boring is what you want the translation to be.

Make the Tradeoffs Visible

Give the editor real options, not a preference dressed as a conclusion. Two approaches, what each one costs in time, money, reliability, scope, accessibility and editorial flexibility, and a recommendation with your reasoning attached.

Concrete beats abstract. “Manual tagging takes about 40 hours for a year of records and gets it right roughly 95% of the time; the automated version takes 3 hours and makes mistakes we catch in about 1 in 20 cases” lets an editor weigh accuracy against time, which is the decision they are actually holding.

Note where editorial flexibility sits on the list. A pipeline that publishes automatically is fast, and it is also the one that can put an error on the homepage at 2am with nobody awake to pull it.

Show What the Work Will Look Like

Use whatever makes the idea visible: a prototype, an annotated workflow, a screenshot, a timeline, a side-by-side comparison. Many editors and reporters absorb a concept from a diagram in seconds and from a paragraph in minutes, and a wall-of-text memo is the wrong container for a spatial or comparative idea.

For data work, show the chart, not the chart’s data. For app work, show two screens, including the ugly one. For automation, show the failure path: what the reader sees when the feed goes down.

Visuals are not decoration, but do not let them carry claims you have not made in words. A screenshot of a working prototype is evidence of feasibility, not evidence of accuracy.

Say What You Cannot Say: Explaining Limits to an Editor

This is the step nobody does well, and it is the one that protects you. State the limitations before the editor asks, because the editor will ask, and the answer will be in the copy either way.

Name what the data cannot support: which records were missing, which years are estimates rather than counts, which comparison is weak because one jurisdiction reports differently, how large the margin of error is, and what you would need to raise confidence.

Then separate signal from noise in plain words. If two numbers differ by 3% and the error range is 8%, the honest headline is that we cannot tell them apart. Editors who publish that sentence look more trustworthy than editors who publish the 3%.

One technique that pays off: write a methods note your reader could follow. If your own editor cannot restate the method in plain language, the methods note will be unreadable.

Explain Automation, Scraping and AI Without the Hype

Automated reporting and AI-assisted work make editors nervous for predictable reasons: error, bias, and accountability. Answer those three directly and the nervousness drops.

Say what the system does, what a human checks, and what happens when the system is wrong. “A model drafts the summaries, a reporter edits every one before publication, and we log any correction we issue” is a better answer than any claim about accuracy percentages, because it names the human in the loop.

For scraping, be plain about the source, the rate, the legality and the failure mode. Editors worry less about scraping than they imagine once they know you are not hammering a small server overnight.

Keep a short glossary for your beat. Twenty terms, written on one page and updated quarterly, is enough to stop domain vocabulary leaking into copy in a way that confuses readers.

End With a Clear Handoff

Close by stating four things: the decision you need, the next action if the answer is yes, who owns it, and the date by which you need a response. Then invite the hard questions about the method. Editors are far more willing to interrogate your work once you have explicitly given them permission.

Written down, the handoff is a short memo. Spoken, it is the last thirty seconds of the meeting. Here is the memo I send before any meeting, roughly 150 words, editable:

Decision needed: ship the election results interactive on the main site, or run it standalone.
Finding: Turnout in three precincts fell below 40% for the first time in 12 years; the pattern holds across all three election types we checked.
Confidence: High on the precinct counts, which come from the official file. Lower on the precinct-to-precinct comparison, where two precincts changed reporting boundaries a couple of cycles back.
What we build: A searchable map plus a short narrative, about three weeks of work using the existing template.
What I need from you: A yes or no on placement by Thursday, so we can hold the slot. I can walk you through the boundary issue whenever suits.
What I am not claiming: We cannot explain why turnout fell. The data shows the drop, not the cause.

If the meeting is happening in person, send that memo 24 hours ahead and do not read it aloud. If it is a Slack handoff, cut it to the decision, the finding, the confidence and the date, and put the rest in a linked doc. Passing the same content through too many reviewers tends to dilute it, and a diluted message never gets published.

Common Mistakes

Six failures I see repeatedly, with the correction for each.

Leading with the method

The instinct is to prove you did the work. Instead, open with the decision and the finding, then keep the method available. If the editor wants the pipeline details they will ask, and they will ask sooner if you look confident about what you found.

Burying the uncertainty

Stating limitations late reads as an apology; stating them early reads as rigour. The correction is one short block, three lines, near the top of the memo: what we are confident about, what we are not, what would change our mind.

Translating jargon word for word

Swapping one specialist term for another does nothing. Translate to the reader’s situation, not to a dictionary definition. “The feed is a machine-readable version of the council’s spreadsheet” is still a definition; “the council publishes a spreadsheet we can pull automatically instead of retyping 40 rows every Tuesday” is an explanation.

Offering a preference instead of a tradeoff

“I think the automated version is better” gives an editor nothing to decide with. Give two options, the cost of each in time, money and risk, and a recommendation with reasoning.

Sending a wall of text

Long memos get skimmed and misread. One page, a decision at the top, a chart or mockup in the middle, a limitation block, a date. If the memo runs past a page, the second page is an appendix, not the brief.

Letting an editor flatten a nuanced finding without flagging it

This is the one that causes real trouble. When a careful result gets rewritten into an overstatement, you have a choice: let it run, or flag it. Flag it once, calmly and in writing: “As written this says the policy caused the drop. The data shows the drop alongside the policy, not that one caused the other. Happy to adjust the framing to match the evidence.”

Rethrowing it is not the move; neither is stonewalling the editor’s news judgment. Offer the alternative framing and let them decide, with the record showing you raised it.

A worked example, rewritten three ways

Same finding, three registers. A data desk collected fourteen years of permit volumes from a city’s open dataset.

Too technical: “I ingested the Socrata permit dataset via the API and ran a Mann-Kendall trend test on annual totals, which returned a tau of negative 0.31, significant at p less than 0.05.”

Clear but not decided: “Permit volumes have fallen in most years across the whole record. The decline is real rather than random, but the size of it varies a lot by district.”

Editor-ready: “Building permits have fallen in nearly every year of the data, and the decline is too consistent to be noise. The decision is whether we run it as a service or a one-off analysis, because a falling trend is worth updating.”

The third version is short, it makes a claim a reader could check, and it ends in a decision. That is the target.

Quick tips

• Write the one-sentence takeaway before you write anything else; if it takes 20 minutes, the framing is wrong.
• Ask the editor in advance how deep they want to go, and honour the answer even if it is shallower than you hoped.
• Put a real date on every request, and name what you will do if the date slips.
• Use concrete nouns from the real case: precincts, filers, districts. Abstraction is where nuance goes to die.
• Separate technical review from developmental editing and copy editing. They are different passes, and merging them is how a finding gets flattened.
• Keep a record of the briefing. When a question resurfaces after publication, the memo is your fastest answer.

Frequently Asked Questions

Conclusion

Pick your next briefing and run it in this order: the editorial decision, the reader’s problem, the finding in one repeatable sentence, the tradeoff with its real costs, then the handoff with an owner and a date. Put the limitation block near the top, where it reads as rigour rather than apology.

The craft here is not dumbing things down. It is arranging technical work so the person holding the deadline can act on it in ninety seconds, and keeping enough detail behind you to survive the questions that follow.