Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I have the pleasure of talking to Cap Watkins. Cap is the VP of Design over at BuzzFeed. Of course, Cap used to be at Etsy. He's worked with people like Amazon. He is a very knowledgeable guy. He writes quite a bit about design and about teams and all of these things that most of you are probably interested in. And if not, you should be. So I will include a link in the show notes, or quite a few links actually, which you can find at spec.fm. So let's get to the interview with Cap Watkins. Thanks so much for coming on the show, Cap. Yeah, sure. Thanks for having me. Absolutely. You were on Design Details twice now, so I feel like it's time that you've made the round onto Developer Tea. I'm really excited to have you. Yeah, totally. I am looking forward to the hat trick. You tweeted that you would have hopefully some software development jokes up your sleeve. Oh, I forgot to look those up. That's really upsetting. I can tell you the joke I always use. I've used it at Etsy and at BuzzFeed a few times now. Whenever there's an argument going on about database stuff, you hear developers talking about this stuff that I don't totally understand, I'll always break into it and just say, Hey, have any of you considered trying to... I'm trying to find an outer left join on the database. And the responses range from laughter to just looking at me like I'm a complete idiot. You know, you could be right sometimes. Well, actually, it's funny. At Etsy, I probably shouldn't tell the story, but at Etsy, pretty early on, I'm on the tech threads with all of engineering. I don't know how. Still to this day? No, no, no. Pretty early on at Etsy, I was on this thread, and the thread was about something to do with databases, going back and forth, a bunch of engineers replying all. And then I reply all. I'm pretty new still. Nobody really knows who I am. I reply all, and that's all I write. I write the, has anybody considered an outer left join? And everybody ignores me for maybe an hour. They just keep talking, which is what they totally should have done, until suddenly the CTO, Kellen, replies. Right. And writes. And writes a couple paragraphs about why we don't do joins in the database. And I was like, I was mortified. I was so upset. I was like, oh, my God, I just totally screwed myself with this job. And so I emailed him back privately and was like, hey, so I'm the new designer. Want to go get lunch? Yeah, I'm the new designer. I'm so sorry. I was just telling a joke. And at some point, he laughed. At some point, I think. Now, whenever he and I talk, it comes up. You're the left join guy? That's right. I'm that guy. Yeah, it's like on Parks and Rec, how Ben gets the, he's always talking about calzones. Yes, right. If you're familiar with this. Yeah. Anyway, people hate calzones in that show for some odd reason. I love calzones. I do love a calzone. It's like a pizza sandwich. I don't know what else you want. What else can you ask for? Well, I first found you, Cap, through your blog. And on your blog, you write lots of stuff. I do. I write a lot of stuff. That's the easy way to put it. You write quite a bit. How long have you been actually writing and publishing content? That's a good question. So that, I mean, I feel like I've been starting blogs since I was very young using Word. I watched Doogie Howser as a kid, and I tried to do like my own little like journal in WordPerfect. You know, like the blue screen WordPerfect. It was great. And of course, it lasted like 10 seconds and I stopped doing it. Sure. This particular blog. So ever since then, I've actually had different blogs about different things. I blogged through college about just personal stuff, so I wouldn't have to call my parents every week. Nice. That's what I used to use Twitter for. Yeah, we didn't have Twitter. Mom, if you want to know where I am, I'll just tweet my location. No Twitter. No Twitter in college. Yeah, yeah. But yeah, so then this blog I started in 2012, I think. So maybe like early 2012. And so I guess that makes it three years now. Almost. Almost three years. The interesting thing that I've found is that so many of your articles end up applying not only to designers, but pretty much anybody in business, including developers. So if anybody's considering whether or not you should read Cap's blog, definitely do. But there's been a couple of articles that I've really enjoyed. One was The Scope. I think it was. What was it? Scope? No, Scale. The Scale discussion, which I think you had on Design Details. But can you kind of share that epiphany moment that you had with the listeners of Developer Tea? Oh, The Scale. That took me. I was thinking you meant like scaling something. I was like, no. I was like, I don't know what he's talking about. No, it's The Scale. That's what I thought you meant when you were on Design Details. I was like, oh, he's going to talk about why it's not a good idea to scale something that never needs to be scaled or something. Nope. So, yeah. So there's this. I guess I'll start with a story. So at Etsy, I was managing folks, but I was still designing for a while because I just didn't have that many people to manage. And, you know, I was kind of spinning up. And so I was working with this engineer named Andrew, who was very, very talented. And it's funny. Like, as a designer, I think for a long time I've had a chip on my shoulder about design, you know, being like a respected. And like, I mean, I don't know. When I was a young designer, like, it was very much like, hey, can you just like make this look good was something you got asked a lot. Yeah. And so I spent a lot of time really early on kind of fighting like engineers or like product people or whatever to try to like, you know, be like, no, no, no, this is important. And it's not just that. So, you know, Andrew and I would, you know, I'm going to use the word discuss very lightly. We would discuss the features we were developing together. And sometimes they would just go on and on and on. And it was like really, I mean, at times, very stupid, like minute things like, like, where should this button go? And we would talk about it for, I swear to God, like 30 minutes. Like that chip on my shoulder thing was really making me feel like it was important. And one day, Andy, we're in the middle of something, you know, about that. And he just goes, he just stops me. And he's like, whoa, whoa, whoa, whoa. He's like, I'm a two out of 10 on this. What are you? And I was just blown away. I had no idea that I could rate my feelings about things. I didn't realize. It's binary. No, yeah, totally. I always felt like it was zero or one. Yeah. I felt like this is like either I have nothing to do with it or it's really important. You know, it's like that's, that's the, it's a little hubris, I think. And I said, uh, I, I mean, I guess I'm a six. And he goes, okay, great. We'll do what you want to do. And he walked away. And ever, and like, you know, I thought about that for a long time. And ever since then, like I've taken to kind of rating my feelings about things on this scale from one to 10. The article was about like basically how many fives. Do I give about this? It's okay to curse, right? Some people feel a little friction and feel like they need to push it back against that. As opposed to, I think there are a lot of times where it's probably a better idea in the short term and even the long term to kind of let stuff go. To just be able to say like, look, I, I actually don't feel that strongly about this. This isn't that important to me. And it seems to be really important to this other person. So I'm just going to let this, you know, I'm gonna let this thing happen. And I think people get really nervous about that idea. Like when I talk about it, because they think. Oh, well, if I give a little bit here and a little bit there and a little bit over there, like, you know, all of a sudden that adds up to this huge, terrible thing. Right. But it is in practice. It never happens that way. It just so rarely happens that way because these little things just as long as everybody's in it for the right reasons and they're all trying to make things better, which generally I think people are even like a decision to disagree with is not like the worst decision. There are definitely worse things that could happen. Yeah. So it's actually really interesting that you talk about that that way, because, you know, as a software developer, a lot of the time I feel like the decisions that I make or the opinions that I have are either right or wrong because, you know, performance is a thing and code actually functioning. That's, you know, that's an important part. But there is a lot of opinion that goes into even software design. I mean, we have we heard the term refactor. Exactly. How many engineers get into somebody else's code or into their own code a month later? I will go to refactor this. It's not that good. You know, it's just this stuff. It's never, you know, perfect. There is no right answer. Well, and the reality is and this is this is really kind of the theme that I want to focus on here in the first part of the show. It's it's all writing. Right. So whether you're writing a blog post or you're designing something, you know, you're designing a system or if you're writing software, a lot of it is is some kind of writing. It's involved some kind of, you know, taking your thoughts and putting them into a form. And whatever that form takes has a lot of your fingerprints on it. So if you're, you know what, it could even be as simple as, you know, how you name your variables. And quite honestly, that is most of what CSS ends up being. Right. It's the naming structure of your classes. It's not, you know, is it going to function or not? If your CSS doesn't function well, it just literally won't work. Right. So we all write good CSS in the in terms of functionality. It will work. Sure. But then, you know, sometimes it's, you know, two megabytes or something. Yeah. Yeah. It could be huge. But even if it was small and you wrote a bunch of, you know, gibberish, then that's not really, you know, quote unquote, good CSS anymore. Even if it has the same functional effect. Yeah. Totally. I mean, it's it's all degrees. Right. You know, it's, you know, I. Yeah. Someone told me once what what ships wins. And I think that's pretty interesting. I think so. You know, it's better to ship gibberish. It's not if it's functionally correct. Like if it works, it's better to ship that than to than maybe to spend a lot more time shipping, not gibberish and to unpack that over time. You know, I think people think about this stuff in terms of, you know, we'll never touch this again. Oh, yeah. I mean, I know. I know designers feel that way a lot of the time. And, you know, I mean, sometimes I mean, you know, never is a long time. That's, you know, that's a very long time. And I mean, a year is a long time. A year is a long time. And I think that that's actually that's sometimes true about, you know, yeah, we're going to ship this and, you know, do a couple iterations and we're out. And so people feel a lot of pressure to, like, make it the best thing it possibly can be. And I think that's where a lot of the tension comes in, as opposed to, like, what is the best version of this in the time? That we can allot to it. You know what I mean? And then, like, also, like, again, as long as it's working, do we really need I mean, how much do we really need to squeak out of this or eke out of this thing? Yeah. You know, so I think, again, it's just all degrees, right? If some I mean, there's a difference between, like, oh, this is so terrible. It doesn't work at all. Or this is so terrible. And the page load just doubled versus like, oh, like, it's terrible. And I would write this a little bit differently. But there's really no gain. Right. Yeah. Yeah. And and it's like. You know, there's a little bit of pride involved with it, too. Right. So especially in that very beginning, you know, if you if you actually are not going to be shipping this thing, you know, if this isn't the only time that you're going to ship. Right. If it is indeed like most Web projects are iterative, just naturally, you're going to change this thing next week or next month or even next year. Well, getting it right the first time is a product of a couple of different things. I think one of those. It's certainly, you know, craftsmanship pride. I don't want to write code that's bad. And so if I ever let code out into the wild that has an inline style and somebody sees it, surely I'm going to lose my job and be crucified. You know, I can't do that. Right. We've heard of React. Right. We're all working with React. Oh, that's not fair, though. I actually ran into a really interesting problem the other day. We were talking about that, about having React and doing inline styles. I said, well, how do you do hover effects? And it was like a moment of wait a second. That's where this thing kind of breaks away from our traditional thinking of CSS. Interesting. Is, you know, now you have to write a function for responding to hover rather than just a rule. Huh. Yeah, I haven't played with it that much. That actually makes a lot of sense, though. Yeah, because basically what it does, for those of you who are interested in this, I recommend going and watching the talk about it. That kind of justifies the reason why I've loved the talk. Is because he talks. About, like, questioning your assumptions and questioning best practices that you accept just because they're there. Right. And because a lot of people have said they're best practices. And so he, you know, he looks for ways of applying styles in realistic and, you know, acceptable ways that kind of go with the methodology or philosophy of React. Which is, you know, everything has a state and we're bundling it all together. There's a lot of view. There's a lot of stuff that goes along with state. So why not go ahead and throw the styles in at the same time? It's basically the same thing as writing CSS. And that's true up to a certain point. Right. And hover is one of those points. That's curious. Yeah. Yeah. Overall, I think that is a really interesting direction. I would love to see how that particular problem gets solved, if it gets solved at all. Now, I know that a lot of the intention behind pretty much any web framework now is to focus on mobile. Right. And hovering isn't as much of a thing on mobile. Although I'd be interested to know what you think about this, about 3D Touch enabling some kind of mobile hover state. Oh, boy. I feel like that's probably, I mean, we've just invented double click for our phones, which doesn't, sorry, right click for our phones, which doesn't feel, I feel bad knocking it without using it. I feel like that's something I wouldn't, I shouldn't do. But I mean, just even watching. Well, it's what we do, right? Well, yeah. But even watching the demo where it's like, oh, you press on this icon and you get a flash. Buyout menu. It is right click, which means that most people won't discover it. Or if they do, it's an accident. They will be trying to do something else. And then they'll be like, what is going on? Like, what is this thing that I just did? Again, like without feeling it, it's hard to know. But it feels like a little bit mystery meat to me. Like, how many things am I going to press on to just see? You know, I mean, like, does this have a thing? Like, how would it invite me to do that? Well, and how frustrating it will be when you see a UI that you think should do it and you try it and nothing happens. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. It feels like a soft touch action. Right. Exactly. Or like it does something unexpected that you did something that is not what you needed. Right. It's going to there's just a lot there where like I feel like phone UI. What made it so great so far is that it's like it's so it has made it so important to be so incredibly articulate in your design. Right. Your design has to be so clear and like concise about what's happening. And this is one of the things we're like, oh, we're going to add this extra layer on top of it. I mean, I guess for power users, but I don't really. I mean, I don't know. Context menus are a fix to a problem that never really existed. I feel like like the issue is all of that stuff is hidden until you until you dig. Right. Right. And we know from so much research coming out about things like the whatever the hamburger menu. You even said, you know, the discussion on design details about the cogwheel, it being a flower. I didn't know what it was, you know, obvious design. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. was everything that you could do with that already existed in a very obvious way in the UI. So the apps that won't do so well are the ones that are going to bury functionality underneath this thing. And the ones that do well are going to be like, oh, well, this is an extra way or a shortcut to get to where you want to go. And that's all we're going to do. And I think that'll be fine. It's fine. You know what I mean? I actually hope it's super useful and helps me use my phone faster. But I don't know. We'll see. And it could be even that it's really useful for some people and they may not even be the power users. I saw a tweet the other day. Somebody has an Apple Watch. I can't remember who it was. But they said even to this day, they've had it basically since it launched or whatever. And to this day, they haven't used the crown at all. Oh, wow. For scrolling. That's so interesting. Yeah. And I thought that was so enlightening because here you have this device that's already pretty limited, right? And you would think that you would have to use everything on it for it to be useful. But that's not true. That is interesting. Yeah. I haven't tried the Apple Watch yet. My wife has. And she wore it for a few weeks. And then I think she spent a weekend without it and never went back. And my personal feeling about it is just like the reason I don't want it is... And I know you can control this, but it kind of, I feel like, loses its function if I do this. I mean, I leave my phone on do not disturb all day. Like it's a 24-hour thing. So my phone doesn't buzz ever because I don't want it to. I don't want anything vying for my attention. You know, I think like for a long time it was in my pocket and buzzing and that was nice. But I'm at a point now where I'm kind of like I want to check this when I want to check it and not check it because it's buzzing at me. And I feel like that's the thing that the watch does is like it says, okay, well, you can check it without taking out of your pocket, but I don't want to check it. You know what I mean? Like I don't want to get... I do not want to get alerted. I don't want to know. I'm the same way. I literally... I'm the same way. I literally... Right now I have my phone on Do Not Disturb. It's really magical. It's life-changing. If anybody out there has not done this, I guarantee you like go for like two weeks. Just like put it on Do Not Disturb. You can set it up in settings, 24 hours. Just set it up for 24 hours for like two weeks. And it's just like it's magical. It's so freeing. And you realize all of a sudden that like nothing really matters that quickly. Because like if someone's in your VIP and they call you twice, you get the call if it's super important, right? And if someone texts you, it's, you know, it's on your VIP list, it still comes through. And like everything else just kind of is there for when you're ready, not for when they are ready. Do you know what I mean? Yeah. I've talked about this quite a bit actually on the show. The concept of focus, which you actually talked about turning your phone on Do Not Disturb in your post about focus. So I thought that was an interesting overlap. But I basically, everything that can push to me, I turn it off. And instead I have this concept of pulling rather than pushing. So going and getting my email, going and getting my text messages, you know, listening to voicemails rather than answering unknown numbers. Like if you really need to get a hold of me, leave me a voicemail, you know? Yeah, I don't know. I actually like the notifications on the lock screen so I don't have to open my, like it's one of those things where I can look at my phone again when I'm ready. I can look at it and then make a decision. Yeah. I think that's kind of conceptually the same thing though, right? Of like limiting the incoming noise. Yeah, no, totally. I just think there's like, you know, like logistically, like when you're, if you don't get notifications and you open your phone, you have to start pulling for all that stuff to figure out which apps have stuff in them. You know what I mean? And then like, I think like what I like about the lock screen, what I don't like is the buzzing. What I do like about it is like, I can quickly like scan it and be like, no, I don't care. You know, like it makes it really easy for me to say, I don't care about this and like put it back. Well, and the only one that I really leave on is text messages. And then I think I accidentally recently turned on Twitter again, which, you know, a blessing and a curse, a blessing and a curse. Yeah. Well, you just press okay to so many, you know, things that pop up. By the way, be aware of those things. They mean something, you know, when you give something access to stuff, it has access to stuff. Now I have text on my home screen. You said something very salient. I think you, you open the lock screen and you say, oh, I don't care about that. I found myself saying that constantly. And I still do this with my email inbox. I just check all unread, read and mark as read. Yeah. Like constantly. Yeah. Why am I even getting these emails? I feel like I get a little, uh, and like, uh, adrenaline rush by saying, I don't care about this. It's like one of those like endorphin hits, right? It's like, I pull out to look at and be like, I don't care. And then I feel good. It's like you can say no to something. And that makes you feel like you said no, no to something. I'm in control of my life. I turned off my phone. You know, it's like, how sad is that? It's, it's, it's, it's, it's, it's, it's, it's a life away cap. I'm, I'm okay with that. I've come to terms. So the idea of everything being writing, now that we're back after that diversion there, you know, you write a lot of blog posts, but you also internally listening to the design details posts, you talked about how you write justifications for your designs. And this kind of works as documentation of the work you're doing. And I'd love to explore this idea a little bit with you and ask you, you know, why do you write justification for designs? Number one. And number two, what does that look like? Is it like a quick note after you work or is it, you know, something more in depth? Yeah. I, so I think there's a couple reasons to do it. I think the biggest reason that we do that stuff at Buzzfeed and at a, and we did that at Etsy as well is like, actually I did that at Amazon too, I guess. But, uh, a lot of it at Etsy and, uh, Buzzfeed was a lot about transparency. You know, we're working on teams and in a lot of cases, like working with, like across teams or working on things that touch other people's stuff or working, you know, in an environment where someone may not know why you're making the decisions you're making. And so I think like one of the biggest things about documenting, not just writing down like justification for the design or even the product that you're working on, it's important for you, but it's also really important for other people to see, uh, so that they can contextualize the work that you're about to share. Do you know what I mean? So like, so we use Basecamp to document all the design work at Buzzfeed. All the designers are on all the threads. Uh, the engineers for each team are on the individual threads for the products that they work on with those designers. Uh, the product people are on those threads, whoever, basically whoever wants to have insight into what's going on has access and every post. So every thread, the designer starts. So a designer will start a thread for a new feature, right? Be like, Oh, we're going to redesign this page. We're going to resign the homepage. Right? I think a lot of designers do this thing where like, they're going to redesign the homepage. They have a conversation. They start designing. Like they start like working in sketch or Photoshop or, or illustrator or whatever. And then, you know, a couple of weeks go by, they have some review meeting. They show this work to the product person. Who's like, what, what is this? Let's make these changes, whatever. Um, or try again. And then, you know, two or three weeks later, they're like, okay, everybody feels great. And then they throw it over the wall to developers. And, uh, and then the developers go, there is no way we can do this. We, we cannot do this. Are you crazy? And also we think you're wrong. You know, it's like, there's like all these, there's pieces to it. And so by pulling everybody into the base camp thread, first of all, you get this transparency. But the second thing that happens is when you write these, this first post in the thread, every single time has no design work in it. Like you haven't started doing design work yet. You've had a conversation with your engineers and your product person. You're writing down, uh, three things. You're writing down the problems you're trying to solve. Uh, so you give a quick intro, then you write down the problems you're trying to solve, uh, the strengths of the current thing that you're replacing or trying to improve on. If it exists, right. If they're, if you're, if you're trying to improve on something, you want to not lose what was good about it. Right. Uh, and then the third thing is, uh, like we call them tenants, uh, but they're really like goals, right? Like design goals. I think it has to be product goals. So it's, or engineering goals, right? So it's like a goal could be, we don't increase conversion on this page, right? That's like, that's a goal. That's a measurable goal. Like another goal might be like, make it clear what's going to happen when you submit this form. You could probably measure that with conversion, right? But like the design goal is to make it clear. And so you, you start to set up these tenants, uh, around what you're hoping to accomplish. And so now, like before you've done any design work, right? You post this thing, the engineers see it, the product people see it, the designers see it. And this is that moment for everybody to, to like disagree or to say, you know, your product person might say, Oh, actually you misunderstood like in our conversation, what I meant, I actually meant this. Um, and the engineers might say, Oh, well actually like, I don't think this thing is as important as this other thing. Um, or here's a problem you didn't think of, you know, and you can, you have that conversation upfront before you've done any work. So you have that conversation and then like, you know, you kind of lock in. And now what you have is like something you can refer back to with every single iteration of design that you do, uh, to measure basically, or am I solving these problems? Right. With this design, am I adhering to these tenants? And if not, why not? Right. And there's been so many times when I've done that as a designer that like you wind up changing those things as you go, because you start to, uh, you know, you're uncovering things. You're just, it's like discovery and exploration and you start to understand more about what's happening. And so you change or add or delete from those lists as you go based on what you're finding, right. Or what an iteration would tell you. It's a really nice way of including people and articulating and also documenting for transparency, like the design process for junior designers, particularly, I think it's a really good way to force yourself to think. I think Daniel Berka posted this the other day that he had, he found, found something where it was like the difference between a junior designer and a senior designer. And like, it was a chart of like the process and how long designers spend in each part of that process. And like the junior designer spent less time in discovery, more time doing the design work, like in Photoshop and sketch or whatever. And then, you know, the last bit kind of like, you know, iterating or whatever. And then like the senior designer, the like time spent thinking was like exponentially longer. And then the time, actually executing was shorter. And then, you know, iterating also was like there. And I think it's just like, how do you take a junior designer into like towards that is like, this is the way to like, this is the forcing function, right? To be like, we're going to write these doc, this documentation. So sit down, think about it. That actually touches on a few different things that I think are really important, especially when it comes to how this intersects with, you know, developers or whatever system admin is, is this idea of, like you said, transparency, but overlapping, this feedback loop so that the, the problems can be addressed early because design is everyone's problem, right? Like you, you don't have an engineering team just to execute on a visual thing, right? That's not the point. The point is that you all are kind of working on one problem together. And when you have a team of people that have the ability to, you know, seed into this concept or seed into a conversation about something, it, as long as it's moderated well, and you aren't doing, you know, the evil design by committee, which I'd be interested to hear how you avoid that. But that, that kind of conversation can help the design actually, you know, avoid some of the pitfalls that otherwise would fall into. And it's not, design is no longer just sitting in Photoshop, right? It's it, the design, sitting in Photoshop is just an expression of the design. Yeah. I mean, I think, I think people tend, tend to have a little trouble when it comes to, I think the term ownership tends to be a problem. Yeah. Across all disciplines really. So I think what this starts to break down a little bit, like even just the space camp thing, like it starts to break down these walls between not even just design and engineering your product, but like product and design engineering. Right. Because like that first post isn't about design. It's not like it's about the product. Right. And like what we're doing and why we're doing it. And you know, this is the chance, this is like an opportunity for, first of all, the designer wrote the post. So like they are clearly trying to articulate the product vision. Right. And then the engineers now, if they didn't before also have an opportunity to respond to that, you know, respond to that and to engage in a product discussion and not an engineering discussion and not a design discussion. Right. And I, and later we're going to talk about designers kind of working in code with the engineers. But like, I think the goal, like a goal that I have, with teams. And I think a lot of people, I feel like a lot of people share this as like trying to break down the silo, right. Like just trying to break, like these things aren't just touching. They're actually right on top of each other. You know, it's like every decision an engineer makes has impact on the user experience. Right. And the product and the future of that product and how easy it is to iterate or how fast it is, or if it works in a certain way or how it throws errors or whatever. This is, these are all things that matter. And are part of this, I mean, like kind of what you're talking about, this like singular thing that like there's no owner of a discipline. It's just owners of the product, right. Of the final product. So you mentioned the throwing over the wall and I, for whatever reason, had this kind of a vision of like, you know, a product being like a child and the design team being the mother or the father, whichever one, I'm not trying to make a big deal out of that, but, and then the development team being the other, right. And you can't parent, you know, one version of the product. Versus the other or one completely separated from the other without actually communicating. Like you can't look at things as completely separate as much as we want to componentize everything because it makes for whatever better efficiency or, you know, we have plug and play kind of conceptually we can work on our own silos and then, you know, interface them together. Ultimately all of that is just a facade for one big working system. And, and each thing definitely affects the other things. And it's all just framing, right? I mean, it's, I think framing things as I think we say things like product owner or, you know, these, the engineers own the code base or whatever. I think there's these, like these words of ownership, but it's really more it's, it's expertise in a tool, right. And a way of thinking and using that tool. Right. So for an engineer, that tool is code. And for a designer, that tool is, you know, user research or, you know, sketch or whatever. Right. And then, you know, product manager is, I mean, this is no small feat. It's going to sound somewhat sarcastic, but it's like JIRA is something that's very hard to use. And it's like, and it's a really powerful tool that can really help your team. Right. Or, you know, even just like the soft skills that a product manager comes in with expertise, right. To help manage things and make sure everything's on track and stuff. I think there's just like, everybody has these expertise bits, but it's not ownership, right? Like it just because engineer owns the code doesn't mean, or is the expert in the code doesn't mean that like a designer can't do that. Or just because a designer works in sketch doesn't mean that they own the design. That seems crazy. Yeah. Well, because again, it's, it's, it's viewing it as discrete things. Right. And while certain expressions may like technically, I guess you could say that a code file is not the same as a dot sketch file or whatever. They all are contributing to a final, I don't want to use the word experience, but really that's, that's what it is, right? It's, it's, it's a final thing that, you know, everything culminates to that. When the user interacts with this thing, what happens? Yeah, sure. Okay. How often are you actually designing? Cause I know as VP, which you mentioned, there's not a P of design, but as VP of design, a lot of your job is, is hiring, right? I mean, it's hiring and management and strategic thinking for the team and the organization. Um, I've been doing a lot more, more work on, uh, developing like our, uh, professional development stuff for tech, but for the tech team generally, um, just kind of like, how do we support people as they grow and what, uh, you know, what kind of stuff can we put in place for people to do, you know, to feel like, you know, they're progressing in their job and career at Buzzfeed. Um, and like, so my job is actually, I don't do very much design work anymore at all. I am like, I'm still working pretty closely with the designers on the, uh, CSS framework and style guide that we've been working on. But other than that, I'm not really doing, I'm not really opening a sketch anymore or, uh, or doing any, I mean, also like I was doing some branding work, but we've just, I just finally hired, I hired someone who's much, much, much more talented at that. And, uh, and so it's a good thing to be able to say is, Oh God, I feel so good. Um, I, you know, that thing where you're doing something in the entire time you're going like, I shouldn't be doing this. I shouldn't be doing this. You just know it's not going to be good. But he's amazing. And so he's like spinning up and, uh, starting to take on more and more of that stuff. So like there's going to be a day, not that soon from now where I'm pretty much just, you know, managing period. So it's actually a very exciting day. I'm pretty pumped about it. That speaks to what we were saying earlier about design, not just being the execution moment necessarily, but the entire kind of holistic team. That's an important part of what happens to the design, right? Like you, you have to have that backing experience first of all, to be in the position that you're in, but also, you know, by, by putting the team together in the way that you were doing it, that actually has a, a lasting and cascading effect on the ultimate thing that you're building. Yeah. I mean, it seems to be that way. Um, I don't know. I mean, this is why people either get into management or don't get into management, I think, uh, or they get into management and hate it. I think I'm very good at knowing that I'm not very good. At things. Um, I'm like, I, I may be some sort of, everybody has this imposter syndrome, but mine may be, you know, one of those things where I just am always concerned that I'm not doing it so well. And so I get very excited when I find people who are very good at what they're doing because it just takes a whole ton of pressure off of me. Uh, you know, and I think it makes it really easy to empower people, you know, to hire. Well, like makes it really easy to empower folks when they come in and makes it really easy just to like, I'm going to give them more and more rope, you know, and just give them more and more ownership. Over what they're doing. And I think when you, there are managers who have a hard time with that. I think the, the folks that are very, uh, are more into making things, they have a hard time letting go of that, you know? And I think, uh, especially the folks, I particularly think the people who are extremely good at this stuff, like have a much harder time, right? Because like, all they want to do is go like, no, give that to me, you know? And they want to like do it or like direct it like very, like, you know, like a micro level. And I think, you know, it takes practice, I think. And, uh, to kind of just, again, like rate those things from one to 10. Yeah. Yeah. Great. This thing's kind of okay. Like they probably know that I probably know that, but how much do I really care? And can I let them kind of like have this experience? Our CTO at Buzzfeed after nine years, just recently left the company and he was giving his last lecture, uh, in his last week before he left. And someone asked him what the hardest thing or what the most important thing he learned was, or one of the hardest things he had to like figure out how to do. And his response was, I had to learn to let the people I manage, fail. Like that has to happen. Like I have to let them fall down and pick and like actually pick themselves up and like dust themselves off and keep going and then be there for them to like help them obviously. Um, but if I, you know, if I tried to make every decision for everybody or try to, you know, be in impact, every decision for everybody, like I would, like I would go crazy and then I would drive them crazy and they wouldn't ever learn because they would never have actually like experienced what I've experienced. You know what I mean? Like I've been very lucky to experience like I'm talking about me now, like just like hopeful like failure. Yeah. I was actually going to ask you a question about that, but go ahead and finish and then I'll, I'll ask the question afterwards. No, I mean that's kind of it. I mean I think, uh, yeah, I just think being able to hire people, I think like it just makes, that makes me really excited because I like to hire people who feel who are resilient and uh, who can fall down and you know, just keep going, you know, like, they just won't, they, they have too much, uh, momentum and energy to like to just lay there, you know? And like, right. I think it's really important. And when I hire on my end, I've experienced people who are too afraid to do anything for fear of early failure. Right. So like, you know, and that often is debilitating. And so part of that is creating a, well, creating a culture, I guess, but making people feel safe in their failures. Oh yeah. You, I mean, the goal should be to fall down as fast as possible. Right. Yeah. The sooner that happens, the like the better, right. With the understanding that your goal isn't to fall down. Right. But that it will probably happen. Yeah, totally. I think Etsy did a very good job of that. BuzzFeed does too, but I think, uh, that's kind of where I learned that it was, um, I mean, running experiments, like actual like web experiments will like, if your company does not have a culture that can absorb failure, like you're, you're going to have a bad time because like, I would say a vast majority of the things that we tried at Etsy, like didn't work. Like, you know what I mean? Didn't do what we expected or didn't like it did poorly or didn't do anything. Right. Just like zero, like just like a total neutral change that didn't help or hurt the company. And what a bummer. It was just there. It was just there. And it was like, Oh, okay. Um, but because like Etsy didn't just, like say that was okay, but encourage that sort of thing. People like sped up to fail. Like, in fact, like we started trying to break down problems to find out like, what's the smallest thing we could do to be wrong? The fastest, what's the fastest way we can learn how wrong we are. Um, and I think if it's baked into the culture like that, even down to like the product level where that is how you do product planning, even like that's where it starts to become like, it's not failure anymore. Right. It's learning because the goal and the, the distance is success. Right. And if, if you're looking at these microcosm, like these micro failures as like the end, then yeah, you're screwed. But if like, if these little micro failures are actually like, because you are working your way towards this much bigger tour up this bigger hill, like then it all, it all is worthwhile. Well, that's the point of iteration. And the point of, you know, refactoring is that the first time you do something, it's not going to be the best. Right. And, and there is no best. Yeah. You're constantly improving because the world around is, is around you is changing. So if you were to create the original iPhone now, I'll use a very obvious example. It would be considered a failure. Sure. But not in its time, not in that context. Yeah, that's totally true. So I think failing is, is just an inherent part of progress, but failure in and of itself, like you're saying, it's not the end, right? Like if you stop at failure, then you failed. But if you use failure, then it's not the end. It's not really failure as much as it is. Like you're saying, learning, it really did. I think that is a very good language shift that people should adopt more often. Failing is really just stopping in the middle of the learning process. Right? No, totally. And it's all part of it. Yeah. I mean, looking at it as a process is actually the most important thing. Yeah. Uh, that it's like steps and not, you know, again, you're right. I mean, like I've, I've seen it, like people stop, people stop and then it's over. Right. Yeah. It's actually, sometimes that's the right thing to do, right? Like sometimes like you, you know, we took a bunch of steps. I mean, this happened at Etsy too. You take a bunch of steps, you wouldn't get where you wanted to go and you would stop and you would like, yeah, like, okay, we got to step away from this. Like this path actually is not producing dividends. It's not worth investing. Yeah. We're not finding, we're not finding the, we're not finding any purchase here. So like finding another path or even coming back to that some other time when maybe we're fresher and we're thinking differently. That's probably the textbook definition of actually failing is like, no, yeah, we tried all this stuff. Nothing worked. So we stopped, but at least we knew enough to stop, I guess. Yeah. No, I think the idea here is that like you aren't typically, unless you are, I don't know, working on your life's thesis or something. I don't think that you're working on one thing necessarily because a lot of the time, you know, you're balancing five initiatives and if one isn't working, then cutting that one gives you more resources to put into the other ones usually, right? Like it's about knowing your portfolio, I guess, of, of efforts. Yeah, totally. And that's probably especially true for, uh, for managerial roles is, you know, what is the energy of my team going towards? And I need to be aware, like keep my finger on the pulse of when we need to cut something and, and move, move that person in a different direction. Yeah. I mean, yeah. I mean, people get tired, right. And burnt out and like, you can only withstand so much of the same, you know, pursuing the same thing, I think, and not, and not actually being successful before. It's kind of time to, to try something else. Yeah. I actually recently had that same discussion with somebody we, and we came to the conclusion that there should always be at least one pinch hitter on any given effort. So like, you know, if one day you need to pull off of that project and go and do something totally unrelated, then somebody can step in and, and help, right? Like even if it's just minor progress, a lot of the work that I do, you can have somebody step in and just carry the ball forward a little, a little ways while you're, you know, recouping, I guess. Yeah. So we started actually doing, we haven't used it in that way yet. I don't think, but one of the like professional development things that we're starting at Buzzfeed. And actually I, I totally full disclosure, ripped this off from Etsy is that we started this thing. We're calling it residencies at Etsy. They call them rotations where anybody in the, in the tech org can talk to their manager about working on another team for six weeks. They'll talk to their manager, talk to their team. That team will like come up with, you know, what makes sense for them to work on, for six weeks and we'll schedule it and we'll do it. That's really interesting. Yeah. It's cool. And we just recently implemented it. What's really funny is we, if anybody had ever asked, we would have probably done it anyway, but like, but it, but we're, you know, we let people know that it's actually a thing you can ask for. And that's, you know, hilariously, I love, I love those wins because it's like, I didn't, we didn't do anything. Yeah. It was already, we sent, we sent an email that just said, this is okay. And we have a label for this. Yeah. And we look like geniuses. So, but yeah, so like a lot of people are starting to ask about that now. And it's interesting because there's different reasons for doing that. Right. There's some reasons which is like, Oh, I've been working on this team for a long time and I don't want to leave this team, but I want to try something else for a little bit. Or, um, I, I, some people like, I just want to know about how this other team works, or I want to know more about how this team does team does AB testing. Right. And like, and these are like the kind of reasons people do that. And what's interesting is like some teams are used, are I think thinking about using it as a way to kind of like, Oh, well there's these things that we've been kind of churning on and able to get done. Like this person's fresh and can like rock through this. Or like, there's this thing that we can't do because there's no one to do it. And it's bothersome to us that we can't, you know? And actually what's really funny is the teams themselves are starting to send emails at times that are like, if anybody wants to do a residency on the growth team, please contact, you know, john at busby.com. And, uh, you know, they, they, they're actually like trying to pitch work that someone could do in a six week residency on their team. Which is actually even more magical. Cause then now everybody starts to even have a broader sense of what's going on in those teams. What's interesting and impactful about those teams. I don't know. It's, it's actually working out in ways I didn't expect, but yeah, I mean, it's that way of like, kind of like letting people get past the burnout and like get past, like try something else for a little while and come back. Was this influenced by like academia and the idea of a residency in academia? I have no idea. I, so at Etsy they, they were doing it just with the engineers. Um, and they were doing it all with just the senior, it called it senior rotation for a long time, or a senior level and up engineers could do that once a year. And I think recently they rolled it out to all of engineering. And then at Buzzfeed, we're doing it for everybody. So there's not like a person who can't, who can't do it. So like design can go and be on the engineering team for six weeks. I mean, there's no, like we don't divide it up like that. So, uh, what winds up happening is, so we, we break the Buzzfeed product team down into like feature areas. So we have, um, what's the example? The mobile app team. That has, you know, smaller teams inside of it, but it's just, it's engineering design and product all in the same team, right? There's no, like there, there's an engineering like discipline, but there's like, and there are engineers and there's definitely like an organization to that. But the organization is actually like that organization is secondary to the team organization. So when like someone goes to join a different team, it'll be like an example would be a designer from the data team. Coming over to work on the growth team, right? New engineers, new designers, new product people, or like an engineer from the, uh, web experience team going to work on the ads team, right? So it's not so much cross discipline as it is just cross subject. Right? Exactly. And like, so we have, um, it's also something I ripped off, not just from a ticket. So a lot of people do this, but like we did, uh, we had our first hack week over the summer and, uh, like our attack wide hack week. And there were a lot of people that did things that weren't things they usually do. Um, so like a lot of the project managers actually had for their hack week project, had an engineer teach them Django and they did a project altogether over the course of a week. And they all had these, they all wrote their own blog. By the end of the week, they had a blog they'd written and deployed like by themselves. It was pretty cool. Um, and I had my project, my hack week project was titled teach cap to code, uh, uh, which didn't work out so well. I got, I got distracted. I got distracted by other projects. I didn't mind it. So you don't know how to code then I guess. Uh, you know, I, I don't know. I actually, so actually if you, if anybody's interested in getting deeper into that, into like coding at all and they aren't listening to this, actually I, over the past few weekends I've been reading this book called hello web app by Tracy Osborne. Oh, it's an introduction to web development. Um, and it's Django. Like she's a designer and she, she's explaining things like I've read a lot of programming books. I think I've tried to learn to code. I've tried to code many, many times and I feel like the, uh, the concepts, I always feel like they're right. I might write on the edge of understanding and I just, and the books just don't go far enough to explain to me what's going on. It's like a slightly missing vocabulary, something like that. Right. And then, and then she just frames it in this like perfect way where I just like, it just clicked on for me and I was like, Oh yeah, I understand why this is happening now. And then she also like when she talks about like snippets of code or something like she, she explains like line by line what's happening. And so it's nice cause you like, especially for someone like me who like has, I never took a CS course. I've never, you know what I mean? I've never done this before to like really be able to like read what she's saying and look at the snippet and be like, okay, like I see what's happening here. I can kind of intuit how to mess with this if I wanted to. And there's something she says not to worry about right now, which is like rejects. Like she's like, don't, don't just, just copy this. Like we'll get into it in another book. Like this is how you need to worry about it, but just stay away from it. This is a beginner. This is not beginner. Stuff like don't touch this. But it's actually super useful. And so like it's actually, she's just, she's kickstarting the intermediate book. That would be great. I'm pretty pumped about it cause like the beginner book was great and actually like did I have a app I've deployed. I'm like kind of building this like little recruiting app on the side. Oh nice. Yeah. Very nice. I'm pretty pumped about it actually works. It's, it's really stupid because it's like I got something to, um, this is really dumb. I, I have some, I have this like this app that you can like, it's basically a form. You can type into the, the form you submit it. It puts it in the database. I can read from the database. I like sort the information and I feel so like powerful. Yeah. Yeah. Doing that stupid stupid welcome to welcome to the software engineering world. God, it's beautiful. I thought CSS was great. This is like, it's pretty, pretty magical. It's funny to hear that from somebody who is at, you know, in the position that you are in because it's, it's, there is a wonder still about how this stuff kind of makes us feel. it's a new way of, of expression, right? And I, I know that design has always talked about in those kinds of terms, but a lot of the time computer science isn't. And when somebody gets a hold of it and really sees, you know what you can do with it, right? Like the app that you built as simple as it is, it could be very powerful like for you or for Buzzfeed or for whatever, you know, and it could be very simple at the same time. Yeah, totally. I, I think that's starting to become more clear to people. Yeah, I think so too. I, I think it's, it's becoming more clear because, you know, code is continuously more and more in the spotlight, right? We have, you know, the app store probably is highly responsible, but beyond that, just, just the common, you know, the hour of code and all of these things that are coming out to kind of make society aware that code is important, I guess. I don't know. I don't know how we didn't catch on to that earlier, but you know, you don't have to do this for a job to be able to explore it. Sure. It's kind of interesting. I mean, we talk about user experience designers and stuff, but I mean, when you're writing the code for an app or whatever, like that kind of user experience and user path has baked into even writing the code for how obviously for how it all works and fits together. And so what you wind up with is like, actually, in my experience, like develop some, a lot of developers I talked to or work with have worked with in the past or like some of the best user experience advocates because actually like the shortest path for the user is the shortest path for the user. Yeah. Is the shortest path for the code a lot of time, right? And like, and they're and they're thinking about that because they're building it. And so we're starting to get to a place where decent design is becoming more commoditized. I think like I think it's becoming easier to do pretty good design, like good enough design for sure. Like I mean, how many apps have we seen that had no designer that have done pretty well? I think not to say that I mean, this is I mean, I'm the VP of design. This is sacrilegious, but like I mean, not to say it is not important or that like you, you know, again, having someone with that expertise doesn't help you, right? I think it does the part that is hard for has historically been hard for developers. Isn't the or what they get knocked for hasn't been the user experience design so much because I think that just kind of happened, but it's been more of the like, oh, well, you know, the visual thing, the thing that all the designers hate being pigeonholed for is the visual design thing and that's just becoming like super commoditized. I think if you look at like apps that you know before they had, you know, before they blew up and got money and had been hired a bunch of designers and like before, you know, and after that, like you can see like big difference, but like just being able to ship a good product that helps people is like not actually that hard for developers anymore. Yeah, things that work tend to continue working right? Like how many different iterations of a form or how many different iterations of you know, notice or alert or modal do we have to do before we say, okay, let's just reuse that one. You know, totally at what point do we say let's let's take it back a step and look at, you know, how are we spending our time? Are we spending our time making this modal, you know, our own personal expression of what a modal should be or are we spending our time really thinking about, you know, how are we going to get people to even come to the site? Yeah. Yeah, which is actually why I think it's I think this sort of thing is good for design too. I think it like helps us change our focus a little bit into a more, even for developers to be like for designers. It means you have to be more strategic. You know, you have to start thinking in a different way because it's not important anymore to be thinking about how it looks or even sometimes I'm not just feeling about the one thing you're working on works how it works like it needs to be like more holistic than that more broad than that. Like I think like design has a lot to say about questions like where people going to come from like where should we be putting our marketing? Like what should the marketing copy say like how you know, what is the entire flow going to look like? What does that mean for the design over time as we add features? Did you know what I mean? It's like there there are harder questions than the feature you're working on and I think oh yeah, the more that that can become easier for everyone to get involved in and collaborate with the more and more designers are going to have to kind of redefine their jobs and like again like just put peel back, you know, peel up another layer and I think it's really cool. I think it's actually really important. Well, it kind of, it kind of starts to overlap with marketing right like and we're as as I said earlier this all becomes one big effort. You know, you have designers that are talking to marketers. What are the channels that were advertising on? How do we maintain continuity between the different voices or you know, if somebody is coming from a specific ad should we show them specific voicing because we know something about them based on what ad they came from, you know, I mean there's so many questions and. Analytics can you know be thrown into this conversation as well, but really it comes down to your building one thing together and is something if there's a problem like for example, if you have a very low visitor number if you have a very low page hit number and you need to solve that. Well, you can't just solve that by designing a better looking thing right like that. Maybe that would help but that's not the only solution to the problem. Oh God, I hope not. Maybe bounce rates are more affected by designing a prettier thing. I don't know. I mean, you know, I mean, obviously we're approaching a singularity where there's only one type of person on a team. Is that what we're saying? Hope not. Thank you so much for listening to today's episode of developer T. I hope you enjoyed my interview with cap at least almost as much as I did. It was such a such a blast to talk to you. Talk to cap. If you enjoyed this episode and you don't want to miss out on future episodes of developer T. Make sure you subscribe in whatever podcasting app you use. Most of your probably listening on your on your phones and most podcasting applications on your phones. You can subscribe in if you like using RSS feeds. There is an RSS feed available at developer T.com. Of course, all of the relevant links and show notes will be available at spec.fm. And you can find all of the past episodes of developer T at spec.fm as well. Again, thank you so much for taking some time out of your day to listen to today's episode. And until next time, enjoy your tea.