By Rachel Schallom
We work together very well, thank you, next question. (Etolane)
Deep dives on project management, process, workflow, newsroom culture & more
When I started the interactive team at the Sun Sentinel in 2013, I thought the biggest challenge would be the code. I was wrong. Experimentation, no matter the size, requires creating new processes and collaborating in new ways. For the next two years, I worked closely with reporters and editors to plan, shape and create interactive journalism, retooling the already fantastic journalism coming out of the newsroom to reach audiences in a sophisticated way online. Most of the time we were successful; occasionally it didn’t work out. The biggest thing I learned was that getting things done in a newsroom only works when everyone is on the same team.
It wasn’t always easy. When you need someone on your side, but they don’t speak the same tech language, it can be very difficult. Investing (not necessarily financially, but emotionally and mentally) in creating a space where teams can work better together is key. Here are some strategies for overcoming the language barrier to make collaboration smoother.
When Brainstorming and Pitching
Face-to-face matters. A lot of people ask how to get pitches from reporters. It’s all about face-to-face conversations. I'm not a fan of asking people to fill out a form, similar to a photo request, because that’s not conducive to building creative, collaborative relationships. Instead, I encourage people to come over and talk with the interactive team. If it’s just going to be five minutes, sure, stop by my desk. If it’ll be longer, throw a meeting request on my calendar. Face-to-face conversations make it easier to understand the goal of the interactive, which means we can figure out the best approach efficiently, and we can set reasonable expectations for working together. We also avoid emails when brainstorming projects because so much can get lost. Instead we bring all stakeholders into one room.
Avoid assumptions about skill levels. Don’t make assumptions about what others know about technology, especially young people. Just because coworkers are young does not mean they know the ins and outs of the latest innovations. Age has nothing to do with digital literacy. I once made a joke about developing for IE8 to a group of twentysomethings, and it totally fell on deaf ears.
Teach along the way. When you want to get colleagues onboard with a new approach or open source tool, find common ground by using familiar analogies. When I’m collaborating with someone on a new tool, I always ask myself: What do they already do on the internet? Maybe your new photo library is “as easy as uploading photos to Facebook” or an interface is “similar to paying a bill through the local cable company.”
Jargon is a problem for every industry, but talking about technology can be especially daunting. I try to teach jargon whenever possible. In my last month at the Sun Sentinel, we launched a contest to get ideas for a new 404 page (in my biased opinion, the Sun Sentinel now has the cutest 404 page), which gave me the opportunity to teach what a 404 page is. Look for opportunities that can be educational without being condescending.
While Working on the Project
Stop and check for understanding. When you need group input or approval from top editors, conversations can easily become one-sided. You need to explain so much, so quickly, to meet a deadline. But make sure to pause for checkpoints during the conversation. You don’t want to make it through your whole spiel and then say, “That makes sense, right?” Stop often and give breathing room for questions.
Agree on common names and terms. Figure out what you are going to call things. I once went around and around on whether we should change a menu to a hamburger icon, and it wasn’t until an hour into the email exchange that I realized: not everyone knew what a hamburger icon was. Outline common terms in advance, and use screenshots whenever possible.
Help people give better feedback. About 36–48 hours before publication of a big project, the Sun Sentinel has a process where the interactive team sends the finished digital link to the team for feedback. In the beginning, though, I wasn’t getting the right kind of feedback. People were finding things like broken links only after we’d already launched. I learned that, when previewing projects, they were only reading the text itself, as though proofing a printed page. Now I send a list of things to look for: click links, try to share on social, see how it looks on your phone, etc. This is a great post on helping your client/team/boss give feedback.
After Publication
Document the madness. There are two sets of feelings after publishing a long-term project: This is awesome, and I can’t want to read all the nice things people say about it—or, I never want to look at this again. Either way, it’s natural to want to move on quickly. But it’s important to remember the challenges along the way so you can refine the process for next time. What worked? What didn’t? What other approaches could have worked better? What would have made this faster or easier?
This is what I do: During the project, I write notes to myself while I’m still mad. Remember everyone who didn’t make deadline and every two-hour meeting that was a waste of time. As time goes on, you start to forgive, and you usually like the project that came out of it, but that doesn’t do us any good. You need to remember the challenges. I then sleep on it for a couple of days, and write an email to just my editor outlining my postmortem notes.
Every Step of the Way, Prioritize Patience
None of this works without patience. If you had asked me two years ago what the most important qualities in a developer were, patience would not have made the list. I now know it’s incredibly important, but it’s not easy.
Newsrooms are famously full of diverse personalities and egos. Collaboration and communication can be incredibly frustrating because so many of us are super passionate, and experimentation pushes people outside of their comfort zones. But you risk souring communication if you are too abrupt or rude—even if you don’t mean to be. I spend a lot of time thinking about how the newsroom feels about the interactive department. It’s important to me for it to be a welcoming place, one where people can ask questions and learn and grow. Kindness and patience make the whole process better, creating a more fulfilling process, and allowing us to produce higher quality work.
Read Full Story from Source https://source.opennews.org/articles/code-runs-communication/
This article by Rachel Schallom originally appeared on source.opennews.org on September 17, 2015 at 09:04PM
