10 Lessons from 10 Journalism Hackdays around the World
Hack The Newsroom! #editorslab
5 min readSep 30, 2013
Over the past 10 months, my job at the Global Editors Network gave me the opportunity to be touring the most renowned newsrooms all over the world to organize journalism hackdays where teams of journalists, designers and developers competed in the development of innovative journalism tools, content and apps.
From the New York Times to India Today, via Zeit Online, NOS in Holland, Clarin in Argentina and many others, it’s been an incredible trip to different journalistic cultures. And it’s not over, as I’m just back from 24.com in Cape Town and The Guardian in London, with the next stop at Gruppo L’Espresso next week, and back to Paris at Le Parisien the following week…
I have learnt a lot on journalism, innovation in newsrooms, the media industry and hackdays organization, and I’ll progressively share all that knowledge in a few posts. I’ve thought the best way to begin would be to write a nice and handy LISTICLE, introducing 10 lessons I’ve learnt from more than 10 journalism hackdays around the world:
- Journalism hackdays are not traditional tech hackdays
A lot of media/journalism hackdays I see are direct transpositions of the traditional tech hackdays model: 48h hours of hacking in a warehouse with beer pizza and redbull. This set up is perfect for hardcore developers in need for a coding sprint, but your journalists will quickly end up bored sitting next to the coders. To find the right balance between brainstorming, prototyping, editorial conception and coding, it is important to structure the hackdays, have speakers talk about non tech topics, not too many APIs and tech presentations. - Focus on forming good teams
In traditional hackdays, the teams are formed on the spot. This is great for networking, but to make the most of hackdays it can be very good to ask people to form teams before hand, if possible with people they already work with or could work with in the future: that way, the team can develop and experiment new ways of working, and take this experience back to the newsroom after the event. - Don’t start to code to early
This is a hackdays classic: brainstorm, scribble, sketch, make paper prototypes and mockups before you start to code. It is more important to get the idea right, event if you have the feeeling you are loosing time, than to rush and code a sketchy prototype, and start from scratch 2 hours before the deadline because your idea was shit. - Focus on small and limited problems/challenges > don’t try to reinvent Facebook, don’t relaunch your whole website
Another hackdays classic: focus on a specific and limited problem to solve in 2 days. As much as you can, leave behind all the sophistication and cool new features you would like to add to your project. Otherwise you’ll end up trying to reinvent Facebook, re-launch your whole website, and you’ll fail. - Don’t forget the major objective: to implement your innovation in a media org or newsroom
The major deception after hackdays is to see many great ideas left aside and never implemented by any news organization. This is because these ideas were not so great, as they were not designed thinking about an existing problem to solve, a real need of your publication, something which could actually interest your editor and be implemented. - Do hackdays within newsrooms, not only outside
A lot of hackdays and hackathons, following an “open” philosophy, take place outside organizations, in co-working spaces, events venues or during festivals. These events are great for networking, and to generate synergies and opportunities. But to change the way a news organisation works and innovate, you need to do it from the inside. Hackdays within newsrooms and/or involving several newsrooms are the key. The model of tech companies regularly organising internal hackdays to constantly innovate is a good one to follow. - It’s not only about the demo/prototype
The demo/pitch time is the best of hackays and hackathons. But sometimes, focusing on delivering a working prototype will forbid the team to be innovative enough to find and work on the right idea. The demo is not the ultimate objective, and a good idea can always be developed after the event. That said, a good old failing demo is always good fun. - It’s not all about the outcome
Same as for the demo: it is important to try to win hackdays, and to build the best app possible, but never forget that the simple fact of taking part to hackdays, taking a break from your usual way of working, experiment, brainstorm and build prototypes is the most important. Teams learn a lot that way, about innovation, creation and new ways of working and collaborating. - Innovation is not a question of high tech
The most technology advanced countries and newsrooms I have visited for hackdays have not always been the most innovative. Innovation and success rely more on idea selection and brainstorming, time management, project management skills within theteams. Finding the right balance between editorial content, design and code is not easy, and it’s the most valuable skill to innovate well and quickly. - The News app developer is queen/king
All the above said a new breed of newsroom animal is reigning on the new media jungle: the News App developer. A mix of project manager, developer and journalist, quite rare, and very effective in hackathons. But don’t be mistaken: they are more coders than journos. Journos, don’t try to be a News App Dev; find one, and form a team together.
Note: this listicle is just a listicle, not a manifesto on the future of the media industry or journalism. Feel free to comment and add something to the list.
