Part I: An Interview with Brian Hamman, VP of Engineering for News Products at The New York Times

Part I: An Interview with Brian Hamman, VP of Engineering for News Products at The New York Times
By

Product Engineering in the Newsroom

Brian Hamman Interview Portrait 3

Enigma: Brian, thanks so much for sitting down with us today! For starters, could you talk a bit about what you do at The Times?

Brian: I’m the VP of engineering for product engineering. Our engineering team works on all the pieces of the site that you actually see and touch. That’s everything from the NYTimes.com homepage to cooking, crosswords, and all the other apps. Collectively, we’re probably about 1/3rd of the entire engineering org.

On the relation between Product Manager and News Editor

Enigma: You’ve been at The Times for over 10 years at this point. Can you talk a little bit about how the product engineering team has evolved?

Brian: One of the interesting things that has evolved is that the newsroom has gotten much more involved in our actual product development. In addition to the usual trio of product managers, designers and engineers that you usually see in technology teams, we now increasingly have editors involved.

Enigma: How would you describe the interplay of product engineering and journalistic culture?

Brian: Well, take The New York Times homepage as an example. On the one hand, it's basically a representation of what the editors of The New York Times think is happening in the world. It is a series of decisions that are made in the newsroom about the importance, relevance and interestingness of a list of stories.

But on the other hand, The New York Times homepage is an actual piece of software developed by product managers who think about people coming to the paper with a user need that they try to meet with features and things.

It’s often a topic of conversation here—the relationship between the editor and the product manager—because there is sometimes a little bit of tension between what an editor does and what a product manager does.

The way that tension used to be mediated was through a separation of concerns: the product managers control the boxes and the editors fill in the boxes with words. That was kind of the defining line, but it doesn't get you very far. And it certainly it doesn't help you push the product forward.

If you actually want to actually change the way you tell stories or change the news experience, you need both those sides to collaborate. We've gotten better at that but collaboration can be messy too because the roles are a little more fungible now.

If you actually want to actually change the way you tell stories or change the news experience, you need both those sides to collaborate. We've gotten better at that but collaboration can be messy too because the roles are a little more fungible now.

Enigma: We imagine that the really innovative interactive features The New York Times produces must be one of the strongest places where editors and technologists collaborate. Can you talk about the process of how these are produced?

Brian: When interactives tend to be driven by a single story, those will happen just in the newsroom. We have some technical people, like some engineers and designers who are technical, and journalists who are technical that will own those. And in those cases, you don't get a typical product-design-tech trio. You end up with more of what Ideo calls T-shaped people that are part designer, part journalist, part engineer. You still might have two or three people collaborating, but they're people that are much more a part of the newsroom.

That's where much of our most innovative work happens, when the boundaries of the “text and boxes” divide gets pushed forward.

That's where much of our most innovative work happens, when the boundaries of the “text and boxes” divide gets pushed forward. It tends to unfold at the pace of a story. If it's a big, ambitious, multi-story series, it could be months they're working on something like that. If it's something where they're reacting to breaking news, it could be hours. It completely varies.

Often what we'll do is after a few cycles of something in the newsroom happening, we might start to develop patterns or ideas of something we want to systematize, turn into a tool that we can then expand to the less technical folks in the newsroom—so they can recreate something that could be visually complex and incorporate a lot of images and text and other things, but not have to do a ton of hand-coding. That's when the product design-tech-newsroom crew will get together and figure out what that is.

Tech debt and the development of online news platforms

Enigma: Online news has gone through a lot of iterations over the last ten or so years. The Times has always been a leader in thinking about what it means for a newspaper to live online. I imagine this has created a bit of tech debt—how do you manage that?

Brian: Yeah. Tech debt has been a huge issue for us over the last two years, as I think it is for a lot of news organizations. Our platform was developing as the way people consumed online content was changing.

As the iPhone developed, the iPad, Android devices, as people shifted from desktop to mobile—each new platform was sort of treated almost as a new addition to The New York Times product code base.

Literally, if you look at the way The New York Times subscription was structured until fairly recently, it was device-based. You could subscribe to the iPhone, or the iPad, or all access, or just the web or all access. We really thought of these as different audiences, almost different products. We had different product managers for each one. Our architecture really reflected that, and our workflow reflected that. We had different editors choosing stories for the iPhone than for the desktop. If you came to each one of these, you would often get different ideas of what was important. We used to think the mobile audience was a younger, cooler, hipper audience that would tolerate faster-changing news and other things that our desktop audience wouldn't.

I think both as usage of these platforms evolved, but also as our understanding evolved, we realized that really we should be thinking of this as one product that you can experience on multiple, different platforms. Certainly our subscribers do that. They will use it on their phone, on their iPad, their desktop. They want to have a consistent experience. They want The Times to know them better and to know what they've already seen, so they're not just having to go through and mark things as read on different platforms, potentially to surface things that they may have missed.

In order to do that, we had to do a pretty fundamental re-architecting of our site to bring these things that were almost completely separate websites into a consistent platform from a technical perspective and then a consistent workflow for the newsroom while still preserving differences where it made sense. That for the last two years has been a huge focus of ours. We're actually just wrapping that up now.

Over the next month or two we're going to relaunch our website, or the homepage at least, and a bunch of things to give us the ability to produce essentially one version of our report, as we call it. What are the stories that The New York Times is tracking and thinking about right now that is consistent across platforms? That, then, is going to open up the ability to personalize in some ways and show things that you may have missed, things that we think you might find interesting.

____________________________________________________________________

Stay tuned for part II of this interview, where we ask Brian how The New York Times uses data science and analytics to inform their engineering and design process, as well as how they’re thinking about virtual and augmented reality.

Interested in joining the Enigma team? We're hiring.

Hero photo: Nic Lehoux