A happy team is one that is productive, effective, and fulfilled in its
work. It’s hard to get there when you’re balancing competing priorities
of many different sites, sections, or editors, alongside the company’s
needs to scale and platformize. The Editorial Products group at Vox
Media—just one small subset of the larger product
team—deals with the realities of
this daily. We have people working on platform
tools
and others embedded in
newsrooms,
working alongside reporters. There will always be chaos when you mash up
the demands of the news cycle with the product development cycle, and my
role as a director of this team is to remove as much uncertainty as possible.

To mitigate the chaos, we’ve developed some processes together over
time, usually when we feel our happiness meter start to dip.
Conversations like “I’m building my first graphic and I feel alone and
no one is helping me and the docs are incomplete!” or “I feel so
disconnected from the rest of the team being in a different city” or “I
don’t get what criteria your team is using when you say no to my
projects!” are all the catalysts for change.

No matter the size of your newsroom or data desk or graphics team or
product group, these are three important practices we’ve developed that
can keep a team united and keep your projects running on time.

Document All the Things

Documenting everything for yourself, and the people who rely on you,
helps in so many ways. It eases onboarding, instills trust among the
team, keeps stakeholders informed, and holds the whole team accountable
to our objectives. Most importantly, it improves team happiness. Yep,
docs can do that.

Say you have a teammate who’s unhappy about your design review process.
She really wants to add a step that would make her work easier and more
efficient. Instead of making an amorphous promise like, “we can work on
improving that over time!”, you can open up your process document, add
the step to it, and send it around. The message: a thing has changed,
let’s all act on it immediately. Canonical, centralized documents make
decisions more meaningful and easier to implement.

This is especially important with remote teams, where habits and
processes might develop amongst the co-located members, leaving others
feeling disconnected. Writing it down creates a shared way of doing
things that everyone can see and contribute to.

Some examples of things to write down:

Mission: What is the high-level vision we’re working toward, and the quarterly objectives to get us there?

Working on projects: How do you initiate them? What questions do
you ask from the start? What tools should be used to track work, and what
are the best practices and expectations for using those tools?

Evaluation: How do you prioritize your work? For us, it’s a
rubric that weighs audience growth, editorial impact, storytelling
innovation, and revenue potential. Without a clear sense of how you
prioritize, it can seem arbitrary to your stakeholders, and easy
for your team to make exceptions that set you off course from your goals.

Communication: How to communicate with stakeholders, be it
editors or a product team or sales, in a way that is consistent,
easily accessible, and honest. What’s your practice when your team
messes up or something breaks? How do you solicit feedback on
designs? (I touch on this in the next section). How do you let
people know what kind of work is upcoming, and what’s been accomplished?

Technical: How to set up your engineering workstation, and get
started with projects.

Yes, writing docs takes time. You have to do it regularly, and you have
to go back and update your documents often. That’s not the job of the
product manager alone. That’s the job of the entire team. We solve for
this by holding a Documentation Day, a full day of doing nothing but writing.

Here’s how:

Every time a new person comes onto the team, have them write down
every question they have. Everyone else should do the same,
writing issues down as they stumble on problems or undocumented
processes, or old docs that need updating. You can keep a running
Google Doc or a lane on a Trello board for things to document.

Once that list gets long enough, work a Documentation Day into your
team planning or your sprint. The day starts with a kickoff, where
we go through all the things that need to be documented, to jot down
quick bullet points and goals for each assignment.

Everyone gets to write something (or comment code, or create new
templates/styleguides—not all documentation is in the form of
text docs)—and every assignment also gets a peer reviewer. The
peer reviewer’s job is to make sure all the questions have been
answered, that the structure of the document is organized really
well, has a good starting point, moves you through coherently
step-by-step, and includes supporting links when necessary.

Once all the docs are written and peer reviewed, collect them in one
place where everyone can easily access them—a wiki, a Google
doc, some other searchable tool! We use one centralized Google Doc
as the place that links to all of our documents by topic. We write
most of our how-tos in Google Docs, and technical docs go into
GitHub wikis and READMEs for their corresponding repository.

Structure Design Reviews for Maximum Joy

