How to Manage a Data Journalism Team in 2026: Practical Guide

Managing a data journalism team means deciding who owns the editorial question, who owns the code, who signs off on the numbers, and what has to be true before a project publishes. It is less about tools than about division of labour, documented decisions and realistic deadlines.

The teams that struggle share the same symptom. One person becomes the bottleneck for every dataset, every chart and every build, the rest of the team learns nothing, and the work either stalls or ships without review. The teams that work have a written workflow, named owners and a standard that any new hire can learn in a week.

What follows is the management system itself: what to set up before the first project, an eight-stage path from pitch to publication, the failure modes to watch for, and the AI rules you will need sooner than you expect. It suits a team of two as much as a graphics team of thirty.

What You Need

Before the first pitch lands, five things need to exist. Most teams start with one or two of them and then spend the first project discovering the gaps.

Named roles with real decision rights

Roles are not job titles. A data editor, a news developer and a visual journalist may all report to the same manager, but they need different authority. Someone has to be able to say the number is wrong and stop publication. Someone else has to be able to say the chart is unreadable and change it. Write down who decides what.

The 30-member international graphics team described in the Journalism in the Data Age chapter is a useful model here. Despite the name, it holds designers and researchers alongside data journalists, which is exactly why the manager’s job is definition rather than headcount.

A place for data, code and decisions

One repository per project, one shared drive, one wiki page. The test is simple: could someone who did not work on the project reproduce the analysis from what is stored there? If the answer is no, you do not have a file problem, you have a management problem.

A provenance record

For every dataset: where it came from, when it was requested, who answered, what the licence permits, what has already been cleaned. Public records data and FOI responses need their request date and delivery date in the same record, because the age of a records response changes what you can claim from it.

A written review standard

What gets checked, by whom, before publication. Two or three sentences is enough to start. Most teams fail here because the standard lives in someone’s head until they leave.

A standing forum for questions

A weekly thirty-minute slot where anyone can bring a blocked project. It sounds trivial. It is also where scope creep gets caught early, which is much cheaper than catching it in the build.

Small newsrooms do all five with almost nothing. A two-person team can combine data editor and visual journalist into one person, keep the repo, and borrow the review step from a colleague outside the unit. Broadcast newsrooms that were late adopters face a similar squeeze; the Solutions Journalism Network playbook makes the same argument, that training or a partner organisation beats staying a late adopter indefinitely.

Step-by-Step: How to Manage a Data Journalism Team from Pitch to Publish

Eight stages, each with an output and a signal that it is finished. The stages matter less than the completion signals, because those are what stop a project from stalling in someone’s inbox.

Hold a kickoff that ends with a shared sentence

Get the editor, reporter, developer and designer in one room for forty-five minutes, or one call if they are distributed. Cover four things: who this is for, what public value it delivers, what question the evidence can answer, and what evidence actually exists right now.

The fifth item is the one people skip. Risks. A source that has not confirmed, a records request still pending, a method the reporter has not tried. Naming risks at kickoff is cheap; discovering them at build time is expensive.

Close by writing one sentence everyone can repeat. If the team cannot agree on that sentence, the pitch is not ready and no amount of downstream process will fix it. Stage complete when the sentence exists and the next action has an owner.

Set a small scope and explicit success criteria

Broad project ideas die from ambition, not from bad data. Force the first release to be small enough to finish: one audience, one core finding, the minimum analysis that supports it, and an explicit list of claims you are not making yet.

Write the deadline and the format in the same document. Interactive or static? Responsive or not? Published with a methodology note or without? These decisions constrain the work far more than the analysis does, and the person building it needs them on day one.

Define useful the same way. Not traffic, not necessarily virality. A defensible definition is whether the piece answers a question readers actually had, and whether you would run it again if the numbers stayed the same.

Assign clear roles and decision rights

Separate five functions even when two people hold two of them: editorial ownership of the question, data and code work, visual and user experience decisions, fact-checking, and coordination.

Then name the tie-breaker for the four disputes that eat weeks: accuracy, design, scope and schedule. The usual failure is a standoff between the assigning editor and the data editor over whether an analytical conclusion is publishable. Settle it in advance, not in week three.

Role	Core responsibility	Typical background	What good looks like
Data editor	Owns the editorial question and the standard of evidence	Reporter or editor with a data state of mind	Turns a vague idea into a bounded question and kills the claim that cannot be supported
News developer	Builds the pipeline, the chart and the page	Software engineer or front-end developer	Work is reproducible from the repository and runs on a phone
Visual journalist	Designs the form: chart choice, annotation, hierarchy	Information designer or illustrator	Rejects a chart that flatters a weak finding, argues for the honest form
Reporter	Finds the story, sources the data, writes the argument	General assignment or investigative reporter	Interviews the data and the people in it, not just the spreadsheet
Audience specialist	Distribution, engagement, follow-up ideas	Audience or product role	Turns reader response into the next pitch instead of a satisfaction metric
Freelance developer	One-off builds and surge capacity	Contract engineer or studio	Works inside your repository and standards, not a folder of their own

That last row deserves a note. Freelancers are where standards quietly disappear. Put contractors inside the same repository, the same naming convention and the same review gate as staff, and write the handover requirement into the contract.

Plan the smallest useful production workflow

