Magnus Bjerg is a journalist and digital projects manager at Denmark’s TV 2. As a Knight Fellow at the Massachusetts Institute of Technology, he has been investigating how developers and journalists can better collaborate.
For me, the last year has been a mix of equal parts FOMO and imposter syndrome as I was one of ten Knight Science Journalism Fellows at the best technical university in the world, Massachusetts Institute of Technology.
As a digital journalist from a small editorial development team, it has been a dream come true to spend a year in an intellectual Disneyland like Cambridge, Massachusetts.
One of my goals was to figure out how journalists like myself could work better with software developers, so I audited 12 classes at Harvard and MIT. I went to a couple of conferences and I interviewed 24 brilliant people working at the intersection of journalism and technology.
Here is what I learned:
- Have more and structured communication
- Create psychological safety
- Embrace Agile
- Create diverse teams with shared goals
Journalists need developers
The old business models are not working anymore. The audience is leaving our platforms. Especially local journalism is in a state of emergency that demands action. Alex Schaffert, the chief digital officer at Southern California Public Radio, said: "The most pressing task for journalism is to figure out the business model. You have to convert your digital users into subscribers or donors. And to do that, you have to use technology."
And all the best, most impressive pieces of journalism I have seen over the years have one thing in common, they were the result of close collaborations between people who write syntax and people who write sentences.
"When we get out of our silos we do better work," says Kaeti Hinck, the newly-hired director of visual news at CNN, who was a Nieman Fellow at Harvard when I interviewed her about her experience as assignment editor at The Washington Post where she led a team of journalists, designers and developers who did visual journalism.
“I thought of all of them as journalists. They came from different backgrounds but all of them did journalism.”
But it is hard. People might think digital is easy but numbers from the Standish Group, a research advisory organisation that focuses on software project performance, shows that only 29 per cent of digital projects can be considered successes, as in on time, on budget, and with a satisfactory result.
When you put developers and journalists together, magic can happen. But the friction will also create heat because of the differences in culture. We speak different languages, we use different workflows and we worship different heroes.
How many reporters harbour warm feelings towards the people building their CMS? My guess is very few. I have personally felt the resentment of watching the glacially slow pace of development, and I know that the people 'on the other side of the table have pulled their hair in frustration with editorial not being able to make up their mind and plan.
"We don’t speak the same language at all. The editors don’t know what ‘switching to a new content API’ means. But it’s obvious to the developers," says Coleen O'Lear, editorial director of Emerging News Products at The Washington Post.
Learning to talk to each other will help both the editorial and engineering people to understand both sides of the job and be able to 'think with two minds'.
Have more and more structured communication
"I default to over-communication," says Hinck who used to do a lot of walking between departments while at The Post to strike up casual conversations like "What are you working on?"
Laura Blenkinsop, a multimedia editor for projects at The Globe and Mail in Canada, observed how journalists are used to making edits to their stories right up until deadline whereas developers usually need all content and decisions locked in well before publication to properly build and test.
Most of the teams I spoke to have borrowed models of communication from the software industry.
Daily standup meetings of no more than 10 to 15 minutes keep diverse teams on the same page and allow for quick adjustments and clearings of misunderstanding.
Each person on the team only answers three quick questions: What did you do yesterday? What will you do today? What might block you? On the third question you can add "and where do you need help?".
According to Uli Köppen, head of the data journalism team at German public service broadcaster Bayerischen Rundfunk, it has been the most helpful third question for her team.
If anything needs a longer follow-up you can huddle after the standup meeting or do a longer meeting later. This, of course, is a flexible format. The team I am at TV 2 Denmark only does two weekly standup meetings plus a longer sit down one at the beginning of the week.
Before the project, most recommend putting some kind of plan into writing whether they call it a project manifesto, a design brief, a mission statement, or a product requirements document. It should state what the project tries to solve, what the success is and when you are done.
"It is strenuous to take time to communicate. But in the end, it is worth it. You get a better project and happier people in the team," says Köppen.
After the project, you should always do a post mortem or a retrospective as fast as possible while it is still fresh in memory. The goal is to learn as fast as possible because plenty of things will go wrong. Professor David Eaves who taught a short class on 'Preventing Digital Disasters' at Harvard recommended to always ask 'what did we learn?' not 'what went wrong?'
But simply turning the question around like that can be hard for many journalists that have been taught to always put their finger on the sore spot. And everyone else might not enjoy the way we communicate.
Create psychological safety
"The journalists can be strong and pushy, and people from other areas often don’t have the same training of complete assuredness. It can often mean that their ideas are not heard," says Francesca Panetta, creative director of MIT’s Center for Virtuality. Before that, she was a Nieman Fellow at Harvard and executive editor for VR at The Guardian.
She has hired both developers and designers to work with journalists, and she is not the only one noticing the issue with the way journalists communicate.
The former chief technology officer of the media startup Whereby.us Ernie Hsiung has felt the heat.
"There is a certain kind of direct communication style and delivery that has not meshed well with folks that are not used to communicating that way," he said.
We have to make everyone feel safe enough to speak up. Because it pays off.
Google did a two-year study on more than 180 of their teams and found that psychological safety was by far the most important dynamic that sets apart high-performing teams from the rest.
The following five tips to achieve that are paraphrased from the Google report and the management classes I took this year:
- Let everyone speak
- Endorse curiosity across professions
- Promote healthy debate
- Foster a no-blame culture
- Celebrate intelligent failures
'Intelligent failures' should be well-thought-out forays into unknown territory that just happened to not work out. That is the advice Harvard Business School professor Amy Edmondson gave at MIT’s yearly Fail Event, where they also celebrate fiascoes. Because not all failures are equal.
Embrace Agile
The difference in cultures is another source of friction.
"In tech, if we realise we’ve made a mistake, that’s okay. We just figure out how to iterate as fast as possible and build something better. For editorial it has to be perfect off the bat," says Hsiung.
As journalists, we should take a page from the developers' playbook and embrace the Agile approach. All the teams I interviewed people from adhered at least loosely to the 12 principles behind agile software development.
Three most important are:
- Close collaboration from start to end
- Flexibility, because the plan will change
- Building in increments, not one big bang
This allows software developers to learn as fast as possible. The old way of doing it that seems more comforting to editorial people is the 'waterfall' approach, where all the decisions are made upfront, a detailed plan is drawn and then handed over to the developers that can go their merry way and come back with exactly what we asked for. But nothing ever goes exactly as planned.
Embrace Agile but also be sceptical and ask questions. Be especially wary of statements that begin with "Let’s rebuild this in…" and end with a cool new framework you have never heard of like Elixir or Rust.
It boils down to being a good partner. Kathy Pham who taught me a product management class at Harvard had a long bullet list of how to do this.
She has done product management with Google, IBM and United States Digital Service at the White House. But these four bullets of hers were especially echoed through the interviews with the industry professionals.
- Share why, not what
- Prioritise
- Have the data
- Listen
Create diverse teams with shared goals
Despite a higher potential for friction, diversity of backgrounds, skills, and culture will create more business value.
Developers should be able and allowed to comment on the story and the journalists on the code.
Panetta often had developers read through manuscripts, especially when the journalists were stuck.
"I can’t see why developers can’t have ideas about writing. No. We are working with clever creative people. They are not ‘coders’ they are creative technologists."
Free daily newsletter
If you like our news and feature articles, you can sign up to receive our free daily (Mon-Fri) email newsletter (mobile friendly).