November 15, 2013
Working with developers in the newsroom

Last month I co-led a “Web Developer Literacy” for reporters and editors at the Online News Association conference. I expected a lot of questions about particular technologies, but the discussion wound up focusing much more on process and office politics, touching on tough questions like:

How do you integrate developers into a team of reporters?
How do you spec out digital projects when you have no idea what’s feasible?
How can developers, designers, and reporters work together effectively in the crucible of a newsroom?

These are far from solved problems, and newsrooms have some particular handicaps.  They typically lack the time or money for a strong project management function. Needs are unpredictable (I don’t know of many software companies where a product is conceived in the morning and then launched before lunchtime). Decisionmakers are unlikely to come from technical backgrounds, and they’re still adjusting to the relatively new phenomenon of developers in the newsroom.

Despite those challenges, though, lots of interactive teams seem to be converging on certain successful principles.  Here’s the short version of what I said last month:

Clarification: when I say “developer” below I mean a newsroom developer who works on interactives, graphics, data journalism projects, etc. How much this applies to a developer who works on your CMS or your mobile app is a separate question.

Talk to a developer early and often.

One of the worst things you can do is let the editorial horse get way out of the barn and then drop your request on a developer’s desk at the last minute. Supposedly “technical” questions have real implications for design and storytelling, and you need that perspective when the project is taking shape, not after all the important decisions have been made. 

Even something as simple as geography matters. If a reporter and developer are working together on a project, they should probably sit next to each other. If that’s not possible, get them on chat or have them pick up the phone often. Email and tickets are great, but asynchronicity is the enemy when you’re working against a deadline.

Ask a lot of questions, especially ones you’re afraid are stupid. Odds are someone else in the room has the same question. When a developer lapses into obnoxious developer-speak, swallow your pride and ask them to translate. Don’t just nod and make a mental note to go Google “S3” later. Having the conversation right then will clue you in, but it will also help your developers understand where you’re coming from.

Developers are journalists, not technicians.

Your news developers may not be writing or calling sources, but they are journalists, and should be treated as such. You need everyone invested in the common cause of the story and the audience. If they aren’t, and they feel like their job is only to worry about the technical details, the thread will get lost along the way and you will end up with a beautifully designed, beautifully coded piece of crap.  Your developers will be gatekeepers who spend their time saying no to things instead of contributing ideas and working with you to solve the problems that matter.

Talk up front about what might change.

In a newsroom, information rarely comes as a perfect batch, especially on a breaking story. It comes in bits. It gets revised and replaced. As you prototype things or explore some data, you’ll wind up adjusting your original approach. Things will change. That’s OK. But it can save everyone a lot of time and aggravation if you express that uncertainty before you send a developer down the rabbit hole.

Whether an idea is firm or experimental, whether data is going to change or not (spoiler alert: it’s going to change), whether a project is definitely going live next week or is definitely maybe probably not going live next week: these will significantly affect how a developer approaches a task under the hood. The best thing you can do is simply be upfront about what you know and don’t know, the possible ways the project might zig and zag. This way your developers won’t paint themselves into a corner, and they’ll free up more time for other work.

Don’t think “possible” vs. “impossible.”

A lot of questions you get as a developer start with “Would it be possible to…” Almost anything can be done given enough time, enough developers, and enough duct tape, but if you just keep throwing changes into the pot one at a time without a sense of opportunity cost, it’s not going to end well. You will almost never get to produce your ideal version of an interactive. Many good ideas will be left on the cutting room floor. The starting point for discussing a new one should be about the timetable and the existing priorities.

Respect a developer’s concerns, but be ready to push back.

Developers can seem like they’re being too precious about technical issues. Maybe they’re demanding a lot of time to test a new app before launching it, or telling you you can’t do things a certain way because it would overload your servers, or expressing concerns about using a third-party API. They often have a good reason. If something breaks later, it will fall to them to clean up the mess; they need to mind the technical store. And a choice between two JavaScript libraries that seems like inside baseball may mean a difference of a full day’s work.

But this doesn’t mean you should be a supplicant, going along with whatever a developer says because they’re using a bunch of jargon or you’re afraid to step on their turf. Developers have plenty of biases, and they can easily lose sight of how one technical bugaboo balances against other tradeoffs. Challenge them on things. Ask them to explain their reasoning. That’s how we all get better. If they get prickly about it, they’re doing something wrong, not you.

This is a two-way street.

This isn’t just about reporters and designers working to better understand where developers are coming from. The reverse is equally important. What works for a software company does not always work in the newsroom. Developers should strive to better understand the reporting process, the importance of design, and the unique demands of news. They need to let go of some of their technical dogma and get used to working without a net on most projects.  They need to care about your audience, which may consume news differently than they do.  Above all, they need to learn to truly work as a team with non-developers, and that comes back to communication again, being able to explain the why of complex choices to non-developers and give competing priorities a fair hearing.

Have any thoughts about this?  I’d love to hear them.

1:13pm  |   URL: http://tmblr.co/Zu2spt_ToMNF
  
Filed under: opennews 
  1. tylermachado reblogged this from veltman and added:
    Well put. We’re still working on this process.
  2. sinker reblogged this from journo-geekery
  3. shanembailey reblogged this from journo-geekery
  4. latenighttaskforce reblogged this from veltman and added:
    A lot of great insight on techies working with non-technical stake holders in general.
  5. journo-geekery reblogged this from veltman
  6. veltman posted this