About this talk
Too often, the product design, product management, and engineering teams are thought of as three separate entities. This divide, according to Cap Watkins, the VP of Design at Buzzfeed, can lead designers to feel undervalued or even defensive when the product managers or engineers attempt to make suggestions to their work. Having realized this battle at Buzzfeed, Watkins proposed the question: “How do we create a culture of empowerment for design?”
In this talk, Watkins provides a step-by-step process to blur the lines between the different product building teams in an effort to get feedback on not only the work being done, but also the process on how that work gets done. Change is complicated and creating the internal partnerships will adjust the way people work, ultimately for the better.
Cap Watkins, VP of Design, Buzzfeed
Cap Watkins is a product designer living and working in Brooklyn. He is currently the VP of Design at BuzzFeed, as well as a blogger, podcast guest, conference speaker, and lover of start-ups and technology. He believes in thoughtful, holistic design solutions that get out of the way and empower people to accomplish more. His past work includes Etsy, Zoosk, Formspring, and hush-hush stuff at Amazon.
Hi. I’m Cap. I’m the VP of Design at BuzzFeed. And when people think of BuzzFeed, they think of maybe the website or something. But it turns out we do a lot of different things. So for instance, obviously like I said, there is the website where we have cute articles and all of our videos and content where you can find out how to improve your relationship goals. You know, like these rascals.
Get it? Anyway, we also make apps. We make a bunch of apps. So we have the BuzzFeed app, which is basically again, like the website very quarterly experience, has everything inside of it. We also last year, launched the news app. We have a huge news team with Pulitzer Prize winning staff. And they publish to this every day. And I highly recommend it. And then very recently in the last couple of months, we launched a BuzzFeed video app. And a lot of people, I don’t think, know that we make video. Or if they do, they don’t know how much or how big it is.
So we made an app to hold all of our shows together. And this is one of our shows called Tasty, which if you’re not familiar with Tasty, go on the internet. So Tasty is like a recipe video show. It has around 360 million people watching it every month. And all told, BuzzFeed does around 7 billion content views every month. So 7 billion different pieces of content are shared, or viewed, or watched, or listened to. And I do have to apologize, there was a rider on my contract that said no pornography. It’s pretty close. Hold on. Wait for it. So we’re making a lot of stuff.
Currently, I’m responsible for a few teams at BuzzFeed. I’m responsible for the product design team, the brand design team, and our marketing design team. And in the last four months or so, I’ve taken on our IT teams globally. What could go wrong? Probably nothing. The design team in total at BuzzFeed– So of the tech team The design team is around 18 in total. So that includes 13 or so product designers and a few brand and marketing designers. And when people ask me why I took this job at BuzzFeed– I get asked that quite a bit. They’re are a huge reason why. The designers and the engineers and the product folks at BuzzFeed are super thoughtful and talented. And I feel like the last year has been a really incredible time to be a part of the company.
Not just because of the projects that we’re working on because I think those are really awesome. But I can really feel the tech culture evolving at BuzzFeed and becoming more collaborative, and design having a much larger voice in that product and the processes by which we work. And when I talk to designers and managers about that, I always get the same exact question, right. Which is like how the hell…
That’s not the answer, by the way. How do we create a culture of empowerment for design? Not even that, but most times a lot of people are just trying to get their coworkers to value design at all. So how do we do that? So who here has ever been frustrated at work and thought one of the following things. So this is the first one. But I’m the designer. Right, it’s my call man. Or this one. I wish they’d just trust my expertise. I’ve been doing this for like 10 years. Like they should just trust me at this point. I went to school for this shit. Or this is my favorite. If you’re a designer out there and you say you haven’t thought this, you’re a liar. Ev Everyone thinks they’re a designer.
So here’s the thing. You’re all clapping, and that’s terrible. Here’s the thing about that. It’s like, I think we all know intuitively these are not good things to feel. In my experience, when we feel these things it’s coming from a place of disempowerment, and frustration, and not feeling like a critical part of a process with a product. And what a huge bummer to go to work every day and feel this way. So how do we fix that feeling? And how do we make things better? And when I’m talking to people about it, the very first thing I tell them to do is to set the goal. Like where are we going? Maybe somewhere better than you are. But to set the goal. I feel like when I say this, what I want people do is really think about it. But what a lot of designers and managers go straight to when ask them this question is something that looks like this, where design makes all the decisions. [LAUGHTER]
Which sounds pretty great, right? Look at that designer running over that product manager. She’s so pumped. She’s like, send me a spec again. I dare you. Sorry, I only have 15 minutes left. We’ve got to stop laughing. But what does this really mean? What does this mean for your coworkers? If you don’t like having unilateral decision making happening that’s impacting you, it would super suck for the people you’re working with. This is actually why I really hate terms like design driven and design led because I feel like it’s super narrow in scope of who makes those decisions and the frame with which we’re making that decision. So when I think about this problem, about where we’re trying to go, on at BuzzFeed and at Etsy, I kind of thought about it this way. Where we take a world that looks like this, where there are siloed teams working on their own stuff separately. And we make it look a little more like this. Or actually, really like this.
When I started at BuzzFeed last January, people were super siloed. We were in that very first state where a product manager would write the roadmap, and write a spec up, and then get assigned a design resource. And the design resource would design the spec, and then give it back. And then we’d get two engineering resources. It was a Sim City. It was great. It was actually very terrible. And I was really lucky because when I started at BuzzFeed in January of last year, they already knew there was a problem. They already were feeling the pain of that process. And they wanted to get here. They had already kind of defined this where we were going to go. And so over the last year and a half, this is where we’ve been moving towards. So knowing where you want to go is super helpful because then you’ll know when you got there.
But until you get there, it’s like I said, it’s a pretty long process. That stuff takes time. My advice is to pretend like you’re there already. Didn’t see that coming. It’s funny. If you start treating other groups like collaboration already exists or that the silos are just not there, it starts to become the norm all on its own. So you gotta invite other people into your process, into the design process, talking to them about what they are working on. So practically speaking, at BuzzFeed we do this a few ways.
So on a product level, we started integrating with design by using Base Camp. And I love Base Camp. It’s awesome. And it’s the most simple tool. And we document the entire design process from start to finish in Base Camp. And it’s transparent to everybody on tech. So all the engineers, all the product people, and all the designers can see all the work happening at any time. And what’s really neat about this is– This is a designer starting a thread, and there is no design work in this thread. She’s just talking about the problems, and the goals, and really just defining what she and her product person talked about.
And then as we start to go through the process there’s me in there, there’s like a couple project managers, a product manager. The VP of product chimes in. The designers finally post some work halfway through the thread. And that started to really blur the lines. We’re starting to ask people to give feedback and critique on our work but also on the process by which we’re doing the work. And that’s been really powerful for us. We’ve also started to blur the lines between design and engineering. I’m a really big believer that designers should code. And if you disagree with me, you’re wrong, and we can talk about it later. So anyway, at BuzzFeed they weren’t writing code. Designers weren’t writing code. They weren’t responsible for that. And a lot of them had never written code before in their lives. And so the first thing we did to get that going was we got a subscription for everybody to Team Treehouse.
Ryan Carson did not pay me to do this. We paid for this tool. And this was kind of an amazing experience for the designers. We gave this to them, and they were so hungry to get involved and start to again blur those lines that all on their own, they set up time together every week. They called this meeting Treehouse buddies. And they hung out every week, and went through the HTLM and CSS modules together. And within a couple of months, it was kind of magical to watch a designer who’d never touched code before start actually touching production front end for the stuff they were working on. That was insane. And so that was really cool. And then the other thing we started doing was building a CSS framework.
So this is our CSS framework at BuzzFeed called Solid. . I paired with one of the designers who was a really strong front end. And we started to build this thing because BuzzFeed’s code was really old and really bloated. And it was kind of prohibitive for the people who had not gotten into code before, to work in that system. And so we wondered if we could create something that was slimmer, and faster, and easier to use. And it super worked, and it’s in production now. And it’s like, I think we took the site that of CSS, and now this is 18 kilobytes gzipped, which is rad. And you can run the entire site on this framework which is super neat. The other thing we did was started this thing called design tweaks.
Who here has had this problem, where just like all these little things that bother you about the product, right? Something’s off by three pixels. We’ve all had this problem, right. Where like, oh that the spacing is wrong. It’s just a little off. And then you file the bug. And then it just keeps getting de-prioritized because the person who went to school for four years and got their computer science degree doesn’t want to do that shit. Surprise.
So now that we’re starting to code, we actually went through and found all those bugs in Jira. And we labeled them design tweaks. And we started meeting as a design team, as a few people every week, like two or three designers. And we got a front end developer to help us start to solve these bugs for a couple hours a week. And what was really neat, was again these designers who were just trying to learn could take something like, just add some padding on the right, get a little help, make the fix, push it to production. And now they are seeing the effect of the work that they’ve been doing. That’s really, really cool.
So, you know, we’re knocking down these walls, the silos are coming down. It sounds awesome! Everything’s great! Because it was fucking awesome. However, it’s also super painful sometimes to make changes like this. As we started engaging in the product and the code, we were asking other people to adjust the way of working. The way that they were working. And that makes people nervous. I’ve heard more than one time, if designers are writing code or if designers are being more product-y, what’s my role supposed to be. Because change is really complicated for all of us.
I’m not knocking the folks who have trouble with this stuff. I’ve experienced these feelings personally when there have been changes that I’m not the one enacting. And it can be really super easy to pretend that the people who are having a hard time are just stubborn or they’re assholes. And you’re just thinking to yourself, why don’t they get with it. Like, why don’t they come along. Right, let’s just do it. And we have to acknowledge that people have legitimate concerns, and empathize with them, and help solve the problems. And not only that, but make them our partner in solving the problems at all. You have to get them invested in the future we’re trying to build.
So for instance, I told the PMs that the designers are now being measured partially by their contributions to the product. And when we get to the mid-year reviews, I’m going to be asking them how they contributed. And hey, product person, you’re the domain expert on this stuff. You can help this person on your team level up and achieve the goal that they’ve set for themselves. And the same thing with engineering. And it’s kind of funny. The PMs and the engineers, we all work really closely together. We really like each other. And so they were more than willing to help out their fellow designer as soon as you explain that we’re not trying to take your job. We’re just trying to be better collaboratators. And the other thing is don’t make this partnership one way. We’re asking them to help us, and we also have to help them in return.
So that they’ll help us back. And so the way that I’ve done this at BuzzFeed is– The design team, when I got there, didn’t have any role documentation or career ladders. And I wound up writing one very quickly. It never stops. She never gets the cat up. Spoiler alert. So I wrote the role documentation. And then found out shortly after that no one had role documentation. No one had career tracks. And I think it would be really easy for me to stay in my little silo and be like, well that sucks. Like, sucks for you. Like, we figured it out, so have a nice time with that. But I didn’t. I shared the doc, shared what we learned. And I wound up helping other departments craft those roles. And then also help them like communicate it out to their teams. The same thing with recruiting practices.
We started developing really effective recruiting practices on design. And now those are tech wide because we’ve started to share that learning with other people. And then most recently, we started developing leadership principles for the whole team. So it started out as this project where we were getting not great feedback when we did annual reviews for the designers. It was pretty shallow. And we wanted a rubric that we could send out to people that they could use as a way to– here’s what we care about. Like, tell us how this person is doing this or not doing this. And it was really effective. We start to get really rich feedback. And I started to get asked for this document by other people. Other engineers were looking for it. And so I started sending it out. And at one point, one of the engineers took it, did a find-replace, and replaced “design” with “engineer” and was like, it works! It still works. We should use this. We should use this for engineering. And at that point, we realized that there was an opportunity to really break down the silos and make something that was really holistic for the whole tech team.
And so now we’ve taken this design leadership principles doc and destroyed it basically and created tech leadership principles which we’re using across all of tech. And in the next few weeks we going to start using it for everybody for mid-year reviews which is super insane. And so helping out in these ways has helped us build a lot of trust with other teams. It’s helped us forge stronger relationships across those departments. Even now though, there are things that are not the way I’d like them to be. They don’t always go exactly the way I’ve planned. There’s a lot of friction sometimes. And at those times, I think it’s really important to be able just let shit go. To not get just– No one here was from the 90s? Yeah, the two people in the back. You can’t get discouraged.
You gotta play the long game. If you get caught up in things not being perfect right this second, you’re going to hurt your chances of reaching that ideal place. And it’s really important to learn when to go to bat for things and when not to. So Etsy I worked with this engineer named Andrew who helped me develop this scale that I use all the time now. This is a real scale. It’s not a joke. So Andy and I are working together on a project. And he was the lead engineer, and I was the lead designer. And Andy really cares about design. He has good design sense. He likes to talk about user experience a lot. And so he brings suggestions to me. And this is a point in my career where I felt like, that thing earlier. Like, I’m the designer. Like, this is my call. And so we go back and forth about stupid nonsense for a long time. Like, is this button on the left or the right. And I’d be like, it has to be on the left. That’s the crux of the user experience. And Andy and I would go back and forth for a long time. And finally, there’s one day where he and I are just arguing about some stupid nonsense. And Andy says suddenly, he goes, wait, wait, hold on. I’m like a two out of ten on this. What are you? And it took me a second. I kind of thought about it. And I said you know, I think I’m like a six out of ten And Andrey goes, great, we’ll do that then. No problem. And walked away. And it really highlighted for me that– I kind of looked back, and I was like, I’ve been a ten on every single thing, like ever. Because I’ve had that chip on my shoulder and I haven’t been very collaborative, I had that like– I’ve been fighting every fight for no reason. And this has really helped me. I actually use this in my daily life like every single day. Not just mentally, but I’ll actually say to people, here’s my opinion. But I’m like a two on this.
So whatever you think is best is great. Or like, hey, I’m an eight on this. I feel really strongly. Can we just make sure we talk about it before we make a final call? And what’s interesting about that is it kind of signals to people that you’re not always a ten. You’re not always fighting just to fight. And that you’re willing to give in. And you’re willing to admit that your opinion is not that strong. And that, again, is all in service of building more trust with the people around you. Which leads me to– I think this changing of culture takes a long time. Like it’s a lot of little steps. And it leads me to the last point, which is you’ve got to be really patient. Both with ourselves and our teams. I have a one on one every so often with this product manager from another company. She and I get together to share challenges because neither of us knows who we’re talking about.
So we can say anything. I highly recommend that. And she was telling me she just started this new job. And she’s running product. And the product roadmap was a mess. And she’d been there a couple weeks. And she was telling me she seemed really hopeful. She was like, in the next three or four months, we’re going to win some hearts and minds. We’re going to change some things. And we’re going to be on track. We’re going to have a great product roadmap. We’ll be going where we want to go. And I was like, sounds great. A few minutes later, we keep talking. And we start talking about her organizational structures, and the team, and how the teams are put together. And she just totally changed. She was like, I don’t understand. We all know what needs to fucking happen with this team, so why don’t we just rip the Band-Aid off. We all know what should happen.
So why don’t we just do it. I thought it was so interesting. We’ve been taught as product people to have a goal and to iterate our way there. To step our way there. To be patient about that goal. When we fail, to get back up and keep going and to iterate and learn. And iterate again. Why should our organizations be any different than out products? It’s been a year and a half at BuzzFeed and we’re not there in a lot of the ways I wish we were. We’ve made a lot of progress though. We’re changing minds. You can see it in little ways and some big ways. And if I got hung up on like, to get it done right this second, I would really block myself. And so I know this talk’s really hard for people to hear, in general, because a lot of people are out there sitting there and thinking like, this is super easy for you to say, Dr. VP of Design. You’re like, I have the power to do things. Like, maybe you’re sitting there and thinking, I’m an engineer. Or I’m a designer. Or I’m a product person. And I just don’t have it. I can’t do any of that stuff you just talked about. It’s the shivering that really gets you. But you know, the truth is that you’re wrong.
It doesn’t matter what level you are. It doesn’t matter what team you’re on. It turns out that leadership is not a role. Leader is not a title that anybody has at any company I’ve ever been at. You can always be an advocate. You can be a collaborator. You can be an idealist. You can create change locally. Like if you’re on a team of five people in a large organization, if you make that the best fucking team with the best culture to work on, now you like going to work every day. And I see this over and over again where, when that exists, people around it start to look at it and try and unpack it. And try to figure out what’s happening so that they can recreate it in other places in the organization. We have to stop only designing for design of the products, the graphics, the ads. We have to stop only empathizing with our users. We have to start treating out organizations, and our teams, and each other like user experience problems, like real life user experience problems. We have to design basically everything.