The editorial products team at Vox Media is the one responsible for projects like SB Nation's live draft tracker or Verge's Apple Watch review or Eater's dessert mashup generator or Racked's fashion quiz. Our group has evolved over the past year, going from dedicated vertical teams, to a centralized company-wide team, to the structure we have now, which is a mix of the two. Throughout our evolution, we've learned to get things done in a way that empowers experimentation but strives for scale and repeatability.
This is Part I of an ongoing series about what we've learned on this one particular group within the greater product team. (Other product groups have their own structures and processes).
Team structure
We are a company that iterates. We do that with our code, we do that with our process. We also do that with our team structure to make sure our teams can map to the goals we have. Our evolution corresponds to the changing goals we have — from growing brands, to scaling brands, to continuing to innovate around storytelling in a reproducible way.
These are the team structures we've so far tried, and why they didn't work:
- Site-based product teams. Designers, engineers, a product manager and a support manager used to exist for every site, meaning they handled everything from the storytelling needs to the site buildout to bug squashing. This worked while we were building up our brands, but ultimately doesn't scale and results in us creating a bunch of different solutions for the same types of problems.
- A mix of centralized teams and site-specific features teams. We moved some common functions to centralized groups, leaving only a features designer, features engineer, support manager and product manager on the sites. This solved more problems, but we were still in a pattern of creating one-off features and not enough tools, and the features teams across sites weren't working together.
- A centralized apps team for all the sites. The summer when Ryan Mark joined our team, we disbanded the small site-based features teams and centralized into one apps team that was responsible for creating tools, apps, data and graphics work for all the sites. One of the team's missions was to create better tools for the engineers and editorial teams who were building editorial projects. In the first six months, we made some of our frameworks more extensible for spinning up projects, but because of the production cycle and demand from seven sites, it was hard to focus on anything but churning out more beautiful apps.
What we're trying now is a little bit of a mix between a centralized apps team and site-specific embedded teams.
With the group broken up into distinct teams, we're able to:
- Have the flexibility to meet site-specific goals. Embedded hires can do anything from engineering, like SB Nation's Graham MacAree, to illustration, like Racked's Brittany Holloway Brown. Editors can hire embedded positions for their teams that directly map to their editorial goals.
- Prevent siloing from happening at the site level. People won't be working in a vacuum without any support or insight into what the other teams are doing. Embedded people work with the centralized team on a daily basis and rely on the centralized team for design, technical and process guidance. Despite the differing roles and responsibilities, daily checkins ensure that we can avoid duplicating work, build off each other's work and learn from each other.
- More consistency across sites. We have an engineering director and a design director on the Editorial Products team who are accountable for the work being done by the embedded teams, meaning we have code and design reviews, and work with a holistic view when coming up with new solutions at the site level.
- Have a stronger feedback loop. With a tools team working at the centralized level and embedded teams at the site level, we can work on parallel tracks. See the next section.
Product lifecycle
The team structure I outlined in the section prior is a very deliberate way of enforcing a product lifecycle that lets us continue to innovate, while making sure we institutionalize the successes — building once for use, and rebuilding for reuse.
The embedded teams are responsible for creating projects to solve the immediate needs of our newsroom. The tools team takes the best of those experiments and abstracts them out to be tools that any site can use.
Here's an example of that life cycle in practice:
1. Vox.com makes a shareable headline generator.
2. The Verge riffs off that concept to make a Comcast custom name generator.
3. Eater further riffs off that to make a dessert mashup generator.
After reusing this code two times, it's time for us to think of a way to templatize it. We created a new blueprint for our tools rig (which we'll be releasing to our editors very soon, after some user testing) that abstracts the concept out into a reusable tool.
Editors can define a headline and variables, then words to feed into each of those variables. The output is a super simple text-based generator that lets you share your mashup.
Also notice that the template we went with is not complex. What we learned from The Verge's generator and Eater's dessert generator (high-touch design) vs. the John Oliver one and SB Nation's draft generator (low-touch design) is that spending a ton of time art directing one of these generators doesn't make it more shareable. The beauty of our embedded structure is that we can try a bunch of things then standardize on what works.
We've followed this same life cycle for filterable charts, sortable tables, bar and pie charts, a list template, social image generator, flowcharts, image sliders and we're now moving on to the common big features templates that we use (brackets, multipage packages, etc).
Keeping the teams united
Some of our team members may be embedded while others are centralized, but we are all one big happy family. We make a deliberate effort to ensure that we're supporting each other and working together so that we never get back to a world of siloing.
Small things go a long way in the regard, so we stay united by:
- All being in the same Slack room
- Doing a daily stand-up with everyone (30 second updates only!)
- Holding a weekly retrospective and knowledge share together
- Convening regular code reviews and design critiques
- Participating in fun activities like our monthly product Jambo and Vax and lettering workshops