Lunch & Learn: Hiring and Growing your Development Team with Clio

Thanks for having me. My name is Jonathan Watson. I'm the VP of Engineering at clio. I've been there about nine months now. I originally thought I was gonna have a projector, so I had a whole bunch of content that was basically like four hours worth of content that I shoved down into an hour just to kind of brain dump and get that going. But instead, I'm gonna use it as notes. All right? So why on earth should you even listen to anything I have to say? So this is the part where I tell you, like, a little bit about me. So I was. When I was three, I was born in Texas, so I happen to be north of the wall, right? Like, if you hear any expletives or something, that's probably just, you know, my native Texan talking, and occasionally you'll hear the accent. When I was three, we moved to Hong Kong. I was basically raised my entire life in Asia, so Hong Kong, Malaysia, India. India and Singapore. When I was 15, I bounced back. Decided midway through college that college wasn't for me. Started playing a bunch of video games. Met my wife playing World of Warcraft. Before that was like an acceptable thing. We're talking a long time ago, right? I remember friends cautioned me, are you sure she's not going to kill you? Are you sure she's a she? And all that kind of fun stuff. And I was like, I swear, we've actually talked on the phone and done all of that kind of junk before. Video conferencing was really kind of widespread, but what happened was I shut down kind of my business that I was running in Texas, and I moved to San Diego. And then I was kind of looking for my next career. And I had always dabbled in programming and just kind of poked around at it, but hadn't actually done anything with it. And I was like, well, we'll give this a shot. Like, let's try this kind of thing out. So I started Dev. That part was mostly uninteresting, except for I found a really great mentor who helped me grow and eventually found a job in San Francisco. So. So I spent four and a half years at Zynga on Zynga Poker. If you got spammed during the high times of farmville, cityville, like Zynga Poker, I am really sorry. That was definitely me. I wrote a system that could basically spam, like, 250 million people a day. So that was like, our entire amount of users we had in Zynga Poker. Believe it or not, it worked. We were making over a million Dollars a day. And some of those numbers are pretty crazy. Some of the big games like farmville were making two to three million dollars a day. So. So people click on the spam right after that. Zynga had gone through its uptime, downtime. I went through the IPO. It launched at $10. It spiked to 18. By the time the open period came in, we were at eight. By the time the next open period came in, we were at 6. Then we were at 2. And then layoffs happened, and then another round of layoffs, and then another round of layoffs. So I had done three of them. As director of engineering, I've been running 130 devs in five locations. Whenever you have to build a team up from about 60 all the way to 130 and then shrink it back down to about 40, that's pretty painful, right? Especially when you've been on all phases of kind of the layoff pipeline, right. As a dev, oh, phew. I made it. I didn't get laid off then as a manager, oh, no, I have to go lay that person off. And then as a director, hey, for three months you're going to stare at ghosts walking through the office because you know that you're going to lay them off. So at that kind of point in time in my life, my wife and I had just gotten married and I was looking for a change. I was like, I kind of want out of the games industry. I kind of want to see what else is out there. And so started looking, happened to find a job in Ottawa. So kind of the reason I tell everybody kind of my international background is because I was used to traveling around the world. It was kind of normal for me. So became the director of engineering at Shopify. Brought that team from 4 to 27 by the time I left about two years later. Grew from a small amount of money, many, many amounts more money. And also was there kind of post IPO after that, I realized I was actually missing a big portion of my job that I had at Zynga. So, like, game studios were kind of. You got to direct company strategy and all sorts of other things in it. Shopify, I was very much kind of the middle layer. Couldn't really direct anything, just had to deliver really well. And while that was fun, and it was a lot of fun doing it with the people I was doing it with, it wasn't quite for me. So Clio happened to come up right before I was about to move to the States. And that's how I got my way here. So What I really kind of specialize in is like helping teams grow and scale like that sweet spot in between 30 and 250. And like, to me, it's kind of where I really like to operate. It's kind of like, you know, everything you thought works now begins to break down and you actually have to change as a company during that point in time. So this is kind of a distillation of a whole bunch of that experience and just kind of breaking down some. Some things that I hope a lot of you will either have a ton of questions afterwards or you'll just kind of think twice when some of these things sort of happen. Once my computer wakes up here, kind of walk into it. So the rough amount of topics that I was going to cover were hiring your first developer. So I don't know how many of you have a dev team already. Okay, just one guy. Sweet. You did it. How many of you are looking for a dev team? Ok, so a few of you to expand the dev team. What's that? To expand it. Ok, to expand the dev team. Got it. So some of this will apply, some of this won't. It'll actually show you kind of what we do at Clio and other pieces as well. What's in an interview. I'm not going to go into a ton of detail here because great interviews are actually kind of an art and a deep understanding of what you're looking for and trying to get out of it. But I'll give you some pointers, like kind of early pro tip, like make sure you have an interview process. Like if you don't, you're doing it wrong and you're incredibly biased and you should probably fix that. We're going to talk a bit about what happens when it goes wrong. Like how does that world look right? Hell, firing your first dev is like a pain. Not sure how many of you had to fire people, but it's not fun. And how do you actually inflect that? How do you change that and how do you address that when you need to get to that point? And then I'm going to talk about a concept that I usually give to a whole bunch of other engineering leaders, which is kind of organization immune systems. Like if you think about orgs as living, breathing things, there's patterns that you develop, there's responses that you develop in the world and to problems and you actually create autoimmune diseases throughout your whole organization. You respond to the good things the bad way and the bad things the good way. And part of it is because you need to pick your head up and look at what you're actually trying to solve. So that's about four to six hours worth of content I'm going to try to cover in about 40 minutes. So hang on. Okay, so before we dive in on hiring your first dev, all of you, if you're going to go out and hire somebody, you need to be able to do a few things. And these are going to sound pedantic, but I can tell you, having been a dev and people trying to hire me into their startups, these are absolutely necessary. Can you explain what your product is? You have to be able to do that. I feel like it's kind of self explanatory, but you'd be surprised at how many people you walk up to that can't do it. What sort of problems would you need solved? That's a huge one for devs. Like if you're encountering me and you're saying, hey, I'd really like for you to solve these kinds of things and here's some things that we're struggling with. I get excited about the job. So you're actually putting the hooks in kind of early and, and getting people to invest. Like, hey, there's actually a ton of problems here to solve. What does winning look like for this person? No one wants a dead end job, right? No one wants to not understand how they're being graded, how they're being measured or any of those sorts of things. So even talking about like winning in this position would be somebody that comes in, helps us get to like operational excellence, that means XYZ and is able to ship X amount of things we think would be pretty sweet. Especially if we solve these five customer problems in the next year. That would be a pretty good indicator of winning. Devs get excited about that. Most devs. And then are we in this together? Especially when you're a stage one dev. The amount of founders that came and talked to me and I was like, so what's your job in this? And they'd be like, I have the ideas. And you're like, oh shit. Like that just means you might as well just contract out the entire thing. Like, are you looking for a partner? Are you, are you looking for somebody to engage in this? Are you in it with me? Are you gonna sit down with me? Are we gonna do this together? How does this whole relationship work? And it's perfectly fine. If you have all the ideas and you need to get it built, that's perfectly fine. Just be upfront with it. So the devs that you do hire understand the world that they're getting into. So I get asked a lot, what's a good developer? Well, that's an incredibly nuanced topic and it's completely different depending on every dev on the face of the planet, right? But I've kind of hammered in on and honed in on a few key things. User and customer empathy. It's a big one. You find devs that actually give a shit about the customer, give a shit about the problems that you're solving. Like they're, they're monsters, right? They, they deliver and solve problems in new and unique ways. They're collaborative and creative. The collaboration piece is really key. The creative piece is there because they should be helping you solve problems and helping you come up with ways to do this. They have a history of failures and successes. I would actually care more about the failures. Failures are exactly how you learn. And if you find a dev that has done nothing but win, one, they're not being completely honest and two, they probably don't have the experience that you're looking for. You're actually looking for some struggle here. I can rattle off my failures left, right and center pretty much all day long, right? And one of the things that we do in kind of any org that I work in is we talk about these failures pretty readily because we want people to be exchanging that information. They give and receive feedback. So a lot of devs, and a lot of people, let's just call it that, do not know how to receive feedback. More people don't know how to give feedback. But we'll get there in a minute. So keep in mind that you're actually looking for this. When you're looking for great devs, how do they take feedback? Give me an example of when you got some developmental feedback. What did it look like when somebody told you you were doing something wrong? How did you respond? And the quality of communication is probably the most important thing. Great devs are great communicators. They may communicate in really non standard ways, but they turn like take for example Linus, right? Guy's been known to be like a huge asshole when it comes to everything he does, but he communicates really fucking effectively. If you read what he's talking about, you're like, I got it. So it doesn't actually matter where on that spectrum you are, but communicating is. If you can't do it in the interview process, you can't do it in the discussion, like get out. It's not going to work. And you should Immediately just be not on the hook for hiring that person. So it's all that stuff plus the embodiment of your company values and that's a big one that every company now tailors to themselves. For Clio, that's customer success comes first. Thrive is team Clio. Play. Play to win. Draw the fucking owl. Live a learning mindset. No doors, only windows. Stay fit. Have fun. In that order. I tend to just start with draw the fucking owl. But so you've done all this and a lot of you probably have a bunch of myths of devs in your heads like what a great dev is, what a bad dev is. Yep. Question. Question was to engage with them and talk about the problems they can solve or product to market fit. The answer is both. You can talk about product fit, you can talk about, hey, I have scalability problems. I don't even know how to scale. I don't even know what scaling is. How do I do this? I want to be able to write code, that kind of thing. Would you be willing to help me learn how to do that sort of stuff? Just engage with them? You'd be surprised. I would say probably half my problems that I solve are actually product and customer facing problems. They're not even technical. So there's a few myths about devs that I'm just going to kill right now because they actually drive me insane. Introverts versus extroverts. Get out of here. Just get out. That's not a thing. It's not a thing that buckets anybody. It is a superpower that is being used in different ways. I myself an extreme introvert, which means at the end of the day I'm going to crawl into my man cave. My daughter's gonna sit on my lap and act like she plays video games with me for an hour. Like that. That's my recovery time. It doesn't actually have anything to do with my day to day job except like I have to manage my energy. And extroverts, same thing. Like they actually get tired of people, they're great at talking, it doesn't actually matter. But I found a bunch of people that say like I'll only hire extroverts or I'll only hire introverts. I'm like, just please stop. Like it's actually an old kind of way of thinking and like we have to just dispel it. It doesn't, doesn't matter. There was that entire article and series that was written about the best devs that they say has led a lot to the Diversity and inclusion problems that we've had where they talked about them being introvert and quiet people that didn't engage with others. And that was the best dev. And it's such bullshit, especially when you see it actually work. So throw that one out immediately. The next one is someone like, hire somebody you want to spend a ton of time with after work, like somebody you want to have a beer with. Luke, one of the dev managers that came over from Shopify, he talks a lot. When I asked him this question, he said, yeah, what you want is somebody that you can have a conversation with and potentially over a beer, but not necessarily somebody that you always go out and have a beer with. If that happens to be how it works, great. But it doesn't have to be that way. Especially on your first devs, they don't need to be your best friends. You're there to do a job, you're there to hold them accountable. And, and I guarantee you, if you're looking for your best friend and you're trying to hire them, that is a different world and gonna be a really painful one when it doesn't work out. Potential versus experience. There are times in life where you need experience. There's times in life you look for potential. It's really up to you, but I think you need to realize which one you're actually honing in on when you're talking to people. We hire almost entirely based off of potential to a point, and then it becomes experience that says we actually need some experience to mentor people around. But potential to me is still way higher on the list of things that I will hire for and education is necessary. We had a guy interviewing the other day who said that he used to do resume kind of walking through by looking just purely at education. And it's just like, holy cow, I had to kind of smile and be like, I don't have a degree. Like, I had to get into Canada by sneaking across the border. Maybe, maybe not. It's up to you to decide. But ultimately it comes back to like, even if you kind of take these myths and you throw them away, or you just acknowledge that they're there and they're kind of biases that you have as you're looking for devs that's actually way better than you'd be not knowing that they exist. But I keep coming back to the best devs communicate well. Just period. Like, if you can't get that during the interview process, you can't get that when you engage with them. Like, you need to walk away Almost immediately, especially during the early days. In fact, process usually comes in because of poor communication or response to something else. But it's usually poor communication. I wish you guys could see all my animated gifs. The kind of next piece behind it is like, do not wing the interview process, ever. Write it down. So it's standardized, otherwise you are not actually evaluating. Especially if you were inexperienced interviewing. I probably, I don't know, close to a thousand interviews at this point in time. I can wing some of it. But it's actually very structured. It's like if you've done enough one on ones, right, you have a structure to your one on ones, whether you write it down or not. If you're inexperienced at interviewing, write it down. For us it's pretty simple. We do a technical deep dive. And what this is is let's talk about a technical problem that you've solved and I want to ask a ton of questions about it and you answer my questions. And that can be as much as why did you pick this technology? Why did you have this problem? Why didn't you solve this problem? And this is actually an interview that you can do even if you're not a programmer. Because when you're looking for that first dev or that first few devs, you want somebody that can communicate these decisions to you so you're not just getting blindsided by their choices, right? Like they're not making terrible ones. You're actually able to challenge what they're doing. So you can do this. Now, leadership and feedback is another big one. Once again back to how do they accept feedback and how do they exhibit leadership and what do they look like when they're in kind of their worst? That's really what you're trying to suss out here. So talk to me about a time where you got some really bad feedback and you had a really shitty day. How'd you show up at work? What'd you like about that? What did you not like about that? That's super important, right? Especially in early stage startups. It's long hours, it's a lot of time together. It's frustration, it's worry, it's stress that brings out pretty much the worst in almost everybody. And you need to understand where we go when we're at our worst. Culture Ad and or fit really depends on your company and how you kind of think about it. But Culture Ad is a big deal for us. Culture fit's the easiest one. Like do they kind of align with our values? That's why that value piece is Important, but culture ad is a big deal. Like, are they actually adding a ton to your organization? That one gets dropped off a lot, especially at the early stage, hires and then gets brought back as companies hit about the 20 to 30. But I encourage everybody, even stage one, like, you can start thinking about it. Like, unless you're looking for a quick exit, quick win, that kind of thing, you should be thinking about building a 100 year company. How would you change the way you hired early on so that your founders are great people to work with? And then optionally, this one's a bit more technical. We do a pair programming exercise where you actually come in and write some code, solve a problem with us. That one you do need a dev. Usually. I was contemplating if you could do it. If you were technical enough. I think you could. So if you want to give it a shot, come talk with me or one of the managers. And we actually would love for you to be kind of a guinea pig and see if it's even possible. You could even come in and do one with us. That's actually how we train everybody on it. We train all of our devs, but they come in and step in and train doing it. So, like I said, didn't go super deep in the interview process, but there's a ton of content here and it's probably well worth lots more hours and lots more eloquent and experienced people in this regard. So Rylan back here is kind of head of, well, senior talent acquisition. You have a ton of questions about interview process, how he actually susses out kind of at the first phone screen. Rylan's like the guy on the front of the lines. He's the guy that is looking to say, like, is this person culture ad immediately? That's the first, first thing he's almost looking for and then going, hey, do they meet the technical bar and where are they going to fit? And like, does this make sense in the organization? He and I are pretty strong partners in this. Can I ask question? Yep, question. Okay. So the question was, how do you evaluate potential? It's kind of nuanced, but in reality, what you can look for. And you'll actually hear the terms a lot, right? So it's how quick did they learn? Like, how quickly do they adjust to things? Like, how driven are they? I like to just experiment. Like, what do they do kind of on their free time? What excites them on learning? Like, what are they excited to learn about? There's like pretty whole series of questions that kind of suss that out. And like for me, how quickly do they change their minds when they're introduced to new information? That's a big one. Is like if you can uproot your position and switch immediately, amazing. But also, to be honest, I don't think there's a science behind it. I do think it's like an in the belly kind of gut feeling. And I think we get it wrong as much as we get it right. You had another question? Yeah. So the question was about pair programming. Do we sit with them while they do it or is it like kind of a take home test or a go away test? It's very much together. We believe that that's actually a better environment because we get to ask questions, help people walk through the problem, see how they work, how they think. If they ace it, we get to ask a million other questions and we get to kind of say, hey, one of our cultural values, like we pair programs together and we want to know how this is going to work. Like if you just can't do it, that's actually not going to fit in the way that we operate. So if you want to build like a healthy pairing culture, which you can probably read a million other articles that talk about it, do it. That's kind of the response like, wow, I really wish we did this thing. Well, are you hiring for that thing? And most of the time people will say, no, I'm not actually hiring for that thing. So what happens when you get it wrong? Right. Anybody familiar with Radical candor? Kim Scott? Anybody familiar with the not Silicon Valley version of it that just makes fun of it the whole time? So basically the premise is there are, is basically this axis, right? So up top means to care personally, to give a shit about somebody, to care deeply for them and about them and about their careers. The other axis is basically to challenge directly. So if you take the quadrant where you do not challenge directly and you do not care personally, you just don't give a shit about that person. You're not going to tell them anything, you're just going to kind of let them fail. You've all worked for that person at some point in your career or you've been around that person in your career and, and the only thing I can tell you to do is get out. Like there's no place I'd rather, how do I phrase this? I'd rather work anywhere else than in that kind of environment. I've been in that environment and I'd recommend you don't build it either. On the other side is like, you care personally, but you don't challenge directly. So you care so much about the person, you don't tell them things that may hurt them. So I always take this one as not wanting to tell somebody that they have something in their teeth or that, hey, maybe they should shower more. Believe it or not, I'm going on five companies in a row where I've had to have that discussion. So it's like little things like this, this is how it shows up. And that's really what happens, is we're actually so worried about them being nervous or it's uncomfortable for us that we're not actually giving them feedback so they can grow. And I can tell you, but I'd rather know. I'd rather know every single day and accept the embarrassment. Then there's kind of the challenges directly, but doesn't care personally. So this is your obnoxious asshole kind of world, right? Where this is where they just kind of throw things over the wall and you just have to take it. Cause it's feedback, right? Feedback's a gift. We love hearing that thing, right? It's like, not really. It doesn't feel great. It's like the shitty white elephant gift. So in the upper axis of the care personally and challenge directly is radical candor. And what this means is, hey, I care so much about you and your career. I have to tell you something, and I'm going to give you this feedback directly, and it's going to be completely backed with all the positive intentions that I want you to develop and grow. When you do this, you will find that people change way faster than you expect. Kim Scott has a ton of blog posts. She's got podcasts, she's got videos. The book is fantastic. I can't recommend it enough, even if it just gets you used to the habit of giving direct feedback. So when you encounter that dev that's not delivering something in the way you want or is, it's hard to deal with. Kind of my first question to almost every manager when they tell me they're having a problem with somebody is like, did you tell them, take that one to heart? Especially as like, early founders, early startups, or people that are growing your dev team, did you actually tell them that you don't like the thing? Hey, when you do that, it's. It means this. So we do a whole bunch of training around this. I make fun of it because it's easy. It's the experience cube. It's actually done by a guy here in Vancouver, but it spells out, oh, what the fuck, Cube? It's observations, thoughts, feelings and wants and it's a good way to kind of structure your feedback so people cannot argue necessarily over the observations, but we can have a discussion about the thoughts and the feelings around it. And keep in mind this whole deck I'm going to actually send out afterwards so there'll be some of these resources in it as well. Yes. Question, question was, was our feedback training in house or something that we can kind of share around our. Chris Yeh, one of our talent development leads, he's written a whole bunch of blog posts on this, so there's information that we can share out there. We run an in house basecamp program that is actually like leadership development and growth and we're actually running our whole company through it now. We started with the leadership group, then managers and then now everybody. We're out in the community a lot. We actually just did a dev manager meetup where Kelvin, myself and Chris Yeh actually spoke about this entire process. So I'll share some of the links to some things along when I sent out the unanimated version of the presentation. So in reality, when it goes bad, ask yourself, hey, is this my fault if I deliver the feedback? If you haven't deliver the feedback, if they don't adjust, cut them loose. It's hard to say, but keeping somebody around longer is going to really kill you. You will never say, wow, I fired that person too quickly. Never heard those sentences. Fifteen years, I've never heard that. I've always heard, I fired that person too slow. So make, make up your mind quick. And if you need help, if you don't have a mentor, go find a mentor. Find somebody you can bounce these ideas off, engage with them. Say, I'm struggling with this. Yep. So the question was, how soon would you let somebody go? A week? Two months? So my fastest firing has been five seconds and my longest was three months. It's highly situational. The point is, if they're not. Here's the easiest one. I use two rules. 70%. If you're taking up 70% of my thinking and energy to manage you every day, you should not be here. Regardless of if you're a high performer or not, no one should take up 70% of your time. Right. The next one is, are they actually accepting the feedback and adjusting? Are you seeing those changes? So that'll elongate the timeline. Right. But a lot of that has to do with the quality of the feedback that you're giving them. So the five second one was a harassment Thing saw it fired. Like easy enough, right? But most are not that black and white. And in reality you'll find you actually sit too long. And sitting too long actually hurts them. You'd be surprised. Like, it's a relief once they leave. Like, they know it, they feel it. I've been fired. I don't know how many of you have been fired, but like when you've been fired, you look at this a whole other way. You're like, holy shit, I went through three months of hell and I didn't have to. Like I could have just been cut loose and been finding another job and like learned from that experience and moved on. So jumping on from this is kind of the organizational immunity. Immune systems, right? So we all have them. Immune systems are super complex things. There are your innate immune system, which is fast and broadly effective. So treat that as like, hey, you had a cut on your arm, you get an infection, you notice it swells up and then it's gone, right? Like your body's immediately responding. Like, I know how to fix that thing. The next piece of it is there's an adaptive immune system which basically is the, hey, you've got that bug before, you won't get that bug again. So think chickenpox, right? Back in the days where your parents sent you to other kids houses to get sick. That's not a thing anymore. My daughter is like 16 months old and I found out that they actually just have a shot for that. And I was like, well, that doesn't make it any fun anymore. Like I remember though, John's sick. Like, everybody go over and have a sleepover and. But yeah, so like your, your body actually remembers that disease and now knows how to counter it and can counter it way quicker. Or you may not even get sick. But then there's kind of the third piece that says like when all this goes really bad is autoimmunity. So this is when the body is actually attacking healthy things. And this happens a ton in companies. So if you liken a company to. Companies are constantly building immune systems and they're trying to decide, is this something I like? Is this something I don't like? And how am I gonna respond to this? And they kinda walk this cycle really, really fast. And there's simple ones like, hey, they harassed somebody, fired, like easy, right? That's kind of the first response. Like, we know what that is. Then there's the, hey, we've hired the asshole before and it took us a year and a half to fire them. So now your company has A no assholes policy. And you've actually like built all sorts of stuff around making sure you don't have the asshole in your organization. So that's kind of the longer term ones. But then there's autoimmunity which really comes into play on developers, actually comes across all organizations, but in developers it's pretty apparent. And it comes down to anytime you find process, that process is there because of pain, that process is there because of scar tissue, that process is there because something went wrong. And what I like to tell everybody is in the early stages, every layer of process you add and no longer assume that people are going to do their best work, you've actually just hampered your ability to ship to your your customer. You've actually put your business at risk thinking you're going to make it successful. Now there are companies that have tons of process that are incredibly successful. There are companies out there that have no process and are incredibly successful. This is my opinion, doesn't mean do it one way or another, but I think it's kind of the way that I view the world. So we'll take an instance and this is where my animated GIFs come into play. Dev ships bad code brings down the site. Pretty common in any industry where you're shipping kind of multiple times a day. The reaction is oh no, we should never allow this to have to happen. We should implement senior sign off, we should do a more comprehensive QA plan, we should do a stage rollout. Maybe there needs to be a secondary developer on all deploys. Maybe that dev can't ship code anymore. I've seen all spectrums of that like pretty heavily and companies is natural. In fact Clio, when I walked in that was the initial response to an outage that I saw three days in was something very similar. So what we decided to do, and there's a couple of tools that we're going to give you, we implemented root cause analysis. When there's an outage on production, we actually just do a really simple blameless kind of root cause, identify the failure, what the sequence of events were for it and and what the hell we're gonna do differently. And that is dev driven. And it is about instituting change at the very base level. Let's say anybody can make that mistake. How do we prevent anybody from making that mistake? And if we're talking process, it better be a short term kind of improvement. So I had an example of one here. But we talk about the good, the bad, the ugly and like what went great in it, what went poorly what went really bad and then kind of what are the action items out of it? A lot of times you'll get 50 things that the devs want to do. And in reality you only need to do two of those things because you're assessing how likely is this to happen again and what actually happens if this happens again in your business, five minutes of downtime may not be a big deal, and other businesses, it may be a million dollars in revenue. So like, you got to tailor that to your experience. But you as leaders and organizations need to understand the, the first reaction when your blood, sweat and tears are in your company and there's an outage and your customer emails you is that should never happen again. I'm going to go talk to the dev and make sure that never happens again. Don't. You're harming that developer from being able to do their jobs. Part of what we get paid for is we have to live on that bleeding edge and we have to be out there without these safety nets. And look, if that dev is constantly making the same mistake, get rid of them. That's pretty easy to say, but instead ask them like, would you mind doing a root cause analysis and tell me what you're gonna do different? Like, I'd love to see that. You'd be surprised because now they're actually packaging that for you and you're building a healthy culture that's adjusting and actually is gonna grow and develop and actually scale. Because the first one doesn't scale. Because then what happens is you end up a cargo culting, right? Like the next group comes in and they say, hey, why did we do this thing? And they're like, it's always been that way. And eventually you end up saying, the hell's going on here? We're slow as shit. When I joined Clio, we were doing eight deploys a day. Yesterday I think we did 27. So it's been a matter of reducing restrictions process, giving one button deploys, putting it back in the hands of the developers. Yes, our uptime has suffered a small amount, but it's actually not been as big as you would think. And in fact, devs are responding even quicker to it. And our monitoring is getting better and our customers are getting better service and it's just going to keep getting better. Because in reality the system is actually what's at fault here. The fact that code wasn't approachable or unmaintained or unmonitored. The next one is, you'll always see a checklist. What about a pre deploy checklist? Any of you familiar with the Checklist manifesto? Sweet. You should read that book. It's basically talking about like this surgeon said, you know, saved a ton of lives by building checklists. It's a fantastic read. But it comes down to a couple of premises that complicated tasks where steps are easily missed. So checking out your airplane before you take off, hey, you miss a step, you're gonna crash. Maybe you should have a checklist. Checklists do not train people. This is a huge mistake that a ton of companies make is they think that it actually trains people. I don't know about you, I've never learned anything from a checklist except for to click the button and kind of gloss over the entire checklist. And checklists have to be customized. It's a big part of the book was like even in the FAA or any of these other things that deal with these high risk scenarios, it's actually customized to kind of each airline, each airplane, each position in the airplane, like each job function. It's highly customized. And for me, like I have a checklist when I'm rolling out a new process, but I'm not over here checking off boxes, right? I'm actually just engaging. It's a highly customized way to not forget some things. So don't say we need a pre launch checklist unless you're actually needing a prelaunch checklist. If you're wanting people to force through steps, that's the wrong way to do it. Yes. The question was how would you deal with customers who require SLAs and you're doing continuous deployments. It's kind of hard for me to answer without knowing the SLAs. I had a thing where I had to guarantee like six nines and uptime on our search technology. So we actually just bulkheaded around that like it wouldn't go down ever. Everything else, we were actually fine if it went down. So we were slow on this piece of the software. Fast on this piece of the software. So you just kind of have to decide what's your risk, like vector and what happens if it goes down. And we can always chat more about it if you have more specifics at some point. So kind of like the last like organizational, I don't know, terrible thing that happens. And you'll hear about this, you'll all probably smile. In some ways is the concept of flow, right? Everybody wants to enter flow in their job. They want to be in the zone, they want to deliver, they want to just like work. I don't know about you that's about four hours for me. In the morning I get in really early and I get that before all my meetings kick off. But everybody actually wants that. All of you probably want that. And devs, the problem is the stuff you're juggling around in your head when you get interrupted. Some devs can pick that up quickly and others take two to three hours to recover from those moments. So understand the impact that you have. And what are some anti flow things, right? Too many meetings. It's usually the biggest complaint you hear. I love this one. I had a dad one time complaining that he was in too many meetings. I pulled up his calendar, he's in two. I was like, well, how can we make it better? And he's like, I would appreciate it if they were all on the same day. And I was like, okay, shoved him. Same day, he was happier again. Never complained about too many meetings, but it was just like he lost actually two days of work time because they were dead center on two different days. So, like, it's funny, I still make fun of him for it. When I talk to him like, how many meetings you got? He's like, well, none this week. But it's important to realize, like, for some people, that's incredibly destructive. For others, it doesn't matter. Like, I can get coding done with 20 minutes of time, but that's a learned skill and something I just spend a ton of time doing. And there are other people that can't do that, and that's okay. The dev environment sucks. If you've been a dev, you show up at a company and they say, here's the wiki page. Go get your dev environment set up. Seven days later, you're finally up and running and you can fix a problem that's terrible. Like, you've actually wasted all sorts of excitement and energy. So you're destroying kind of that flow. And then actually, if you think about this, in a great continuous kind of deployment environment, you should be able to rebuild your dev environment in a matter of minutes, not days, because you should be blowing away your changes constantly. So whenever your dev says, hey, I really need to work on this tooling, it's true, they should. That stuff pays off in the long term. We had a new project, we just bootstrapped that. We tried out a new dev environment and we went from four hours of dev setup and a bunch of pain to basically our PM set it up in about 12 minutes. And our goal is to get that to like a minute and a half. We want it to be two commands. So that is huge. That PM was immediately engaged. New devs joining the team were able to contribute within an hour. It's pretty fantastic, right? Especially when he's talking about onboarding new devs. You really want to lose seven days when you got money burning, Your burn rate's there no matter what. You should be doing things to improve that. Documentation sucks. This one's kind of weird. Depends on your culture. Do you care about documentation? Do you not code document itself? Do you care more about decisions? Do you care more about, like why we picked One direction, why we didn't like what we thought about? It's really up to you. But just understand that really bad onboarding documentation is worse than no onboarding documentation. So delete it. Auto age it out. I yell this one all the time. In fact, I think I got quoted this morning by someone on my team saying the right thing is not easy. That one's huge. For me, the right thing should always be easy. Humans always take the easy path, make the right thing always easy. Pretty self explanatory, but it takes a lot of investment and time and discipline to actually do that. So kind of gut check questions for you, whether you're technical or not, dev or not, is are you investing enough in tooling? I think there's a sweet spot between 15 to 25% that should be done in tooling. That seems high. Probably to most of you that stuff pays off so heavily, especially if you haven't been doing it. Eventually it'll taper off to maybe 10%, maybe less, depending on the type of company you are, depending on how big your environment is, how many devs you have, that kind of thing. But you're not spending enough now, period. So the next one is back to that. Is the right thing easy to do? I'm just gonna keep, like I should get that one tattooed on myself somewhere. Like it's just, it's kind of the words to live by. If you're building an organization. Are you solving the right thing? So this is the important point of when you're having these responses to these problems, are you actually solving the right thing? Ask yourself that. You'd be surprised. Most of the time you're going to go, no, I'm not. That was my gut response. Probably not what I should do. And are you. And finally, and this one, I hope resonates with most of you. Are you talking more about your process than your product doing it wrong? Right. You should be talking about your product and your customer and what it takes to do those two things. Whenever you spend all this time on your process thinking your process is going to solve those two things. Guess what? It doesn't. Process does help. It does have its place in the world. It is something you should enable and wield but it is not something that should wield you. So ask yourself every single day, am I talking too much about my process? That is a problem. We hire the best and the brightest. Let them do their best work. If they are not doing their best work, let's talk about that. Challenge them directly. Give them some radical candor see the responses and the change go from there. And ultimately kind of the words that I live by is I want to change every conversation from you didn't follow the process to let's talk about your decision. I almost never say why didn't you follow the process? It's like I don't actually care. Like you made a poor decision somewhere. I want to talk about that because that's the thing that makes us better. That's the thing that.