Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today is the second part of my interview with Cap Watkins. If you missed the first part, make sure you jump back and listen to it before you listen to the second part. As I mentioned on the first episode, Cap is the VP of design at Buzzfeed and we talk all about different things related to collaboration between designers and developers. I hope you enjoy listening to it as much as I enjoyed interviewing Cap. As always, all of the relevant links will be in the show notes which you can find at speck.fm. I hope you enjoy the second part of my interview with Cap Watkins. There is something to be said for like, how do we talk to each other? We have to have some kind of shared vocabulary and allow people to be experts in what their experts at, but how can we get to the place where we're doing all of those things with relatively small teams? I think that's the big problem, right? It's the size of the team because when you have a marketing channel for a massive company has people who are dedicated to figuring out how to get conversion rates based on advertising and they have it down to a science. That may be true for even teams of Buzzfeed's size. There are a lot of teams like the team I'm on. We just don't have, we have a guy who is doing some marketing work and marketing research and compiling analytics and trying to gain insights from it. Teams of that size, we all have to be aware of the things that marketing is aware of. Yeah, totally. I actually feel bad that we lose that as we get bigger. I think that's sad. I don't think there's an easy answer to that, but I think as companies get bigger, what I've witnessed is more specialization. And again, it's not so much siling, no one's trying to keep people out. It becomes impractical. It becomes impractical to try to communicate all of that stuff to everyone. When a company gets certain size, the entire company isn't moving together. It's actually not like that anymore. We break it down. Individual teams. Right. And so now you have marketing broken down into smaller teams alongside product broken down into smaller teams, design and sharing whatever. And maybe those things can stay in sync. I guess that's what I am trying to push on with product designers and also coding and trying to broaden instead of narrow. Because I gave a lot of comments about, well, when are you just going to have visual designers and when you're just going to have UX designers and I'm like, hopefully, never. I really hope that we can become more general and just push this generalist thing even as we get bigger. But we'll stay tuned on how that works out for us. Yeah. I think people demonize the word general a little bit too much. Oh, sure. Because that word assumes that you aren't becoming an expert at something. It assumes that to be general, you can't be a specialist at the same time. And I just, I don't think that's true. Yeah. I think the people that say that are the specialists. I mean, I really do want to decide not to be generalist. I think so. I mean, the people that I talk to that are like, well, you know, designers, a generalist isn't as good a visual designer as a visual designer. And I'm like, well, that's actually not my experience. I mean, actually the best designer is visual and otherwise that I met are like general product designers. And like everybody has different things. They're really great at things. They're not as great at, right? I mean, like, I feel like I'm a pretty strong, like front end person and like pretty strong UX person. Visual design. I'm okay. Like, I'm okay. Not great. And that's okay, right? Like, the nice thing about generalist is like, they fit together in similar ways. If you did hire a bunch of specialists. So like, I am best paired with someone who is very strong visual designer and, you know, also strong one. The other things too, right? Like, we like, it's like still extremely possible to be extremely good at things. I think you have more opportunity to be good, extremely good at more things if you're doing more things. So you know, we'll see. Yeah. Yeah. It's kind of a broad net kind of thing. I think the people who argue against the generalist concept is, or they're thinking or maybe they're part of their theory is that, you know, these things don't overlap, right? Or they don't feed each other. Like, to be a good developer, you know, to be the best developer, I need some kind of sense of design. I need some kind of sense of visual design, right? I need some kind of sense of user experience. And I don't think I can be a specialist developer without those things. Yeah, I mean, I've even seen at Amazon, I was a UX, I was technically considered a UX designer. And we had a visual design team, which was separate from us. And I mean, we sat together, but it was different thing. And I would actually get kind of pushed back on if I delivered anything that remotely resembled something polished. I was like, why? Why? Well, that was just the way it was, whatever, right? So whatever. This is the way they've chosen to build their organization. I was just, you know, I had no control over that. So I let it go. Sure. Yeah. But the hard part was when I would hand over my wireframes that like with a lot of UX stuff in it, with a lot of flows in it, with a lot of like very specific, I mean, even like touch target sizes, I was pretty, I needed to be pretty explicit. So you might have seen these visual designs that like just like had nothing like, we just drop things like touch target sizing and just drop out things like type size, like legible type size. And you're just going like, what happened? You know, and it's not that they're bad visual designers, right? It's actually not true. What's true is like they have no idea because they weren't a part of the UX process and they didn't come up with the UX alongside us that like they have no idea why we made the decisions we made or what decisions are important. And when you are like throwing stuff over a wall or handing it off to someone else to take the next specialist step with it, like there's always, you're always going to lose stuff in that translation, always. And it's going to be super painful and you're spent a lot of time trying to explain it. And you may never get there. And you're going to wind up with something that's like not as good as it could be because neither of you, and you don't understand where they're making the decisions they're making either. Right? That's the thing. It goes both ways. So like that person would make those decisions and we would talk about them and I would have no, I could not unpack like why those decisions got me. He was like, this would be like, oh well, it just looks really cool. And it's like, great. Right? Great. It's a legible. You know, it's like, and we have this thing going back and forth. And like, it would have been much easier if we'd been working on the exact same thing at the same time and gone through the UX together, gone through the visual design of it together and like come out the other side. And even if one of us was stronger at one than the other, like maybe I take on like more of the heavy UX work, because I'm better at that. But this person still contributes to the UX work. Right? So at the end of the day, they're bought in first of all and they don't try to change it. And like, then this, you know, because they've been a part of the process. And then like, then I'm more satisfied with like, I'll, no matter what, be more satisfied with the visual design because like this person will have taken into consideration everything that we've done so far because he's done it with us. And so this sort of collaboration stuff. And this thing with Developer Too is like, and that's why we've pushed transparency in collaboration, designers and code developers in design because like at the end of the day, if everybody's bought in before you start building or designing a single thing, everything is better. And everybody's much, much happier in the product is like, incredible. Like just like heads and tails better than it would have been. Yeah, I mean, people are not good at actually having good inputs into other processes. Right? So like what you said, I think is right on point that when you try to transfer that stuff over to somebody else, there's going to be a lot that is missed, right? Or maybe even totally ignored, which is what you were saying about like the eligibility. It's not enough to do, you know, A through C and then expect somebody to know where to pick up and and and because basically what we have to do, this especially falls on developers a lot of the time because you know, the typical process is, you know, in a lot of agencies, you know, we do like a discovery thing where we figure out what it is that we're going to build. And then we design it and then we execute the build, right? And that's there are you can make that work. It's possible to make that work. The issues that arise happen when you go from discovery to design and then from design to development, there's a lot of lossy, you know, like you're saying translation between the two because it's like, well, you didn't think about the 404 page or you didn't think about this particular viewport size or, you know, whatever. And eventually you end up collaborating, right? Right. Either you end up collaborating or the developer does the designer's job or the designer does the discovery person's job, whatever you want to call that person, content team. You know, that creates this situation where you have a little bit of animosity because it's like, you know, you handed me something that I can't do, right? Or you handed me something that is isn't all the way thought out and it doesn't become all the way thought out until launch. Right, right, right. And I think it's better for that to happen from the start, right? Like which is what you're saying is transparency from the beginning, having people involved from the beginning, that is, you know, the thinking out process starts at the beginning and you start answering those questions about legibility at the very beginning of the process. Yeah, I think it also helps. This is a really interesting thing, but I think it helps with retention. I think if you're happy at the end of a thing you did, you know, if you believe, rather than resentful. You believe in the thing you just shipped or you just had to build or you just designed, you know, I mean, like that's huge. Like it's so huge. I think, I honestly think developers get the worst of this because it is like, they do get kind of thought out as like resources and design is thrown over the wall at them and that's like a huge bummer. I feel like you just can't, I can't imagine what that's like. I mean, it sounds awful. I can tell you. It sounds really bad. I mean, I can't, I, you know, I've, I hope to have never done that so much. I'm in my career. I'm sure I've done the times when I feel I apologize if you're author listening. That must be so crummy. You know, and then at the end, even if you had, even if you did pushback as a developer, even if you did like somehow get some of the changes that you thought were important, like you still don't feel good. You know, I mean, and neither the person you just argued with, you know, over the thing that they thought was complete. Right? Like, you know, I just the more the people, again, we keep talking about this, like smashing these things together, like getting them closer, like getting them earlier, getting together earlier just feels like it's, it's so easy to do. And it actually reduces the time it takes to do things and it leaves everybody like kind of pumped at the end, which, which is never a bad thing. Yeah, exactly. And, and there's nothing wrong with somebody having, you know, creative control for periods of that time, right? Like sometimes, you know, call it a cave or whatever, but you need to go into your space and not be bothered for whatever, a couple hours to iterate through something. You don't need somebody standing over your shoulder all the time. So I think there's a balance that has to be struck. Yeah, yeah. But definitely more collaboration from where the industry, in large, I guess, currently is would be better. Absolutely. So switching gears entirely to this, this hiring conversation, because there's so many people who listen to this show and there's actually a lot of you who would be considered a designer at BuzzFeed right now. And Cap talks about this on design details and also I think in a couple of blog posts, but the designers that Cap hires are the typical unicorn. How much do you cringe when you hear it, Cap? I'm not calling myself that, so I don't care what we call them. I'm just kidding. Now yeah, it doesn't bother me. I kind of, I think it's dumb. But it's not a, whatever. It's a designer who can do CSS and HTML, right? Yeah, totally. And also just for words, there are worse words you could call somebody than a unicorn, I think. I mean, you know, it's true. It's true. We can cringe all you want, but it's kind of nice. Yeah, I guess so. So we'll stick with it. Unicron why not? That's just be shameless. Unicron, as we would say, BuzzFeed. Hey, why not? That is the kind of designer that BuzzFeed is hiring. So if you are a front-end developer and you're looking for jobs, don't close yourself off to the possibility of being fit for a designer position. You may not see yourself that way, but that very well could be a great fit for you without you even realizing it, right? So tell me what you at BuzzFeed are looking for in that position, the young designer, the junior position. Sure. Maybe it's not young, but just go ahead. Yeah, it's a good question. So I mentioned resilience earlier. I feel like it's a really big deal. I got a lot comes down to that. I think, especially when you're like earlier in your career. I'll avoid the word younger as well. Earlier in your career, or been working alone for a long time, I did that for a long time, and I think it's really funny. I worked at startups for first five years in my career or so, and I really thought that I was senior. After all that experience, I felt like I really got it. When I went to Amazon and realized I was so not. It started to work with other designers for the first time and you're just going like, oh my god, these people are so, so smart and have so much process that I'd never developed because I had been working alone. So I think like for folks that are kind of starting out in design and stuff what we're looking for is resilience is really important being able to kind of push forward through things you don't know. Those things push forward through things that aren't going so well because you don't know how to do them yet or because you do them poorly. That has to be there. Curiosity is a huge deal. I was talking to a designer the other day and I was asking her like, well how do you, she works alone. I was like, well how do you get better at stuff? Like what are you doing to learn what you don't know? And she started just listing all these blogs, she follows and all these books she's read. That's awesome. It's like this drive and momentum that even if she doesn't work at Buzzfeed or even if she doesn't work anywhere with more designers, she's going to push herself into that place because she's curious and she wants to know more and she knows what she doesn't know. That feels really important. Well, I wanted to ask you a question about the resilience. How do you actually, as a prospective designer, I guess, as a young designer, I keep on using the time. That's fine. As a beginner designer, how would I go about expressing resilience? How can you evaluate that, I guess? Yeah. I mean, I ask a lot of questions that require examples. So like give an example of when you're resilient. Well, I mean, I wouldn't have liked that, right? It would be give me an example of time that you disagreed with your product manager and like strongly disagreed and then what happened, right? Then they tell the story because everyone's got that story, everyone, right? And then you get to the end of it and they're like, yeah, and so, you know, we really disagreed and I thought it should be this way and they thought it should be this way and we want to do this thing. And I was like, well, okay, cool. So like talk more about how you got there, right? Like what happened? Like what was the conversation like? Like, you know what I mean? Like how many times you go back and forth? Like did you feel okay? Did you feel good about the result? If so great, if not why not? And so it's just like, it's like peeling the onion a little bit on people. The only thing we do is when we do bring people in for an interview in the office, we do as part of that some like design whiteboarding and typically what I try to do is, you know, you give people something vague enough so they can kind of like start to play around with it and then begin to add constraints or more things to do. Like as it's happening, so to see how people are able to pivot and think, you know, so it's like, all right, so we've done this now. What would happen if we learned, like what would you do if we like did this or did some research and we learned this thing, right? That like sure, like it has to work on a screen reader. Sure. Right. Or like a contradicts or what we've learned has contradicted what you've done here. Right. Right. Right. Or, you know, hey, we just got a call from the, you know, people that were doing this with and they actually said that they messed up and that these are the new constraints, right? Like no one really ever like crumbles at this point, right? But the ability to kind of like really easily pivot on that and just be like, okay, great. Like you know what I mean? Like, okay, fine. Yeah, it's just another iteration at that point. Right. Because you know, you're looking in the, in that first question and even in the whiteboarding thing, like we're looking for folks who can like, because they're going to be just agreements, right? They're going to be hard conversations with your team, with your team and other teams. I want folks on the team that can manage and navigate those conversations more than I think I want folks who are like extremely polished designers. Right. Yeah. I mean, I think like, I could teach someone each time on CSS. Right. Like if we pair it with somebody with a really strong UX designer, they could learn UX design. And if they have some taste like which is usually pretty apparent from the portfolio at all, like they're going to get better visual design. Like those things are all like either teachable or pretty apparent. I think the hardest thing in hiring is really finding folks, even junior people who are able to like easily navigate conversations, know what they don't know, admit what they don't know. And then like in the face of adversity, you know, continue just to like, yeah, like what happens under the stress. Yeah. Because it is stressful. It can be really stressful sometimes. Those two things that I asked those people are the same, they're the true for every level. Yeah. Yeah. And that was going to be my next question is like, once somebody is a junior designer because there's plenty of those listening to this show too, how can they feasibly, you know, develop the skills necessary to go from junior to say a managing designer? Yeah. I mean, a lot of its experience obviously. Years, the number of years. It's a lot of number. It's more like what are the experiences you've had and how have you handled those experiences? I mean, at that point, if you're, we've had first hand knowledge of that, you know, like, I mean, the entire time start to like identify strengths and weaknesses, starting, you know, to help people, you know, maximize their strengths and kind of like put them positions where their weaknesses don't matter so much. You know, if you're not created for an end development, like, you're going to, actually, working at BuzzFeed, you're going to get better. Right? I mean, it's just like, it's just how it's going to be. Right? Because there's no escaping that we're going to be doing that. So, you know, as long as you come in ready to go, like, and learn some stuff, we're going to do it. You know, if you're like, not strong at UX, like, we're probably going to throw some stuff at you that's UX stuff. And we're going to pair you with people who are good at that. And you're going to learn some things. But, I mean, like, typically, Mike's experience is like, no one stays in the junior role more than like a year, like a year and a half maybe, because that role is actually mostly about hard skills. And we can, I mean, if we're not teaching you that fast enough, that's a problem for us, not for the person. So it's a learning position based on like a second level internship almost. I mean, yeah, kind of. And then like the product design level is like, once we get into that kind of like mid-level thing, it starts to become more about, you know, like a really like articulated process that you can repeat and get good results out of, right? And then like from senior and up, you start to see more of like, saw skills emerge where even for non-managers, like becoming a leader on the team and being able to mentor other designers and make other people around you better just because you're there. You know, is like, is extremely important. And some of those folks are so good at that and they like it so much, they become managers. Right. So like really don't want to have one on ones and deal with, you know, balance sheets. Personal issues. Or even just like the, you know, stupid stuff like budgets. And like, like some people just don't care about that, but they really enjoy like helping designers do better work and they really enjoy doing the work. And like that's great. And we're going to provide that path. Yeah, I mean, that's kind of how it happens. It moves from like hard skills to kind of like some hard and soft stuff around like process articulation and then basically more and more into soft skills as you like become better what you're doing. And eventually you aren't designing at all if you're the VP. Yeah. If you, if that sounds great then, yeah, let's do that. You know, climb, climb on up. Right. Exactly. That's great. By the way, I really enjoyed the, the lie that you tell new hires. I'm not going to, I'm not going to ruin the surprise for anyone who's listening because I think well, first of all, time constraints at this point. So go and read it. I'm going to put it in the show notes. It's really one of one of the better kind of especially for managers who are listening to this. And if you are cultivating a team and you're trying to cultivate, you know, new practices, especially on your team, that's a really good read. I thought that was clever and really good. Thanks. Good insight. Thanks. So another shift in terms of topic here. How much of the CSS architecture are you, are you personally actually responsible for, you know, that actually gets shipped to the front end of Buzzfeed? In March of this year, I started to kind of play around with writing a CSS framework for Buzzfeed. It didn't have one at all before that. Not comprehensive. I met. There was like, there was a lot of old code on the site. There were a couple of front end developers like trying to refactor every single page. It was just like, there was no framework to build that on top of. I started to play around with it on a train one day, paying to one of the other designers, a senior designer at Buzzfeed, who is actually like one of the strongest front ends we have. And she and I started to kind of like toss this code back and forth in a GitHub repo. Start adding to it, you know, starting to figure out what we would need, what we wouldn't need, kind of like approach we wanted to take. And started to pull in more people as we started to realize this might be really useful and powerful. And so by a couple of months in we had, I want to say two or three more designers contributing to it and we had a regular meeting every week about it to check in on it and like assign cards and stuff and starting to like actually make it a project. And then a couple front end Developer That were helping kind of, they were kind of advising on the project because they were these were the people that were like actually trying to like refactor every template. And so they were kind, they were obviously extremely interesting what we were doing. That was in March at this point we've like released one.o internally. It's being used in a ton of internal projects like almost every internal project now is like on this framework. We're technically at 1.o.5 right now and I'm we're developing.6. Nice. Yeah, it feels good. And like this week we're going into production production with it just to CSS like to make it available so people working on projects on the web app can use it. Like the entire web app won't be like converted over anything but like they won't look, it won't look any different. From what you've said it's really light right? Like it's you said it was 8k. Yeah, it's 8 kilobytes gzipped. So basically what we've done is like if you're familiar with like Brent Jackson and base CSS we took that almost that exact concept actually Brent worked. I hired Brent to that scene. Very nice. Which is actually how I know about this at all. But we took all those concepts and kind of like did our version of that and the idea is it's like atomic CSS. So essentially we rewrote all of CSS as class names. So float left you know it was a class name and display block is a class name. And so what you wind up with is not a lot of CSS but you can basically in HTML build and style anything which is pretty rad. Yeah, we've been building that for the last whatever you know like there's like five months, four months. I have probably contributed at this point 50% or so of the code. Well, code and code deletions. I looked at my stats the other day and I deleted twice as much code as I've added. I feel pretty good about that. That's the mark of a great development. The best code you write is the negative lines that you put into your GitHub repo. Yeah. So I like and actually I spent the last couple of weeks. We're starting to gear up to like put the documentation online and put the CSS online for people. I'm not sure if we're going to open source and not something we've talked about but there's a lot like of course like responsibility there. So we're trying to figure out how we're going to handle that if we're going to do it. But in lieu of like the documentation going online like I was like okay well it's been cool internally because we all knew what we meant. Yeah. So we should rewrite this. So I started to kind of go through every single page that completely rewritten it from scratch which is hilarious because I uncovered a bunch of bugs in the CSS. Wow. In the process. Exactly. Exactly. Which is pretty magical. So go out and rewrite your documentation and you'll find a lot of stuff. So that's done. And now we're just kind of doing some last minutes. I'm like doing some cleanup on like our navigation system for the documentation and stuff. Do you guys use like a pre-processed language? Yeah. So are you using SAS? Okay. SAS or SCSS? Rusing SCSS files I think the syntax is SAS. I'm pretty sure. So it's either the bracketed one or the one with the indents. Does it look like regular CSS sort of? It can. I mean we're writing like functions and mixins obviously and like okay. Yeah. If you were in fewer people are writing the SAS proper. In fact there's a lot of people that don't even use it at all or don't even know about it. It's a totally different syntax and it's not interoperable with regular CSS. So you can't drop your CSS blocks into SAS and expect it to work because white space is actually regarded in SAS. Yeah. I've always been confused about that because like our front-end developers, I've had this exact argument before or this discussion before and like and I go back to BuzzFeed and like you guys were like we're using SAS right and they're like yes but we're actually this file still have CSS in them and they're still SCSS files. So I'm not really sure what like the distinction is because like we're definitely using SAS syntax. Yeah. Well, and they have the basically it's the the pre the processor is the same right. So the output would be the same. It's just the input right. So like the at syntax and all those mix ends and stuff that you use, that's the same stuff as SAS proper or whatever. But you just add the brackets so that white space is not the deal. And you can also you put back in the semi-colons and colon's. So that's what you're separating your stuff. And in in SAS like the white space version, it's not that way. Right. It's kind of weird. I don't like SAS. Actually personally, the SAS proper. I love SCSS now. I feel like that's the only way to go. I don't really understand how you would ever. Why you would ever do the other. Yeah, yeah. I feel like that's a really great way to learn something that is not a standard. Exactly. Yeah. It's one of the things that I respect about coffee script by the way. I don't know if you're familiar but you can write regular JavaScript in a coffee script file and it will work. So you can move like one piece at a time over and change the syntax to the more coffee script asc version of it. Right. And the same thing is true for SCSS or whatever you want to call it. So yeah. So that's something. Something. Yeah. So yeah, we're using that. I mean, like we're using it. I feel like responsibly. I know people have mixed feelings about this stuff. The way I think we've approached it, I don't know if anybody's ever articulate this. They may all think I'm crazy. But like the way I think we've approached it is more of like a way of just not repeating ourselves. You know what I mean? We only would make a function or a mix in when we know what the output is already because we've written it. And it's just like, okay, well, this will be a pain if we were going to change it because we might. So let's like wrap this into mix and because we know exactly how much CSS it is because we've already written it. You know what I mean? It's like we're not writing it blind. We're writing it like basically after we write the vanilla CSS version most times and then realize that we can like kind of like wrap it up a little bit nicer for us to look a little better. Yeah. And also just like there have been so many, I mean, there have been a couple times actually where we've wanted to change like a spacing variable and wanted to change everywhere, right? In the CSS. And so being able to change that in one single place is like so nice. And not trying to search for the value because that value because we're all, it's all in the RMS and so like that value could be on things that are not spaces, you know, that are not spacing things. And so you have to look at every single one. Right. It's supposed to be like, oh, this space variable, which we know we haven't used on anything that's not a spacing thing. Like, is we could just change it and it'll be fine. And then there are times where we don't use any variables to declare the exact same value because the value is not the thing that's important. Right. The value isn't the important thing. It's actually like the context it's in. And so we're using it that way and I feel like that's been actually really successful for us. Again, like hasn't led to it on a code boat or anything, which I feel pretty good about. Yeah, definitely. Yeah. Anyway, yeah. So like, it's, I've written about 50%. I think like, we've had five designers contribute to it. And I mean, the vast, I mean, like 98% of it's been written by designers at this point. Which is pretty rare. Yeah. Yeah, that's amazing. Yeah, it's really cool. I don't think anybody saw that coming. So go in and give all of your designers a little badge, find like a sticker or something that says congratulations. You're now a front end developer. Yeah, it's been pretty interesting actually. One of the, so there was that one designer, like I said, who was like pretty proficient already. And then there was another designer who, I'm a wrong person, I don't think she had ever written a line of CSS. Like maybe she'd done a little bit, but she had never like done it in production, never like done it to prototype nothing. She, she was coming from like essentially zero. And she has like turned into the biggest contributor to this thing. She is such like, she's so deep in it. She knows how to write CSS really well now. She's like teaching other people like how to do this stuff. She's having opinions on how to write like, you know, on code, like pull requests and stuff. It's been really magical to see that happen with folks who have worked on this project, like who maybe didn't have that background. And then like through the project basically learned how to do it and became huge advocates for it. Like there are times she's completely skipping even going into sketch or Photoshop. So she can like, because she's going to prototype with this framework that she helped build. Sure. And it's like, it's really, I walked over to her desk the other day and I was like, wait, what is this? What are you doing? And she's like, oh, I'm just writing the, you know, I'm writing this prototype, whatever it is. And I was like, oh my god. Because like, it's like never happened before. You know, it's like, it's so, so cool. It's really interesting because that stuff can translate, you can hand that off to a developer. I mean, especially with the framework, right? Because what's really cool is like if we prototype it even not in the actual code base, although sometimes we're doing that. Like because this framework is class-based, like, and because the framework is already in the web app, all that has to happen essentially is the developer, like we give them the front at the HTML and they can like literally copy and paste it. And it will, and it will just look correct. And they don't have to deal with any CSS. There's no garbage, like at all. And so it's actually pretty powerful. The developers I've talked to who've used it so far are so grateful to not have to do that part anymore. I've been told that a couple of times. They're like, I really am so glad I get to do the fun part of my job, which is like, why are this thing up? Like make it work to an API and do the most. Yeah, they can do all the fun stuff that they like to do. And they're like, you know, I really always dreaded the CSS. Like I didn't want to, it's not that I wasn't good at, I just didn't want to do it. I didn't, they were like, I totally totally get it. Implementation details for that. Super get that, right? I don't want to be responsible for writing, you know, back in architecture. So, you know, we're even. We're square. Like, you know what I mean? And so it's been pretty, pretty, pretty cool to see that happen. Well, it's interesting you bring up the back in architecture thing because I was going to say we actually have experimented with this at the company that I work for. And we have designers that will jump in and, you know, build out a WordPress project or something. And every once in a while, we realize, oh, wait a second, like we've thrown too much at this particular present. Like, they can go up to a certain point and then it's like full on stop, you know, and there's no progress after that point because, you know, that's totally out of their wheelhouse. They were never, you know, we didn't never, we didn't never even intend for them to have to do those things. But the project requirements had shifted enough and we didn't, you know, we didn't plan for the development team to be holding onto that project at the time. Totally. It's a very interesting problem to try to solve. I'd rather be solving that. You know what I mean? I'd rather solve those kinds of problems. Like I'd rather hit a full stop because we tried too much. You know, because we let people extend beyond themselves and try things they've never tried before. You know what I mean? It's just like such a much better problem than like, oh, well, this person's frustrated because they can't try things. You know what I mean? Yeah, yeah, sending 20 emails back and forth trying to figure out who's right. Yeah. I mean, like actually, so the residency thing, we have a someone on our product support team who wants to do residency with the ops team. And I heard that today and I was like, I don't even know what that means. Like what does that mean? And like they talked to the ops team and the folks on the team were like, yeah, no, totally will like, will each of us will peel out, peel off this much time each day and like we'll help this person. I do whatever they're going to do. It's kind of crazy. Like it's kind of awesome. Like that, like where does that happen? Who does that? That's sure. You know what I mean? People, people again, who feel safe in failing. Right. Well, and then you have like, it's not just that. If we just put this person on that team with zero support, like you could say that, you could say like, yeah, sure, totally. You could do this team for six weeks. And then like if the team didn't, wasn't like generous, right? With their time and their expertise, like it would be a huge failure and that person probably still be really frustrated. And that comes back to hiring, hiring people who are, who are going to be doing that properly. Like how can you just like increase the generosity of your team? You know, it's a really hard problem. It's very like, it's a very person to person thing. Yeah. Like do you ask that question upfront and be like, hey, so are you a generous? That's a tough one. And it's more cultural, I think, than anything else. Like it's like, even if you come from a place where it wasn't like that, it is extremely possible to, you know, to create a culture where it is, it's just an infectious thing. You're right. It's like, it's just like, oh, wow. That happened. You're watching it happen to other people. And if we all celebrate that publicly, but it's happening and how amazing it is, you'll do it too. You don't even mean you'll be like, well, that is really cool, right? Like, I mean, like, unless you have zero heart whatsoever, it's really cool. Well, we tend to follow the things that our friends do, right? Like there was a stat that came out recently that said, if you have a much higher, it's some crazy number percentage chance of being obese. If your best friends are obese, right? Like, and the flip flop is true. If your best friends are fit, then you have a much higher chance of being, you know, fit. And that's a weird, like, reality for the workplace is if you act in certain ways at work, especially if you're in a position of leadership, right? Like, if I am being generous with my teammates and we show appreciation to the people who are who were leading or who are managing or whatever, then they will in turn show appreciation of those around them very often. Yeah, I also think I always feel bad when we talk about that as like a leadership saying, I think because like, I think what happens with people think it's a tactic or something. No, I know. I think it's, I think it can be discouraging to folks who are not in a management position. I think like, it's like, oh, well, I'm not in a management position. I'm on this team in a company that doesn't quite have that culture. I mean, there's people listening right now who are thinking this, right? And they're like, oh, and there's nothing I can do about it because like they're saying, like, of course, like caps the VP of design, like, of course, you can like do whatever you want. So I like, of course, you can make that however you want it to be, right? But like the trick is, I think like leadership, it's not, is not like a role. There's no title that says like leadership on it. Forget the whole culture of the whole organization. Forget that, right? Like, if you're on a team of five people, it doesn't matter if you're a junior designer, it doesn't matter if you're a middle of a engineer or like new or whatever, you can impact that change locally. You know, there's a, it can definitely happen from a bottom up in a bottom up way, right? And I hate the term bottom up and it drives me crazy. But like, like, that's how these folks feel, right? They feel like they're at the bottom. It can definitely happen in a local level. There are some teams that I've seen that like companies I've worked at or whatever, they're just functioning better. You know, he just like five people that just together are just like crushing it and doing so much good work and everyone around them is just like, how the hell is that happening? The fact is the like the culture in total obviously isn't that whatever that team is doing, right? Because that's why I was asking themselves like, what the hell is this? But like because that happened locally, it's actually starting to impact the teams around them because they're all asking themselves like, and each other like, how is this possible? Like what's like, they seem so happy. They seem to be pushing codes so fast. Like, they'll work through doing is so great. Like, what is happening? Is a bunch of senior people know, right? Is it like, like what is happening in that team that makes it so successful? Then you will start to have emulation, right? You start to have questions being asked and like, these are good things that can impact, it can wind up actually impacting the entire culture. Yeah, that's so true. So I think it's hard because like when you're in that position, you're like, well, we, like, I'm in this position and I need to change the whole culture and I can't do that. But like, you don't actually have to do that, right? You can like, really just focus on your relationships, right? Like, how can you make as a designer, how can you make the engineers feel really good? And like collaborative and like brought into the process as an engineer, how can you like teach the designer stuff they don't know about how the code works? Like if you're a product person, how can you include everybody in the product road mapping process on your team? And then like, that's enough. Do you know? Like, that's enough to really like... Yeah, because it has a cascading effect throughout the rest of the people that they interact with. Well, even if it doesn't, like at least you're on a team that's awesome. You know, like it... Sure. Yeah, you mind that. You're kind of in a place that like is better for you anyway. And like, and then if coincidentally, which I think it could like impact other people, like that's even more magical, right? And that's really great. And so I don't like... I think people looking to like managers to like do this stuff is... They're like, they're missing an opportunity, I think. And like, and if you wait, you're going to be waiting for a long time, particularly in some cases, right? Yeah. Just to excrue that. Yeah. I mean, our brains don't respect the boundaries that are imposed by an organization, necessarily. Like we respond to personal interaction with people and our brains perceive people as people, right? Like it doesn't matter what your title is or where you sit in an organizational structure. That thing was imposed on you. So when you're interacting with another person, you have just as much of a ability to, I don't know, impact that situation as they do. I think so. Yeah, it's a powerful perspective, I think. And one that, especially for those people who feel like they're stuck in a really frustrating role or something like that, there are still things you can do. You're not powerless. Yeah, totally. By any means. In fact, quite the opposite. Yeah. Awesome. Well, this has been really good. I do like to ask all of the people who come on this show a couple of questions. The first one is, if you could give every developer 30 seconds worth of advice, what would you tell them? Geez. I don't know if you haven't covered in two hours. Let me think. Just forget ownership, man. Like it's not worth it. You know, it's just like the more you hold on to the thing that you think is yours, like the worst thing you're going to make. You know, I think people, like I think, develop, not just developers, but all of us have a tendency to really latch on to the thing we're good at and really try to protect it. Because we think that's the right thing to do. And it's a super reasonable thing to do. Like it makes a lot of sense. But it's counterintuitively not the best thing to do. The more, like, and we talked a lot of this podcast about, like, you know, designers advocating for design with engineers and with product folks. But the same should be true for engineers. Like, you're great at what you do. Like advocate for why it's great and why other people should know more about it. You know, I mean, like, at Etsy, they did lunch and learns every week about some, I mean, sometimes designs up, but most of the time, very difficult engineering things that they were working on. And designers went. It was like an open place. The email went out to everybody. Be an advocate for your expertise and like share that with other people that are not, not in your expertise. I think it's like, it'll just give you more leeway and appreciation for what you do. So. Yeah, I like to say a lot of the time that, you know, most of the other practices in our organization, other than development, is at least in a translucent, if not a transparent box. Right. So like, I can sort of understand what sales does. I can sort of understand what designers are doing, you know, development quite often seems like they're in an opaque box. That's a little box. Yeah, for sure. Yeah. Yeah. There's some empowering aspects of that. There's a little bit of mystery to it. You know, there's this perspective that we're always hacking something or we're always, you know, stealing people's passwords or, I don't know, whatever, whatever people think that developers do. But I think it's, I think that's an interesting, improper perspective. And it is a powerful thing to bring things out of that box. Right. Oh, yeah, totally. Because it helps, especially Developer To communicate more effectively with other people who previously didn't really know what they were doing. Yeah, absolutely. That's great. I think so lunch and learns. Yeah. Do so good. Do lunch. So, and the second question, and this is, this can be, you know, even a personal response. But what is one topic or, you know, maybe one question that you wish more people would ask you so that you could talk about it? Do I really want that? Let's see. I don't really feel that strongly about people asking me the right questions. Because I feel like whatever they're asking me is the right thing. Sure. Maybe, maybe topic though, right? I guess. I've never, like, it's not so much, I wish people would ask me questions. I wish that someone would talk about something that I don't, that I feel nervous about, that I wish someone else would write a blog about or something, which is, there's challenges that I'm having now, which is managing managers. It's really interesting, actually, because, you know, when you manage designers, it's, I, it's not, I don't want to say it's easy. It's not easy, but like, it's easier because there's an artifact, I think, and there are clear moments of achievement where someone, you know, reach beyond themselves and do something they hadn't done before. And you can watch it happen. And like, you're in the room when they lead a meeting about their design work, right? And that you can see them. They're demeanor change over time and they become more confident or whatever, right? Or not be as dismissive of questions or like concerns, right? You can kind of like, you can watch these things happen and coach it and watch the change, right? And then like, it makes it really easy to see what's going on. When you're managing managers, like, talk about a black box, like, it's really, really, really hard to know what's happening because the artifact of that is people, first of all, so that's a hard thing to impact. The second thing is like, where it's happening are places I'm not. So in a one-on-one, I'm not there. I'm just like, me, maybe two-one-one. So it's a one-on-one and like, I'm not there to see how that's going, right? And like, I'm not going to drop in. That's crazy. And it wouldn't be the same, right? Like, it wouldn't be the same. Or in a meeting with their team or in a critique with their team, right? Like, I am not in those places. But that is where the work's happening that this person is doing, right? And this is where like, things are going well. They're not going well. And then you can get general sense for how things are going, right? You can like, talk to the designers and stuff, but it's still unclear to me how to help managers. Like, I hope I'm doing a good job. I think I'm doing an okay job. That is a hard problem to solve. And probably one that not many people have experienced. Right. I mean, I feel like a lot of people have experienced, but I don't know that anybody's like writing about it. Yeah. Like, I couldn't speak to that right now. You know, I have like, maybe a very limited amount of experience with that, but on an extremely micro scale, you know, like we could sit here and talk in hypotheticals and, you know, psychological maxims or whatever, but ultimately the experience is what is what would drive a writing session. Right. And what's interesting is like the for sure, and I can speak to this from experience, like a lot of the job is communication is like strong communication, clear communication, good communication, and like when you have a designer and communications is really important for design two, and when you're just hanging around and you hear a designer have a conversation about their work with someone else, like you can kind of like, you can be there and like hear it and then like, talk to them about later. I'd be like, hey, that's same frustrating, I'll let go. But you just can't, there's no mechanism for that with managers. And I don't like, I don't know, this is my plead, anybody out there who knows anything about this. I really, maybe it's you. Maybe you need to start writing. Well, I, yeah, I'm going to start probably writing about it in some form of fashion, but me more of my like, I don't know what's going on writing. It'll be non-authoritative. It'll be more like, well, I think that's how the internet was built, wasn't it? That is probably true. That's how most blogs are at least. I'm saying that I know something about this, but really I just experienced it for the first time. Right. This will be me just like putting the crying emoji over and over and over. And every manager of managers will probably be like, yep, that's exactly how I feel. So I was right on. I just kind of know a lot about how it feels. He's right. I spot on all, as I was. That's right. Oh, that's good stuff. Well, I appreciate you coming on the show, Kat. I'll tell you. I'm very certain that the developers who are listening also appreciate it. I put my email address online, but if anybody out there has more questions or like, you know, wants to talk about it, let me know. It's just a CWATKINS at gmail.com. There you go. Of course, we'll include Kat's blog and anything we mentioned in this very long episode of Demeliverty in the show. You made it this far. Jonathan's going to send you a some stickers. I think. Yeah, sure. Why not? Yeah. In fact, if you contact me, I will use some shipping startup to send you a handful of stickers. Yeah, you use the promo code. I made it this far. I made it this far. Yeah. You made the promo code in an email. That's right. Well, man, well, thanks a lot. Thanks, Kat. I appreciate it. Thanks so much for listening to today's episode of my interview with Kat Wachins. Again, of course, this was the second part. So if you didn't hear the first part, make sure you jump back and listen to that as well. If you have questions or comments that you would like for me to address on the show or even if you just want to talk to me directly, you can always email me at developerateatgmail.com. There's also a Slack community that's spec.fm has started. We have over a thousand designers and developers in there. So there's always good conversation going. You can join that Slack community by going to spec.fm slash slack. Of course, that link, along with all the other links from this episode, can be found in the show notes, spec.fm. Thanks so much for listening to today's episode of developerateatgmail.com. Until next time, enjoy your tea.