Here’s another tricky spot, where happiness can evaporate quickly. When
any groups of multidisciplinary people work together, a big part of the
process is back-and-forth feedback, for revisions. This design review
with stakeholders can drag on forever. (And by stakeholders, I mean your
collaborators, people who rely on you, and whom you rely on.)

Establish the points of focus to discuss. If you are presenting
sketches, say that this is a meeting about concepts, not fidelity.
If you are showing a polished logo, the minutia of type kerning
may be discussed. This helps focus the discussion.

Avoid vague questions like “Do you like it?” or “What do you
think?”, as they will trap the discussion in opinions rather
than project goals. Strive to ask targeted questions that test the
goals of the project. For instance: “Does this feel like The
Verge?”, “Does this interaction feel clear?”, “Do these icons and
colors feel like they are part of the same design system?”, “Is
this typography and typeface selection working for this subject?”

Don’t try to solve design problems in the presentation meeting.
Group design reviews are great for identifying problems, but not
great for solving problems. This is only the time to present and
discuss what is working or not. The meeting will give you the
information you need to solve design problems later.

These rules have changed the way we talk about our work and have helped us
work through issues more quickly. If someone tries to jump into a
meeting who doesn’t have context or wants to solve design problems on
the spot, we can step it back and make sure we’re focusing on the
problems at hand. When someone says, “We should do a mosaic-style grid
with large, medium, and small images sprinkled throughout” we can say,
“Let’s talk more about that. It sounds like you’re looking for more
variation and hierarchy?” and take the conversation to a place of goals.

Let the Humanity Shine Through

Part of keeping a team happy is making sure your teammates know more
about each other than their file-naming conventions or code-commenting
style. We’re all humans, and it’s healthy to foster team relationships
in a personal way, which, again, is super important with remote teams.

Here’s a structure for a weekly meeting, Google Hangout, or Skype chat
that brings everyone closer and helps them look back at their progress.

Give everyone time to show and tell. Every Friday morning,
create a new Google Presentation that anyone can add slides to. At
the meeting or hangout, those who added slides get to talk. People
can share everything from an introduction to their children, to
their favorite weekend hikes, to a personal time-management skill
they learned, to their favorite ways to reduce pageload. It can be one slide, it can be 10; it can be one minute,
it can be five; it can be personal, it can be work related. It
takes you out of your normal work mindset, loosens everyone up a
little, and brings everyone closer. We’ve made a meeting like this
work for up to 20 people, which is probably as big as it can get.

Reflect on the week. Doing retrospectives every week or at the
end of every sprint is super important, but for large teams with
complex projects, it’s hard and incredibly time-consuming to talk
about every single thing that was built or shipped. Instead we use
a more casual, two-step approach. First we “damn the things,”
where anyone can talk about what went wrong during the week (no
badmouthing your teammates!). Then we do shoutouts, where we can
call out anything that went really well, or teammates who did
awesome work. Based on this part of the meeting, we can schedule
project-specific retrospectives if there are clearly certain
issues we need to talk through.

The format of our Friday hangout is a mashup of things stolen from
Editorially and TribApps
plus a little of our own spice—and now you can steal it and remix it too.

These three practices haven’t been in place since the start, and they’re
certainly not the only processes we employ to keep each other sane. The
team has shaped these ideas over time, always in response to unhappiness
and because we have a hunger to make things better. We have an open and
healthy culture of talking about what works and what doesn’t. The team
knows that the leadership level works for them, not the other way
around. It’s the job of the directors to give everyone what they need to
be effective, productive, and fulfilled.

We experiment with this stuff constantly. What I’ve outlined above is
what we have in place today, but it was different three months ago and
will be different three months from now. The important thing is that
everyone on our team is empowered to refine, adapt, and iterate to find
something different or better. And once we’ve done that, we write it
down and start the cycle over again.

Connect

OpenNews connects a network of developers, designers, journalists, and editors to collaborate on open technologies and processes within journalism. OpenNews believes that a community of peers working, learning, and solving problems together can create a stronger, more responsive journalism ecosystem. Incubated at the Mozilla Foundation from 2011-2016, OpenNews is now a project of Community Partners.