Break the project into the tasks that actually happen: data acquisition, cleaning, analysis, reporting, prototyping, build, review. For each, name an owner, note what it depends on, and mark where a review point sits.

Then write the fallback. Every data project has a moment where the data arrives incomplete, malformed or in a format nobody predicted. Decide in advance what gets dropped if that happens. A publishable small finding beats an unpublishable complete one, and the team will make that trade faster if you have already named it.

Create shared naming, file and documentation rules

Agree conventions once and apply them everywhere: source files untouched, cleaned copies named, versions dated, variables described in a data dictionary, charts saved at export size with their annotation text intact.

The documentation minimum is one README per project covering the question, the sources, the method, the known limitations and who to ask. Reproducibility is the practical test: if the reporter is sick for two weeks, can the project continue without them? If the answer is currently no, the documentation is not finished.

Charts deserve special care. A number that only makes sense next to the footnote is a number that will be screenshotted and quoted without the footnote. Assume everything gets lifted.

Build checkpoints instead of relying on a final review

Four gates beat one big review before publication. Pause after scoping, after analysis, after visual design, and after build. Each gate asks the same five questions:

• Is the finding worth the reader’s time, and does the evidence support the claim as written?
• Is the method sound and honest about its limits?
• Can a screen reader or a keyboard user get the finding?
• Does it load fast enough on a mid-range phone?
• Would a colleague read the headline number and get the same impression you did?

Four short gates cost less than one emergency review the night before publication, and they catch problems while they are still cheap.

Test the story, the interface and the claims together

Run one coordinated test session rather than three separate reviews. Recompute the headline numbers from the raw source by hand. Check every label against the underlying table, especially axis labels and units. Test on a phone, on a slow connection, with a screen reader, and look at the social share preview.

Also test the edge cases people ask about: the small group that got identified by a filter, the month with partial data, the category that was renamed mid-series. Decide what the piece says when someone finds it.

If AI tooling is anywhere in the process, the verification rule is non-negotiable: output has to be verified against a primary source by a named human before it enters a draft, and it goes through the same fact-checking as everything else. That is the rule the Deutsche Presse-Agentur settled on, and it is a good default because it does not require your newsroom to have an AI policy committee.

For teams going further with retrieval-augmented systems, the testing bar is higher, not lower. Bloomberg’s responsible AI group ran a 5,000-question safety test on its retrieval system, Verdens Gang tested its FOIA bot against 548 expectations with an automated LLM judge, and the Financial Times waited until 80% of beta testers rated the tool useful before opening it up. Lars Adrian Giske, head of AI at iTromso, put the practical problem plainly: checking large volumes of material by hand is not something one journalist, or even a whole team, can absorb. Build verification time into the schedule rather than assuming speed.

Publish with ownership and a maintenance plan

At publication, four things must exist: the source list, the method note, a description of every chart for readers who cannot see it, and a named owner for updates. Also decide in advance what your correction policy looks like for a wrong number, because it will be different from a wrong quote and people will notice.

Then schedule the follow-up checks: broken links, a source that has been revised, a page that got slow, a reader question that exposes a gap. A published data project is a standing liability unless someone owns it, and plenty of newsrooms have years of unowned pages running.

Use the launch as a source of the next story. Reader questions, follow-up records requests and the questions you could not answer in the first piece are the cheapest pitch list you will ever get.

Common Mistakes

Most data team failures are management failures wearing a technical costume. These seven show up constantly, and each has a straightforward fix.

Overlapping responsibilities

Everyone is responsible, so nobody owns the deadline. The fix is the table above, plus one named owner per project. If two people can both say the project is waiting on them, it is actually waiting on nobody.

Vague assignments

Making something look good is not a task. Replace it with the finding, the format, the deadline and the reviewer. Assignments that cannot be judged as finished are how projects get to ninety percent for three weeks.

Visualising before analysing

Teams love to build the chart first because it is the visible part. It hides the real work, and a beautiful picture of a shaky number is worse than no picture. Fix the analysis and the claim first; design starts after the shape of the finding is known.

Undocumented analysis

The script breaks, the person who built it has moved on, and nobody knows why a filter is in there. Reproducibility and provenance are the fix: the README, the data dictionary, the untouched source files, the version history. Budget an hour for it or it will not happen.

Stakeholders arriving late

Legal, audience, commercial or an outside partner arriving after the build starts means rework. Put a review window into the plan at kickoff, even if the review is small, and let the deadline move instead of the review.

Untested on mobile

A chart tested on a laptop is not a tested chart. Most readers meet your work on a phone, often on mobile data. Test on a real device on a real connection before you call a build finished, and check what the share card looks like while you are there.

Launching with no update owner

The piece launches, interest fades, and six months later someone finds an error. Name an owner at publication, not after the first complaint. A ten-minute monthly check is enough to keep the sources and the code honest.

Frequently Asked Questions

Conclusion

Do one thing this week: hold the kickoff. Write the story goal in one sentence everyone repeats, assign an owner for the editorial question, the data and code, the visual work and the verification, then put the first checkpoint in the calendar before production starts.

Everything above, the workflow, the review gates, the AI rules and the maintenance plan, works better once those four decisions exist. Learn how to manage a data journalism team by running the first stage properly rather than by adding process later, when two projects are already stuck.