NPR’s Brian Boyer on Building and Managing News Apps Teams

Process, hiring, and what it takes to make it in newsroom code

Brian Boyer at the Hacks/Hackers BA Media Party 2013 (CC Ramiro Chanes)

As part of our one-year anniversary series, we’re interviewing news apps and interactive features editors about the history of their teams, the challenges they face, and their advice to designers and developers who are interested in newsroom work.

Yesterday, NPR announced that news apps team leader Brian Boyer was assuming a new role as head of the combined news apps/multimedia superteam. Boyer offers the unusual experience of having built out two news apps teams within five years, first at the Chicago Tribune and then at NPR. We spoke with him about his new gig, his path from computer science to journalism, his focus on sound process, and the internal obstacles new teams can face.

This interview has been edited for length and clarity.

Combining Forces at NPR

Can you give me a quick description of your new gig and what you guys hope to accomplish as a combined team?

We don’t have a team name yet, but news apps and multimedia go together like maple syrup and breakfast sausage. We all make awesome stuff for the web—pictures, video, Tumblrs, charts, animations, mobile things, data things, and stuff from our audience—and it’ll be even more awesome doing it together.

Origin Story

Let’s go all the way back to the beginning. When you came into the news apps world, what was your sense of its history?

I think one thing that’s important to remember is that it’s not like we just started this. I’m amazed when I learn about another project that Derek Willis and Adrian Holovaty worked on. So it’s not necessarily new at all, although having teams that do this, that have autonomy and funding and they continue to exist seems like a nice new development, although that’s not common across the board.

I only know anecdotally things about the history, things like what Matt [Waite] did with Politifact and what Adrian was doing… The transition that seems important to me, is—I’m interested in process. So when I got to ProPublica—and not to pick on them, or anything—but they had, you know, a very small team. It was Dan Nguyen and Krista [Kjellman Schmidt] and Scott [Klein], and they didn’t have version control and they didn’t have ticket tracking, and they didn’t have all these software best practices. And I feel like I run into this a lot with these teams—especially the ones that have been around for awhile. But it seems like the new ones are picking this stuff up faster.

For me, something I felt like I brought to the party early on is the idea that we should be looking to the software world. Or at least certain smart parts of the software world, because people not using version control is common everywhere…

I think that leads nicely into your origin story. Tell me where you came from, Brian!

My story is that I studied computer science in school for no good reason except I liked computers and read Wired magazine and thought computers were fun, and was pretty inspired by the internet. So I started programming in high school, and studied computer science for four years and hated it, and didn’t go to class and spent much of my time in the ceramics studio. And then got a job in the software consulting world in Chicago because I figured I would move out of programming as quickly as possible and on to business or something else.

And it turns out I actually really liked it, and I realized I was making things for people as opposed to writing algorithms, and that struck a nerve. So I did that for a long time in software consulting shops, and then at the end, it just grated on me—I didn’t feel like I was doing something good with my skills, so I was looking at a degree in public policy or in law. At the time, I was running a startup with some friends doing electronic medical software, there were three of us and I was out couch surfing for a few weeks on the west coast, and I was perusing Boing Boing after a long hard day of work, and I found this post that Xeni wrote about this program that Rich Gordon had gotten a News Challenge grant for. It was sort of an easy choice—it was in Chicago and our startup was kind of running out of money—but journalism had never occurred to me. I was on our high school newspaper, but I wasn’t, like, a reporter.

So I googled journalism and read the Journalist’s Creed and what journalism was about and some of its principles and why people do it, and it struck a nerve with me. The things I was thinking about law and policy were sort of better governance from the top down, and journalism was the same thing but from the bottom up.

It was a very quick thing. I started studying for the GREs and then I took them a week later, and then the week after that I wrote an entrance essay and applied and I guess I had like three weeks to get my act together and the application done. And then it all kind of went crazy from there: I went to Medill and basically got a regular journalism degree—it’s a master’s, one-year program with other journalism students—so I was writing and doing what everybody else does and working with Ryan Mark, who was one of the other two first students. We had a capstone project we worked on called News Mixer and it was all about news commenting systems. And it was actually kind of interesting, because that quarter was the quarter that Facebook Connect launched and so we were one of the first things that used Facebook Connect (which was the idea you could the Facebook button to log into a website) so it was like us and People Magazine were the first few things to use Facebook Connect.

And I went to ProPublica for a few months and got drawn right back to Chicago for the starter team at the Trib.

Building the Trib Team

You started the Trib team from scratch, right?

Yeah. Bill Adee, to his credit, knew that he wanted a team of people to do really interesting things on the internet and he’d gotten buy-in from the bosses to do it.

