Photo by Graham Holliday/Flickr
As storytelling evolves on the Web, media and technology industries are overlapping more than ever before. People from each field are learning more about what there is to know and adapt to by working together within organizations and networking at events, hackathons and workshops.
Media hackathons are perfect models of experimentation to learn from, especially when the organizers strive to include people with different skills. The best ones have enough structure to give people ideas coming into groups and set expectations of collaboration, listening and learning. The not-so-good ones throw attendees to the wind with too many possibilities and vague goals. One challenge for most is thinking of project ideas that need more than developers to get it done, and providing opportunities for people from different background to see how others work.
The path to collaboration in any newsroom is unclear without process and goals. Thinking of these questions and answering them while planning how to organize work in newsrooms will help keep the big picture in mind when working with different teams to tell stories.
What kind of space do we want to build so people can pitch ideas?
Each editorial team has a place where ideas are pitched. It could be through back-and-forth emails with editors. Where there are several editors, there could be a shared editorial calendar where vetted pieces are scheduled to publish. For technical projects, it’s best to start with lots of encouragement, since not all people are familiar with collaborating on this kind of work. Consider using a Trello board or an open-access task management tool to pitch and give constructive feedback on ideas, and product managers and editors can work together to create a backlog of small project ideas that can be revised or universally applied to different topics.
What kinds of expectations should we assign to everyone?
To make things easier, set guidelines and a level of expectations to working together. The Recurse Center (formerly known as Hacker School) created an excellent code of conduct rule: when someone doesn’t know what you know, never act surprised that they don’t have the same knowledge. This also gives you the right to expect that no one treats you like that when you’re learning something new. It also creates a better environment to say “I don’t know the answer to that question yet” or to ask basic questions.
A standard of communication is needed, too. Though some parts of the project require solitary or heads-down work, everyone working together should be accessible and walk others through what their thought process is on their work. Support is necessarily baked into everyone’s role; asking for help or clarification is a given.
What are skills we need besides design, editorial and development, and who can play these skills?
In any designated space where people with different skill sets work together, there are a handful of roles that come into play besides designer, developer, multimedia producer and writer.
A project manager can organize the work going on for all cross-functional teams, set deliverables and keep everyone on track for deadlines.
A technical editor can vet story pitches and help edit those ideas into something that can be done by a small team of people.
A QA tester should, just like an editor, be able to see projects before they publish live to make sure they work and display as needed.
A note taker and reviewer can be the designated tracker of each individual project; taking notes and drawing ideas on whiteboards, then asking questions to clarify the project’s goals, what the work entails and what success looks like for the idea.
What does success look like for the projects we work on together?
Do we want to learn each other’s names and open a line of communication? Intangible and informal relationship building can be the best part of working with new people and is completely worth the time; it opens everyone’s eyes to how other people work in the same field and think about the same stories. There can also be tangible expectations, such as teaching engineers about design thinking or writers learning about interactive code.
Where should we start?
Start with lots of little ideas: charts, graphs, maps, data visualizations, a different way to design story layouts, quizzes, or a piece that you might have seen somewhere else that looked interesting. The killer of experimentation is perfection; you cannot learn much if you come with only one idea that you have your heart set on. Technical projects can be pitched just like traditional editorial ones; think of different angles to the story you want to tell, and these supplementary tools simply help show those angles in new ways. By talking through the process of reporting the story or putting the copy together with developers, designers and multimedia producers, writers can get feedback on how others would approach the same production of that piece and come away with new ways of thinking for future stories.
