The Great Reanchoring

When I joined BuzzFeed just over a year ago, I spent the first few months of my time there setting the Product Design team up so it could scale well. I wrote a roles and responsibilities document, instituted Basecamp as the place for design work and discussion and overhauled our recruiting process. Since then, the design managers and I have set up quarterly peer reviews for the team, written our Design Leadership Principles and initiated weekly small group critiques in addition to our weekly one with the entire team. Each of these changes were made in response to needs we identified and wanted to make sure were met. They started out as experiments, but quickly became an official part of our team and process as each addition proved its usefulness. Progress was made. We felt good.

But recently, we decided to blow it all up.

A couple of months ago, my manager (our publisher) Dao initiated an offsite with senior tech management. The purpose of the offsite, she explained, was to do a close, critical examination of our processes and beliefs as an organization. She described our current processes and beliefs as anchors - things that we do because we've always done them and beliefs we have because we've always believed them. She told us that in order to evolve and grow our tech team, it was imperative that we reevaluate our anchors, decide whether not they're still valid, and then re-anchor ourselves somewhere else. We got together and discussed all sorts of topics: why do we tend to lean toward building our own tools rather than buying things off the shelf? Why do we believe so strongly in small, iterative changes over large projects? In a few cases, our thinking was totally validated and we decided to leave our anchor where it was. In many cases, though, the discussion revealed that our current anchors were holding us back, or even that we disagreed on whether or not an anchor was important. It was a super productive day and has already impacted the way we work and communicate as senior management on the team.

As the next week or two went by, I couldn't stop thinking about that exercise. I'd sit in our design critique and wonder if this was the right format and if people were getting the most they could out of it. I started writing annual reviews for some of the designers and managers and realized that our roles document (that I wrote!) was sorely lacking in a ton of ways. I'd look at our Basecamp threads and notice the wild inconsistency in how folks were using it (was it not valuable? Had we just not articulated how to use the tool well?). Most of these were anchors I myself had thrown down for our team just a year ago. We were anchored and it was all my fault!

So, I started an anchors document and wrote down the assumptions we were making as a team, such as:

• Each designer has unique challenges and goals. As a result, it’s difficult to set a consistent standard and uphold it across the board.
• Sharing work regularly and openly is good for the end result.
• Getting the entire team together to look at work regularly is healthy.
• Quarterly Reviews are useful because they give people constant feedback from their peers.

The design managers added a few and we decided together which ones felt most urgent and important. We scheduled a full day to go through each anchor in detail. We wanted to discuss and debate not only the anchor itself, but our current processes around each anchor (so, Basecamp re: sharing work). We also realized that about half of our anchors related directly to the designers' processes. It felt wrong to discuss and decide on new design processes without the designers' input. So, we shared the anchors with the entire team and asked for their thoughts and feedback ahead of time. Additionally, the managers nominated a few of the designers to come to the second half of the offsite to represent the team and discuss the anchors with us.

The end result was, in my opinion, hugely successful. We talked in detail about each anchor, took a ton of notes and made sure to write down action items so that we could hold ourselves accountable for changes. There was disagreement at times and there were frequently many points of view or ways of looking at a particular anchor. We decided on a lot of big changes (rewrite our Roles document to make it as clear and actionable as possible) and smaller experiments (try out a sign-up form for design critique instead of a regular rotation). Afterward, we put together a deck to share with the entire design team and talked through all the anchors, what we'd discussed and what we were going to do immediately. Afterward as we've talked with the designers one on one, it's become clear that we were all feeling the strain of our old anchors. There are a lot of positive feelings, excitement and momentum around the changes we're starting to implement.

Going forward, I imagine re-anchoring being an annual process for our design team. These changes we're making now will definitely set us up even better for the year ahead. However, I think we're now more sensitive than ever to what we're allowing to calcify into our team dynamics and processes. I've written in the past about treating your organization as a product and one way to iterate on your organization is to spend time thinking critically about your processes and why they're your processes. Decide what's important to you - not based on what's been important in the past, but about what kind of team you want to be in the future.

Wanna see what we talked about? Here's the slide deck we presented to the team.