It was a fortuitous moment—I’d come to Chicago to go to PyCon 2009 with the idea that I was going to work on a Sunlight Labs project, which became the 50 States Project, which is now called Open States. And at that hackathon, I wrote some of my first Python and hung out with Joe Germuska and we hit it off and became friends. And I was going to go to this interview at the Trib a few days later. And I was like, “Joe, if you’re interested, I have might have a team at the Tribune.” And he probably thought that I was crazy. And since I happened to be in town, I went and talked to Bill and they offered me the job like a week later, and Joe was my first phone call and Ryan Mark was my second phone call.

I was going to ask you what shaped your early hiring decisions…

I got lucky, really. Joe just seemed to be a great person to talk to and was someone who seemed sort of likeminded and I was really not plugged into the civic/open gov hacking space at all—that just wasn’t my scene, I didn’t know that shit existed. And Joe was part of that group in Chicago. The reason there were no designers on that team at the Trib, is that I didn’t really know any designers! But Joe knew the open gov thing, and we kept trying to recruit [from the] government community. And that’s how we recruited Chris Groskopf. We met on the Sunlight Labs email list.

Sunlight seems like one of these deep roots that run across all these teams.

I used to tell people it’s where geeks with shitty day jobs go—geeks with souls and shitty day jobs.

How would you characterize the development of that team? Were you looking for people with specific expertise, or people whose backgrounds were different from the people you already had…?

I try not to hire for specific acronyms or technologies. I want to hire people who are smart and friendly, and frankly people we could make an emotional appeal to, because we couldn’t make a cash appeal. I had to find people who cared a lot because they were going to come work at a newspaper where we weren’t going to make a lot of money, but hopefully we were going to make the world a better place. So we sort of hired who we could. We did not have people beating down the door…that sort of changed over time as more young people started to be produced by J-schools who were really interested in tech. And probably also as we got more importance in that scene.

But, you know, when we started the team, there wasn’t someone like Heather Billings sitting on Twitter, making a fuss. We kind of built the team with who we could find, and felt like we liked and could work with, and who gave a shit. I think it was good. We built a good gang. (Maybe a little too white and a little too male, but what are you going to do? There are only so many applicants.)

The NPR Apps Team

How would you contrast your experience starting that team with when you moved to NPR? How did those experiences differ?

A big thing was, we came in with an established team. We absorbed the Graphics desk here, so a big, big difference is that we are the Graphics desk as well as the News Applications team. But that’s okay, because we don’t have a newspaper to illustrate every day. We tried at Trib to work with the Graphics desk, but we had a very difficult time because they had these very short deadlines, all this scrambling, and they work these terrible hours, and the process is fucked. Graphics desks have terrible lives. So what we ended up doing was taking interns off the Graphics desk—we’d just get their boss to give them to us for a week as part of our team, because the bosses knew that they needed their people to learn new skills.

Here [at NPR], we picked three designer/programmers plus Matt Stiles and kind of built up from there. So the obvious gaps were in programming skills or heavy hitting back-end kind of work. You know, I feel very fortunate, Chris Groskopf has allowed me to be his boss three times in a row…but it worked out nicely, because when he needed to move, the Panda Project was kicking off, and when the Panda Project was winding down, that’s when we were starting the team here.

For people who aren’t aware of all the tendrils of your work, can you explain how Panda came into this chronology, and where it got started?

Yeah, sure. There was a piece of software in the Tribune newsroom called DAVE that Darnell Little, a CAR reporter there who is now a professor at Medill, had written that was basically a place for interesting data sets for the newsroom: lists of city employees and lists of taxi drivers and that sort of thing for the city and the county. It was basically a database where you could search across multiple databases and look up little bits of information—and the reporters were using it, it was in daily use even by the Breaking News desk.

And Darnell left not long after we started the team at Trib, so it became our duty to take care of it, and we took care of it as well as we could, but the problem was we didn’t even know where the servers were. We had a very difficult time maintaining the system and it was getting a little stale and we wanted to have something that was a little easier to update, and maybe easier for people in the newsroom to add things—or even more like an intranet or more like a wiki for data, as opposed to something that only we were the gatekeepers for.

So that gave us DAVE 2—that was our project to replace DAVE—and that was Matt Hampel’s summer internship, so in 2010 I guess. He was our first intern on the news apps team and he’s now one of our Knight grant recipients and was at Code for America. So he worked on that for the summer and we never launched it, which makes me very sad, and since then, we’ve structured our internships differently and not given an intern a project to work on alone for three months…

But right as that was not launching, the Knight News Challenge was up for entrants, and that weekend or maybe two weekends after he left, I sat down and wrote the entire grant proposal on my iPad and submitted it and when I got to work the next day I was like “Hey Joe, you want to do this with me?” I submitted the grant proposal and so Panda came directly out of a specific need we had in the newsroom and we realized that it was too complicated a project to do in a summer, and we needed full-time developers and a budget.

