Jeremy Bowers

Jeremy Bowers is a senior developer at the Washington Post. Before that, he was a news technologist at the St. Petersburg Times, working on news apps like PolitiFact. You can reach him at

5 steps for building a successful news app team

It’s no longer a question: data-driven news applications generate traffic and engagement. And as organizations continue to prove, they’re also noteworthy pieces of important journalism.

Despite this, news applications at media organizations are still the exception and not the rule, and even fewer organizations have an officially organized team. If you’re thinking about how to organize a team of your own, or even how to start the discussion at your company, here are five principles to guide your work.

Recruit internally

Many of the best news apps developers have been recruited from different positions at the same company. For example, the news application team at Poynter’s St. Petersburg Times was built entirely from existing staffers. Matt Waite worked on PolitiFact while still technically a reporter. CSS guru and designer Martin Frobisher formerly worked in paste-up and was snatched away from the advertising department. And I had worked in IT on pre-press systems for print. Other contributors were cops reporters, cartographers and even a particularly skilled print CMS support engineer.

In your newsroom, candidates for news applications teams could come from news art, where they’re building flash interactives by day but dabbling in exotic Javascript libraries and CSS3 animations away from work. Your job is to identify the producer who’s teaching herself Django or the cops reporter who’s learning MySQL to make data analysis easier.

Additionally, recruiting internally enables you to build interesting relationships with groups inside your organization. Pick a former cops reporter? You’ll have great insight at crime apps and data. Pick a former IT staffer? You’ll have someone working tirelessly to tighten up your server architecture.

Provide for success

Unplanned success can be more dangerous than failure. At the St. Petersburg Times, MugShots was picked up by Gizmodo within the first month and nearly took the site down with traffic. We hadn’t planned for that level of success, so we had to work to build a standard server architecture that would withstand loads that were 10 times higher than our highest estimate. Making sure your team has either a strong server administrator or good relationships with IT or infrastructure can prepare you for the kind of traffic that comes with success.

Another form of success that can be dangerous is internal popularity. A site we built for events and destinations was more popular with editors inside the building and with advertisers than we’d planned for. As a result, we had to clear our development schedules to add requested features and advertising opportunities, as well as perform maintenance. Building your team modularly can allow you to add staffers or contractors — and proper development processes like version control and documentation can make adding staff easier.

Provide for failure

Some news apps just don’t work. An education app we build around assessment tests in St. Petersburg didn’t get the kind of traffic we wanted and lacked newsroom support. Having set reasonable traffic goals and some user engagement targets early, we could clearly determine that the app was substantially underperforming. After a few months, we redirected pages of the app to various blog posts, shut down the site and began the discussion about what went wrong and what should be in the next version.

This gave us the flexibility to focus on our next app without wasting time on maintenance.

Establish autonomy

As the Chicago Tribune’s Brian Boyer explained in Steve Myers’ article on challenges facing news apps teams, technological autonomy is the key to getting software out the door on a daily news cycle. Shipping finished projects is a skill; a news apps team’s job is to produce apps, not just code.

However, this autonomy comes at a price. As Myers’ article points out, autonomy doesn’t mean isolationism. Finding ways to leverage relationships with skilled IT administrators is a necessary step if your team doesn’t have the skills to handle big traffic. As always, balance is critical; Myers’ article contains a cautionary note about the news apps team at the St. Petersburg Times and the value of keeping your team autonomous enough to focus on editorial projects.

Say no

A newsroom produces a seemingly neverending supply of project ideas. But as Joel Spolsky reminds us, ideas are easy but execution is hard. The best news apps teams have the ability to say no and to pick the projects that have the best chance to be successfully executed.

Identifying projects in your team’s wheelhouse means working with the newsroom to filter out projects that are too big or too small. Few news apps teams build full CMS’s, though some have found success with this, and there’s at least one argument that the CMS is the new frontier for news applications. On the other hand, news apps teams rarely face the challenge of daily deadlines, unless it’s for breaking news or a new application of an existing tool. The middle ground seems to be just right — projects smaller than a platform but larger than a two-or-three-click interactive.

While there’s no cookie-cutter solution to creating or rebuilding your news applications team, these principles offer a good start. An approach that builds strong relationships, identifies clear patterns for success and failure, and guarantees flexibility will set the foundation for news application success.

This How To is part of a Poynter Institute/Online News Association partnership aimed at bringing more digital know-how to more journalists. Jeremy Bowers, an ONA member and senior developer at The Washington Post, will elaborate on the tips in this How To during a presentation at ONA’s annual conference this September. You can reach Bowers at Read more


Get the latest media news delivered to your inbox.

Select the newsletter(s) you'd like to receive: