Skip the Shortcuts

Over the past few years, I’ve had a lot of people thank me for open sourcing the Product Design Roles documentation that we developed at BuzzFeed. It’s always very nice to hear that the work we did has proven useful to folks (the repo has over 500 stars and nearly 100 forks on Github!), and it definitely gets me thinking about what else might be helpful to put out into the open.

At the same time, I’ve had a number of folks approach me a little frustrated, telling me that the role documentation we wrote didn’t work! More than once, I’ve listened to a design leader go on at length about everything wrong with the BuzzFeed docs and why it was a huge failure for their team. Some made up (but close to reality) examples:

Our team doesn’t code so everyone got stressed out when it was part of our docs.

or

We centralize our design team, so when we tried your roles they didn’t work at all.

Each and every time someone talks to me about how the BuzzFeed documents don’t work for them, I hear them out and then always wind up saying the same exact thing:

Yeah, of course, that totally makes sense.

So what's the problem?

The reality is that the BuzzFeed role documents are just that: BuzzFeed’s role documents. They were written by myself and other BuzzFeed Design Managers, for the team we wanted to build, within the context of BuzzFeed as a company. They reflect our biases, whether toward totally transparent design processes or designers writing code, and are the result of years of learning and iteration. Through that lens, it makes a ton of sense that those same documents can’t and shouldn’t be airdropped into another organization.

Even at Primary now, I’m only taking bits and pieces from past documentation and processes. For instance, we only have one Product Designer (with another joining soon!), so a lot of what is in the BuzzFeed role document makes absolutely zero sense and shouldn’t be used! Or recently, when I was working on Primary's annual review and compensation process, the approach I took (for around 50 people right now) is a bit different, you can imagine, than the approach taken by the 1000+ person BuzzFeed or Etsy org. So, while I’m taking inspiration from past experience and work, at this point in my career I know that lifting anything wholesale (even from myself!) is not going to wind up working for me.

But there’s something else, too.

When you take something like BuzzFeed’s role documentation or anything else you come across (e.g. org structures, Agile processes, continuous deployment, recruiting processes, etc.) and implement it as-is, not only are you going to be surprised and disappointed by the outcomes, but you’re also denying yourself a huge opportunity to develop new skills and lead your team. If you’re managing a team, but using BuzzFeed’s role documentation, what does that say to the people you’re leading about what you think the team should become or how it should operate? When writing the BF documentation, a lot of our time went into making sure it reflected what people like myself and the design managers agreed we wanted the team to achieve. Behavior starts at the top and trickles down, so if you’re not intentional about how your team works, no one else is going to be either.

As for learning new skills, one of the reasons I now feel so confident evaluating what teams need and writing documentation to reflect those needs is that I’ve done it a lot of times, all from scratch! Was my first role document, recruiting process or annual review methodology perfect? No! But I learned more each time I did it, saw where there were gaps, unexpected outcomes or mismanaged expectations, and tried again. We iterated on the BF role document every single year, right after annual reviews, while the document was fresh in our minds. We also iterated pretty consistently on our recruiting process (sometimes going too far, but hey, we learned!). And I evolved the performance review process every time I ran it for the Tech org.

Looking back, it would have been a lot harder to learn if I’d taken something wholesale as a starting point, since I wouldn’t have understood many of the decisions that led up to the thing I was taking. Implementing an existing document or process, while easy, artificially limits your ability to address the problems your team is actually having, since it’s hard to figure out afterward which issues belong to the team versus which issues are a direct result of the process you just dropped in. And in the worst case, the process you just implemented creates new incentives that you didn’t consider and definitely don’t even want people thinking about, like Agile teams who become more focused on correctly sizing and completing work than delivering amazing customer and business outcomes. Or a Design Systems team who cares more about people following the rules than helping teams move quickly and simply.

Look, leading a team is hard work. And writing and designing your organization, and how it operates from scratch, can be daunting. But do yourself a favor: skip the shortcuts. Do the work yourself and iterate regularly. By doing that, you’ll become a better leader for you team far more quickly, your team will feel better having docs and processes that accurately reflect their work and experiences, and you’ll be set up to be an incredible and valuable leader at any future organization you join.