And how did Panda grow from there?

We were very fortunate to be able to bring Chris [Groskopf] onto the team. And Joe and I were looking for a board member who was different than us. Someone who worked in a newsroom at a smaller newspaper or maybe not at a Tribune company…so we weren’t going to call the folks at the New York Times, and we couldn’t have called Ben Welsh in LA because he also works at Trib. And this [Ryan] Pitts guy, I thought was smart on Twitter—I mean, I didn’t know, I’d never met the guy. And I decided—I think Ryan should be in on this, because you know we’d talked on Twitter about Rush and Python and I was like “I think Ryan should be our partner.” So I called him on Skype and we’re video chatting and this is the first time we’ve ever spoken with him or seen him and I just asked if he wanted to be the partner with us on the project and he was like “suuuuure.” So we kind of just sucked him in… I was either incredibly lucky that he wasn’t a total jackass or I have very good instincts. And I think probably the former. So that was the board, and we had a pretty solid idea of what we wanted the project to be already because we’d already tried to build it for Trib. We did a development exercise and hashed the whole thing out in the Christian Science big, beautiful courtyard in Boston. We sat there all day with index cards and markers and hashed out what the Panda project should be.

Excellent. How would you describe the biggest challenges you’ve faced since you got to NPR? And how long has it been since you got there, again? Time is passing really quickly.

Just over a year—well, not just over, a year this past July.

What have been the big challenges of year one?

It’s been the same challenges we had year one at Trib—getting people [internally] to know who we are, getting people to call us for projects and call us early. Building awareness and trust, because we’re new, we’re different. You can’t call us like a Graphics desk—you can’t call us a week before the story launches or two days before the story launches and say “Hey, I need a chart for this.” But we’ve made inroads. We do lots of projects with Morning Edition, we do practically nothing with All Things Considered, which I think probably has to do with when they’re awake or busy. By morning in the newsroom, Morning Edition is done with their show, but All Things Considered is hustling toward their deadline.

The other challenges are maybe similar, in that we rarely make the project someone asks us to make. And that’s okay. Someone usually comes to me and says “Hey, I’ve got this list of things, can you put it on a map?” And then we work through a sort of exercise or we talk about our users and what needs we can serve, and end up arriving at something better or more useful. And sometimes we just say no, which disappoints people.

I think I have a team with a well-managed process and a strict set of priorities, and it doesn’t work more than eight hours a day. We don’t come in on the weekends. We don’t do all-nighters because we keep our stakeholders aware of what we’re doing and we do a lot to avoid surprises. Everyone has to have processes that work for them, and so everyone’s processes are going to be a little different. Most of our projects take less than two weeks, from concept to done, so we have to sort of be extra lean.

News Apps Process

As I’ve been working near news apps teams, having worked in other kinds of tech for years—you guys deliver like nobody else.

I’ve mentioned this in a couple of my recruiting posts, but I’ve never seen a team—at the Trib, but also here—I’ve never seen a team learn this fast. I’ve worked on a lot of software teams, and I’ve led a handful, and I’ve never seen one learn this fast. And it’s because the newsroom is a crucible.

We’re forced to crank things out very quickly, which means we pick up a new project every two weeks, which means we picking up new pieces of technology every two weeks, and we’re upgrading our stack every two weeks, right? So we have this opportunity to constantly refine our tools and always be trying new things. So we just get better faster by doing these stacks of short sprints. It’s remarkable. It’s super fun.

Everything we do is about transparency, both inside the team and outside the team, every part of the process. If it’s scrumming every morning, our five-minute meeting, if it’s having weekly iteration reviews with our stakeholders—we take our software and we just walk around the newsroom and ask people to try it while we’re with them. I don’t want secret features that our stakeholders don’t know about, and I don’t want coders working on secret projects, and that’s what happens at most organizations is that every programmer has their own special itch to scratch and they just work on it and nobody knows about it. There are always interesting problems to solve, and we need to be marching together to solve them. And that means that sometimes we’re doing boring shit like…testing. But we launch. We always launch.

Just that alone—always launching—seems like it would really help with developer fatigue.

We might look into a project and poke at it for a couple of days and do a prototype, but we stop there, if we don’t think it’s going to go anywhere. At Trib or here, there hasn’t been a project that we worked on for months that just didn’t go, for some reason.

This seems like one of the ways in which this work is really different from so many opportunities programmers have outside of journalism—so many really long projects that have branches that don’t launch forever…

It’s no fun! And you know, I’ve worked on long projects, and I’ve generally enjoyed consulting work more than software, for similar reasons—but even a consulting project can take six months to a year.

Rolling Your Own Apps Team

I want to ask you for some advice from two different angles. The first is: if you’re in a newsroom that doesn’t yet have a formal news apps or interactive team outside of whomever maintains the website, what’s your advice for starting that team?

Someone needs to get their back against IT…but I don’t want to bust on IT. People at the top need to like that they exist. There are a lot of teams that don’t have as much backing from their editors, and they struggle when IT decides to crush them. So I’m kind of ranty about that.

Why would IT do that? If I can just go straight into the hornet’s nest.

Let’s go straight into the hornet’s nest. I don’t want to take care of code someone else wrote. Understanding someone else’s code is impossible, it can be very, very difficult, even with well-written, well-documented code. And IT’s job is stability, and IT’s job is consistency. And I respect those jobs. So they have systems and processes and they use one platform and they might make technology choices that I wouldn’t make, but they make them because they’re consistent with their uptime goals, or consistent with, like, “We’re an all-Windows shop and that’s how we can keep the ship running.”

Whereas we’re going for the opposite. I don’t want consistency: I’m trying to use the best tools for the job, every single job, which probably means we’re changing programming languages every week. So an IT department when they see a team doing that, they imagine, “What happens when all those people quit? What am I going to get stuck maintaining?”

So they see us as a potential giant pain in their asses. I don’t even want to say they think we’re a threat to them, we’re just—they’ve been stuck with things before, people leave their jobs and they get stuck with code. This is what happened at Trib, when programmers left their jobs, and it bites them in the ass. So having editorial leadership back us up and say, “We’re not going to abandon this team, we’re going to keep hiring for this thing,” and also say, “Listen, leave this team alone, let them do their jobs.” Because you need backup.

At NPR, we have a really good relationship with our tech people, but that’s also because our tech people aren’t IT. One of the things that’s great about this organization is that the product group—the tech group—actually works for Kinsey Wilson, who’s also the boss of news. So the tech group isn’t in operations—they’re in content. Kinsey is the chief content officer. So that corporate structure means that the product people are not the same people who are doing the telephones and the satellites and the infrastructure, so our goals are much more aligned, which is wonderful.

So #1, you need backup from the top point of the newsroom: the editor in chief needs to have your back. And #2, everyone needs an editor. I feel terrible when I see a sort of lone gun programmer-journalist type in the newsroom and they flail because they don’t have an editor. You wouldn’t let a reporter just write stories and put them on the website without an editor. And that’s expensive, because it means you’ve got those two people. But when I am too deeply involved in coding or actually creating on a project, I have to step away and go find someone else to be my editor, because I get lost. So what that means these days is I mostly don’t code. I stay back as an editor, which is why I don’t take bylines anymore. I’m intimately involved in the process of it, but I’m still one step away.

And that doesn’t necessarily mean that person has to be a technologist—it helps if you’re one, but having. You know, Scott Klein’s not a software developer, but he’s very technical. You need that.

And I think it’s very important to study best practices. Even on a one-person team you need version control. Even on a one-person team you need to track your tickets, even on a one-person team you need to have a process for how you prioritize and how you get things done. And when you add one person to that team, you’ve squared your problems. But even the smallest teams need good process and frameworks to help you get your job done.

How to Break In

The flipside of the previous question is, if I’m a programmer in consulting or in startups and I look over and see your world, how do I get there? How do I make myself the right person to join a team like yours?

Well, you know, step one is to give a shit, which is maybe something you can’t make yourself do. But it helps a lot. People on these teams—we care. And then, in most cities there are wonderful meetups, like Hacks/Hackers meetups, and you can meet these people and become friends with them. I am most aware of people who are involved in the conversation online—people who tweet and chat and write comments and ask questions, but hell, just apply. NewsNerdJobs.com, there are stacks and stacks of jobs. And if you care and you’re maybe willing to take a pay cut, there are jobs. There are opportunities all over the country.

And that’s it. I don’t think there’s a lot of preparation necessary. We generally work with free and open source tools, but I would not turn away a lifelong Microsoft developer if they’re willing to try on some new code. You know, I mean—I was a Microsoft developer for the first seven years of my career, so you know, we can change. Go volunteer on a Sunlight Labs project! Go do a civic hackathon, go to your open government meetings, find a meetup.




  • Brian Boyer

    Brian is an independent consultant. Previously, he was the vice president of product and people at Spirited Media, the visuals editor at NPR, founded the news applications team at the Chicago Tribune, and was a happy intern at ProPublica. He was one of the first programmers to receive a Knight-funded scholarship to study journalism at Northwestern University.

  • Erin Kissane

    Editor, Source, 2012-2018.


Current page