In today's episode, I finish my interview with Lauren Cutrell. Lauren is the Director of Interactive at Whiteboard, and she also happens to be my wife! We talk about agile, scrum, and how to make those things simple for developers and clients. Today's episode is brought to you by Flatiron School. Flatiron School is the premier coding bootcamp for launching developers. Proven job outcomes, career-ready curriculum, and a focus on building community through code. Check out their free bootcamp prep course at [flatironbootcampprep.com](https://flatironbootcampprep.com) and get $500 off your first month's tutition!
In today's episode, I finish my interview Lauren Cutrell. Lauren is the Director of Interactive at Whiteboard, and she also happens to be my wife! We talk about agile, scrum, and how to make those things simple for developers and clients.
Today's episode is brought to you by Flatiron School. Flatiron School is the premier coding bootcamp for launching developers. Proven job outcomes, career-ready curriculum, and a focus on building community through code. Check out their free bootcamp prep course at flatironbootcampprep.com and get $500 off your first month's tutition!
Hey everyone and welcome to today's episode of Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to be finishing up the interview with Lauren Cutrell. For those of you who don't know, Lauren is my wife and she works at Whiteboard with me. She is the director of Interactive at Whiteboard. In today's episode and in the previous part of today's interview, we talk about Agile, we talk about how it applies to developers and how we are implementing Scrum at Whiteboard. I hope you enjoy this interview with Lauren Cutrell. Okay so we've gone through these first two ceremonies that kick off meeting as I'm going to call it. I'm never going to get the name right. The sprint planning meeting as we call it and then the continuous ceremony I guess is a better way of putting it but the second ceremony is that stand-up meeting every day. What is the third ceremony? It's the exciting sprint demo or iteration demo of what you've done over the course of the whole week that is actually involving the client and or product owner where you are demoing all the working software or the working web or the executed design in browser or in mailchimp or whatever you're working in. Okay so this is basically showing the client what you've created for the order. Showing the product owner is a better way of putting it right? Sure, it can be either or there's in our situation there is a client and a product owner. So I like to think about movie credits when I think about this. So a product owner is like the director on a movie set. They're much more involved. They have really specific preferences on how things look, how things feel, how things how they match up to a brand. They're going to be the most once again to use the metaphor. Boots on the ground kind of role in the sprint process. Whereas somebody like a client is going to play more of the producer role. Now we're using this, we're using the term producer in the movie sense, not in like the producing the developer as a producer in the sprint world. But in the movie world a producer is kind of hands off. Usually they are involved in some distant way. They had an idea for the film or maybe they were involved with some people who had the idea for the film or typically they're going to be hands off and a lot of times they have maybe some money wrapped up into the film. But that actually describes this relationship really, really well. You have the director who is much more artistically involved, much more bought into the individual decisions. The way that a movie feels is typically because of the director. The way that a movie is funded is typically because of the producer. So think about that in those terms. And I think that kind of gives you an idea of how a product owner should be interacting with the sprint team throughout the week. They're going to be doing a lot of hands on. They're going to be giving feedback throughout the week. Is that how it's supposed to work? Should they be having kind of impromptu meetings, for example, with developers? If they see fit, but really that's only a question of if the task or requirement isn't quite fulfilling the values or if something got off track or if they have more insight to fuel the direction of the thing that a developer is working on, that's more than acceptable. What isn't prescriptive about the way you implement Scrum or Agile is that the team should really define when and how they communicate and the coach helps them do that. This is actually probably my favorite thing about Agile. You no longer have to feel bad about saying, hey, let's jump into this conference room and talk about this thing. You don't have to plan it. Typically, because you're all working on the same project, the interruption is welcome. Because you know, hey, they're working on something really important. As long as you're respecting each other. You don't need a project manager to do all of that overhead for you. Get into to compare this to a non-focused week is what I would probably prefer to call it. Without this kind of singular focus for a given team, a lot of the time you're going to have somebody coming up to your desk and asking you to work on something that's totally unrelated to what you're working on. That's not what we're talking about with this. What we're talking about here is having someone come up to your desk and ask you a question that is actually relevant to what you're doing and that's actually relevant to what they're doing. You're all working towards a singular goal over the course of five days. It is a powerful feeling to have focus once again. This is literally one of the very first things we talked about on Developer Tea. Focus is a super power almost. The ability to focus is so important. If you build your processes, if you use something like Scram, if you subscribe to the philosophies of Agile, then you can accomplish focus. I know it sounds like we're almost preaching this. There's no money involved in this for us. We aren't trying to sell you a product that you can go buy about Agile. All this stuff is as open source as it gets. This all comes from the desire for people to be happy and effective. That's client and producer the same. That's a developer feeling fulfilled and they met the focus and the task as it was defined. They felt the reward of that on a daily basis. Then at a weekly in the sprint demo, they're like, look at this. What we did is a team. It's already working. It's launchable. It's effective. It might not be the whole site. It's working and you can move on to the next thing to create the full solution and maybe launch it all together. Yeah, absolutely. We're going back to our film metaphor for a second because we just mentioned this third ceremony, which is the demo. That's almost like the initial screening, if you will. There's a weekly screening. It's almost like you're screening a scene. You're not going to look at the entire application. You're going to look at a subsection of the application, whatever you worked on for that week. And then, so that's the third ceremony. What is the final ceremony in the scrum process? This one is internal. It is for the betterment and the growth of a team and it's the sprint retro or the iteration retrospective. You are as a team identifying three things. What worked really well? Let's do it again next sprint. What didn't work so well? Cool. We identified that. Let's pick one or a couple achievable things to try on this next sprint, learning what didn't, didn't work. I love this in our team right now. And hopefully other people experience the same thing I assume they do. But in our team right now, this is almost a exercise for our team to start practicing how to be both positive and critical. So we look at what we've done. And sometimes it's really difficult to come up with one side or the other. If you feel negative about something, you're going to have a hard time coming up with something positive. And vice versa, if you feel positive about something, it's really difficult to come up with something negative. So I found that this is a really good exercise in critical thinking for our team because it's easy to kind of fall prey to group think. But what you have to do in this particular meeting, I'm talking a lot about this, even I'm interviewing Lauren, but I feel very strongly about the retro meeting. What you have to do on the retro meeting is ensure that everyone comes up with something on both sides of that fence. Yeah, it's easy to fall prey to the negative that happens. The bug that occurs, the unknown that pops up that we know is inevitable in software, in web design and development. And this really coaches you just as a practice to identify something positive as well because you've worked as a team. Something has gone well. And this key is you up to do something well again next week as well as improve something, not just identify all the negatives, but actually choose to isolate that thing and say what we could try differently next time. So this is actually a pattern that we see in super high performing athletes. We've used some sports language in this episode, but most specifically, athletes that are trying to get better, a lot of the time, what they will do, if you go and listen to any of these podcasts about these incredible athletes who have won multiple championships or episodes of coaches talking about how they coach and how they won multiple world championship kind of things, pretty much across the board, the way that bettering happens is you have a coach and you iterate and for each iteration, you identify things that you need to do again and you identify things that you need to improve on. So the exercise itself of identifying those things is a part of the process and then going through it is the exercise. It's the actual building of the muscle or the building of that memory of that particular skill. So you're not going to get it right at the beginning. You're not going to get agile, right? You're going to estimate things wrong all the time. One of the things that is so important in agile is this idea of accepting that you're bad at estimation, right? Yeah, and the power in this, the truth be told that I have witnessed is that even after what two weeks we worked on a project together in this team weeks model, Jonathan, I was a coach and you were a developer. You guys in less than two weeks time estimated higher than it actually was going to require of your time and you completed more than you took on in a given sprint and we had that much more to demo. That's just incredible. I mean, you're learning that quickly on the day. Yeah, it is really interesting to see how you start to expect to not get as much done just because of either some previous bias that you had. I have an tendency to believe that I'm to basically underestimate every single time now because of so many times of being burnt as a developer of overestimating what I could complete in a given amount of time. I'm very wary and I'm very careful, realistically speaking, and very careful about what I promise that I can get done. This has shown to be a really effective way of increasing the actual buzzword is going to be the velocity of what we do. Yeah, you guys are more productive and the momentum is greater and that's the win. What I want to talk about this estimation thing real quick because estimation, obviously, we talked about on the show before, the sandwich problem, you can estimate pretty easily how long it's going to take you to make one sandwich. If you tried to gut estimate how long it takes to make 100 sandwiches, you're probably going to be wrong. If you were to multiply one sandwich times 100, you're going to see a much, much higher number than you probably, this is most likely, you're going to see a higher number than you would have gut estimated 100 sandwiches that. A very simple proof. Let's say it's six minutes just because that's an easy round number. If it takes you six minutes to make one sandwich, it's going to take you 600 minutes to make 100 sandwiches and you would have never probably guessed that it would take you 10 hours to make 100 sandwiches. That's without any breaks, right? Yeah, an estimating in this agile philosophy is really, I think, a breakthrough idea that you can say does a PB&J take me less time or more time than making a baked panini with Swiss cheese and ham? Well, hopefully it would take you significantly less time to make a PB&J. Exactly. That's the answer. And without having to put a number to it, without having to put hours to it or a budget to it, you can say this will take more or less than this other task. We're kind of going outside of agile here because the discussion starts to center around this idea of degrees of confidence, right? I talk to my developers about this all the time. I don't know if I've talked about it on the show or not, actually, but degrees of confidence about something that you're stating. For example, I've talked to customer service representatives and I would ask them, for example, if something had not been shipped to my house on time, I would ask them, when is this item going, when is this item supposed to arrive? And way too many times the customer service representative will say something along the lines of, we have no idea, right? And this to me is one of the most infuriating lines that I can hear from a customer service representative because they do have some idea, right? In other words, if I were to ask them, so is it possible that this is going to be delivered in five years from now? Yeah, right. Well, obviously not, right? So they have a very high degree of confidence that is not going to be delivered in five years from now. They have almost a 100% degree of confidence that is not going to be delivered in five years from now. So if I were to ask them, is this going to be delivered between nine and nine thirty on Tuesday, right? They would have almost zero confidence in answering that question. Yeah, they would. And that's kind of the way to think about the agile way of estimating. Don't make it a comparison and then narrow it down by, well, that definitely wouldn't take me longer than two days. But I'm not sure if it would be a half day or a full. Well, then put it somewhere in that, in that realm, then to be safe, slightly overestimate what you think it's going to take, you know, say it's going to take you the whole day. If it could take a half day and you're not quite sure whether that's going to land, well, the best case scenario you over delivered to the client. So all of this estimation is really for a bigger picture goal that gets our team to understanding and measuring our own velocity without having to have an expert who runs numbers all the time. The coach actually looks at our estimations and what we were actually able to accomplish in a given sprint. And then over a few sprints, we actually figure out our real velocity. So putting these estimations, they're sometimes referenced as a complexity point, you know, from one to five, how complex is this task? That is what we add up and then begin to average out so that when we say something's a one, we start understanding more and more what a one is and how long a one is going to take. And then we understand that our whole team can accomplish, say, 20 points in a given sprint. It's really powerful and it doesn't take rocket science. And I've just been so energized and excited to play the role of this coach. I mean, for moments like these. And here's the reality. There's a lot of people who are listening to this episode and you've heard all of the stuff about Agile and you've probably heard of Bern. You've probably seen the burn down charts, you know, this hit pop like mainstream media when it was on Silicon Valley on HBO. They had the burn down chart and they actually show it working, which is really cool to me that this show would actually like somehow throw a bone back to the to the Agile world. But it's very interesting to me to see this stuff in a practical light, right? We've read all the books. And really simple. It's not that hard. I haven't studied really long and hard. I haven't practiced this for 20 years. I didn't go and get my scrum master certification and here we are and it's effective. Yeah. And to be fair, Warren's dad does have like every certification under the sun, but at the same time. And how many programming like good. Yeah. He knows so many things that we respect Warren's dad quite a bit. A lot. Hopefully he's going to hear this episode at some point. But, but yeah, I think that I think you're right. I think the best way to make Agile work and I want you to talk about it. I'm going to ask you kind of a really specific question. But I think just to to to tee this up, I think that the best way to make Agile work is to start with the simplest, most direct, valuable thing that you can implement from Agile. And I want you to talk about like if I were to do a single thing to test Agile methodology, what would that thing be like for myself? I don't want to take it to my team yet. I don't want to force everybody to adopt it in order to test to see if it's going to work. Yeah. I don't want to, you know, I don't want to go and read about complexity points yet. I don't want to have all these ceremonies yet. I just want to see if maybe this is going to be for me. What are the like one or two things that I can do this week to test out some of the philosophy in my own life? I would say take the to-do list that you already have and organize it in some way, whether it's Post-it-Nodes or Trello or Google, a con-bon board, it's key K-A-N, B-A-N, and put it in just a simple arrangement. Put all the things you haven't done in the do call. Have a doing column and a done column. And limit your work and progress to one thing at a time. And be it in a couple days or a week, see what you accomplish. So this is kind of like the user stories, organizing the user stories and putting those through the process of doing one thing at a time and then going into the done column so that we can see exactly what we've done in the past week or so. I'm wondering if this would be something that I could try like maybe at home with my, like the stuff that I have to do at home? I think that's a perfect idea. And that way you're validating, like for example, Lauren and I, this is a married moment here for a second. We often talk about what can we get done at night? And I have this tendency to think that I'm going to get 100 things done at night. And she has a tendency to think that I'm going to get like one thing done at night. And neither of us are totally right. And part of this is because the variability in doing a Developer Tea episode, for example. And so it's really like a perfect place where we could actually try this in our personal life to validate the concept of measuring and figuring out, you know, because the reality of human behavior is that we often act the same. Like we don't change a lot. And so we're probably going to do, I probably take about the same amount of time to do a Developer Tea episode. Even if it feels like some of them are significantly longer or significantly shorter than other authors, most of the time they're probably going to fall in like a standard distribution from an average amount of time that I have to put into it. And so if I'm actually measuring that time, then I can make a pretty good, again, a pretty good estimation with a pretty high degree of confidence that it's going to take about this amount of time to do this thing. Yeah. So start with your off hours. Don't make it about work. Make it about your personal life when you're at home in your weekends, your pet projects, whatever you want to do. I've seen this implemented in like a hundred different places outside of work. For example, I've seen it done for like a wedding planning is a really big one. There's books on actual wedding planning. There's also, for example, using this to get your kids to do their chores properly or in the most important order, right? Yeah. And even in the classroom structure, like elementary schools are using this due-doing done concept with post-it notes or three by five note cards. And it's really incredible what's happening. Today's episode is sponsored by Flatiron School. Now, we talk about learning on this program all the time. And Flatiron School is about learning. But they're more than just about learning. Flatiron is a premier coding bootcamp for launching developers into proven jobs. Okay, not only are you going to learn a ton from Flatiron, obviously you're going to get prepared for your career, but Flatiron also has a job guarantee. If you do your part, you'll receive a job offer within 180 days or your money back. So you have very little reason to worry about going into this program because you're very likely to get a job. In fact, 98% of Flatiron School grads find jobs they love within six months, including internships, apprenticeships, and full-time roles with starting salaries over $74,000. And that's pretty competitive pretty much anywhere that you go. Flatiron has placed people and companies like Google, IBM, Facebook. So if you want to join the ranks of Flatiron School alumni who are now working at companies like that, then go and check out Flatironbootcampprep.com or you can get a spec.fm slash Flatiron to learn more about what Flatiron is doing. Flatironbootcamp, this bootcamp prep, is totally free for you. Okay, there's free online resources to get you ready for Flatiron. They're providing that to you, not only is it free to you, but if you then go on to go to Flatiron, you're going to receive $500 off your first month of tuition. So head over to spec.fm slash Flatiron to learn more about what Flatiron School has to offer to you as a brand new developer or even if you have a little bit of experience as a developer and you're just wanting to step up your game or get into this guaranteed job placement program. Flatiron is the type of bootcamp that you want to be looking at. Thank you again to Flatiron for sponsoring today's episode of Developer Tea. That's actually a really, really cool idea because we were talking about this concept of meta education the other night and we discussed the fact that, and I think I've talked about this with Khaled Azad on the show in the interviews that I did with him, but we discussed the fact that we don't really learn how to memorize things, but so many of our classes in school require us to have memorized a large amount of information. My example was Spanish, but another example in high school was history, all these random dates or random people that I didn't really put together into a story. I didn't really understand how it all fit together. And so if I had had this meta education on how to memorize things, maybe I could have memorized things better throughout my years in school. And I think that management of a list of things to do, management of my tasks, management of my workload, if we can teach children how to manage their tasks better, especially this limiting work in progressing. I think this is really, if you walk away with nothing else from today's episode, this has really been more like a collaborative episode than it has been an interview, I think. But if you walk away with nothing else, limiting your work in progress, it does so many things for you both at an actual practical level, but also at like a mental health level. Right? If you feel a sense of anxiety because you have 100 things and you're doing 100 things and nothing ever seems to get done, if you've ever felt that, then this is definitely for you. We actually have experienced this with Lauren at home before and we have to remind each other, hey, take a second, decide what you think is the most important thing to do right now and then go do that thing. Yeah, absolutely. Or document it, write it down, prioritize it and then go do it. I mean, it gets the, you know, oh, we need to do this. Oh, we need to do that. Oh, we need to do that out of the way. And you're actually feeling accomplished and things that are actually needing to get done ultimately make it to the top of the list. You said something there that actually reminded me of an experience we had last week. You said document it. You know, both of us had this distinct feeling last week. Both of us had this on separate days too. I had this feeling that I had not finished everything I was supposed to do. Like I felt like I was still in go mode. Like I hadn't finished my day out and I didn't know what the thing was that I was supposed to do. So clue why I felt that way. I just kind of had that sense of urgency to go and get something done, but I had no idea what I was trying to get done. Yep. And you had the same feeling, didn't you? Yeah, I did. And I never really quite put my finger on it because we didn't document what it could have been or what it should have been. So there's actually, so that's actually a really good point. Taylor, the CEO at Whiteboard has mentioned this as well. He said one of his favorite parts of Scrum is that you have this end point. At the end of the week, you feel accomplished. So on the emotional side, if we're just talking about the emotional side, you have this moment of celebration of retrospective looking back at what you've done. You actually did what you said you were going to do and sometimes more. And you're validating that it's done. And you're showing it to someone else to validate that it's done. And the whole team has a shared definition of done. Right. And you can look at the documentation and say, yes, we did these things. And there's a sense, there's another idea. I can't remember who it came from. It's another famous podcaster out there in podcast land. But they talk about the concept of a shutdown. So every day at a certain point and their workday, they start their shutdown sequence. That lets their brain know. It's just a habitual thing. Right. They have the same rhythm. They have a sprint. They start an end to each day and to each week. Right. And so you have a shutdown that lets your brain know, hey, now you can chill out and you can go into this other mode. Whatever that mode is. So if you're headed home to spend time with your family, now you can actually fully be present with your family. And there's some of this stuff you guys know headspace is a sponsor of the show. Some of this comes back to being mindful and being in the moment. If you're doing one thing and your mind is on another thing, not only are you not going to do the thing you're doing well, but you're also not really serving the thing that your mind is on very well either. Right. And this puts beautiful boundaries on things. Like you can walk away at 5, 5, 30 even if something isn't resolved because you know what literally what is on your plate for the rest of the week and unknowns are sort of accounted for and your estimations aren't perfectly exact. So you can still close your computer at 5, 30 and not work till 9 o'clock in misdinner. Yeah. There's like a sense of closure in the day and a sense of like we all have come to the table and agreed that the work has been, you know, this week has completed. Yeah. So it's a very boring that unknowns and change are inevitable, which I think for being someone who if you've done the strengths, finders, test adaptability is like my number one. And even though I'm type A and organized, I mean, that's like empowering and truly you can organize for yourself in this framework. Yeah. Absolutely. Okay. So let's do like a very fast recap of what a scrum week looks like. And then we're going to wrap up the show with the two questions that I ask every, every guess that comes on the show. But let's do a very fast recap. What does a scrum week look like? It's a dedicated team of varying disciplines, one or more of each. And together you establish a rhythm that you are going to repeat, call it a sprint or an iteration. You have a sprint planning meeting where you've taken big ideas and features and broke them down at tasks and you estimate them. You queue them up and order them in priority and then you get working. And then on the daily you have a stand up and say what you did the day before, what you're going to do today. If there's any impediments, get to the end of the week or the sprint and you actually demo the work you've done as a team. And then you have a little retrospect and learn from what worked really well and what didn't. Very simple. And if you want to try this in your daily life, then you're just going to set up some kind of way of tracking the things that you need to do, the things that you are currently doing or better yet, the thing that you are currently doing. That's right. And then finally, the things that you've already done. And a very simple way to limit your work and progress, by the way, is put a number above that column, the number of things that are allowed to be in that column. Yes. It's a very effective way so that you know you're visually reminding yourself of the rules. You'd be surprised at how strong that visual reminder can be. If you see that reminder as you are managing that board, and Lauren mentioned earlier, I think it was in between takes. Lauren mentioned that you can even use like posted notes for this, right? That's where it all started. The agile methodology, you mean? Absolutely. Posted notes on a big wall. Yeah. If you go Google it, I think, nothing you mentioned that Lauren. If you go Google this, I think you'll see a bunch of people in a room with a bunch of posted notes all over the wall. Yep. This is even a great way to have even meetings outside of work, like say coffee talks where you want to just talk about topics or learn something together. You can even apply it there. So look up, I would say do a little bit of homework and look up something called lean coffee. Yeah. Lean is another part of the like the agile philosophy. That we are going to get in like deep into now. There are, it's also very like hot word. The lean startup is a book that has ray reviews. I actually haven't read it yet, but I know Lauren, your dad has read it and he is a huge fan of it. Yes. And have you read it as well? I have not. Okay. But that's all my objectives for this quarter. There you go. So we've covered Scrum, I think. Hopefully people who have heard it spoken in their firms or in their agencies or startups or wherever they are working. Hopefully it's a little less intimidating and a little less like process and HR, process speak and all that. Hopefully you're seeing now how a developer can actually be a champion of something like Scrum and the agile philosophy. But I want to ask you two questions that ask all of the guests that come on Developer Tea. The first question that I like to ask everyone who comes on the show is if you had 30 seconds to give developers advice, just 30 seconds. What would you tell them? That's a great question. I know today it sounded like, you know, I'm talking mostly about process and strategy and tools and a way to manage projects and people. But I would say remember this out of everything else, focus on individuals and your interactions with them over processes and tools. Because I think this is what was eye opening for me in learning what I have and just seeing the effectiveness of it. So individuals and interactions over processes and tools any day. Isn't this, that sounds familiar to me. I'm pretty sure it's because it's in the agile manifesto, isn't it? It is. That's the pioneering value. And I think in my own journey to try to teach it and incorporate it and infuse it in an industry where it's sort of taboo, that's the thing that has won. Stripe away the jargon, focus on the people and the way they're interacting with them in order to try it or teach it. So that could mean that like if the language of agile or the language of scrum, if somebody has like a bad experience with a poorly implemented agile, you could abandon all of this language altogether and still get the value out of the underlying processes, right? Yep. And really through this, you and the people that you're interacting with are discovering the best way to work together. It's not, you know, prescriptive. You don't need to go read and research and implement it. Focus on the people that you're working with and how they want to work with you in this way. And you guys define what that looks like. So what that means is just because it's working for us in the way that we have implemented and experimented and tried it again, doesn't mean that it's going to work for you exactly the same way or maybe in most ways that I've described today. So it's adaptable. It's shapeable. And you know, if you need to have a sprint in a half a week or you need to chop up your sprints in two days every week and only do a stand-up one of those days, we've done each and every one of these that I've just mentioned. And we're going to find new ways to work in the future. Be it the client has less resources than the other client or the team needs to be bigger or smaller based on the project. It really is adaptable. Yeah, I think the thing that I've heard you say over and over is that the most important part of this is the iteration of it and learning from the previous iteration. Like what are we doing and what can we do better? And for example, what if we threw two product owners into the mix rather than just one or what if we didn't have a daily stand-up? How does that change things? What if we did daily stand-up over, I don't know, if we did it over Slack or something like that? Yep, we've done it before. Love it. Do it. And there's no reason why you can't experiment. That's very cool. And hopefully again, going back to this thing of like trying to get Developer To champion this cause, the whole point here is to create a way of evaluating what you're doing. Now we see other people, what they've done, what has worked for them. And the whole point of Agile and Scram is to give you an evaluation method, right? Like, that's the whole point. Value delivery is really the whole thing. You know, like do something valuable with your time and be able to account for it. Yeah, and then go back and learn from a measure front. Absolutely. Value-driven work. And we've come back to Agile again in your 30 seconds of advice. Here we are back at Agile again. What's that other question? The next question is, what is one thing that you wish people asked you about more often? Can I go two ways with this, Sanser? Yeah, absolutely. Let's go serious first. I wish more people would ask me about what it's like to work with your husband and how that actually impacts your relationship and friendship. People have the tendency to reduce their idea of us working together to that of our marriage or the way we interact. And I would say it's work. It is different, but it has built and strengthened our marriage conversely. I think we chose the harder route by choosing to work together as peers, you know, neither of us or bosses of one another. And learning the proper forms for having emotions and feelings and being the wife of someone who's either proud or stressed out by their spouse at work and channeling it and doing the right things with it so that we had a really killer or have a really killer relationship at work and similarly so that our marriage is that much cooler in the end. Do you have a story of like an assumption that somebody has made about us that you can share a specific assumption that's been made about us? You know, maybe I got hired because of you, but that interview process was really, Taylor and Eric did such an incredible job of bringing me in by my own merit and interviewing me. Pretty, you know, they were tough on me. And it was a two hour conversation, three hour conversation. It was awesome and made the delineation and very clear directive that if I didn't think I could do it, we shouldn't work together. And I thought that was really powerful. So we've been charged by great leadership, but we also had to make a decision personally to be better friends, to be better peers, to be better co-workers. And I think that's spilled over into a marriage. I think it's made our marriage really cool. Yeah, I would say that if she got hired just because of me, that that would be a really horrible business decision, right? Like, and Whiteboard has succeeded after that decision and Lauren has leadership that's way outside of my, like, she has her own entire set of leadership that I have no bearing on. Like, that's totally, that would be completely easy to remove, like, remove all doubt. It was, it was as if I had brought, like, just a person from Atlanta to interview at Whiteboard. Totally. But, you know, we're still humans and sure we fought over Slack, but we've learned not to do that in the... Oh, yeah. We've definitely fought over Slack once or twice, but it was something that we, that we eventually learned how to avoid doing. I do think it's important that we're at least honest with the idea that relationships are still important. Like, there's, there's no way that going into that interview that it was totally removed, like, just because it was, they were aware that at the time you were only my girlfriend, or we were engaged rather. Yeah. But, but just because they were aware of it, I think that that, that can't be removed from their decision making, but at the same time, relationships are always important in hiring, right? Like, having a good relationship with the company that you work with, or with someone on a personal level, that really is what it comes down to. Yeah, it's called triple. Many times. Yeah, absolutely. Culture building, for sure. But, I think it becomes really important to draw the line between, you know, showing favoritism because of the relationship, and actually just knowing someone is going to be good for a job because of a relationship, right? Yeah. I knew you very well because we're obviously we're engaged. I knew you very well. I knew your personality, and I could see a fit for you in the company. And so that relationship began from the perspective of seeing a fit. Oh, yeah. We shared values. I mean, we were in a relationship with value alignment, and that spills over into the culture of a company and the values that they promote, you know, so we aligned there as well. Yeah, and I think a lot of people, unfortunately, they don't see perfectly eye to eye in a romantic relationship, and also in a work relationship. And so we're very blessed. We're lucky to be able to do that together every day. Yep. Okay, so talk about your, the other, the second answer that you have to this question. I love the fact that I had these really vivid obscure childhood nightmares, and they were repeating enough for me to remember about five of them, you know, vaguely I can say that they repeated, but enough that I can still envision them today. One of them involved Jeffrey, the giraffe shooting me with a shot so I could never go to the bathroom again. And it's the most horrifying thing. I love retelling these stories from my childhood of my crazy vivid nightmares. My guess is that you will probably pass that on to Liam, our son. I hope not. One of them involves fud records. Another one involves floating down the stairs. Lots of weird ones. That's great. Yeah. So if you ever see Lauren at a conference or something like that, then walk up to her and say, thank you so much for teaching me about scrum. Also tell me about Jeffrey, the giraffe. It's perfect. Lauren, thank you so much for coming on the show and for being a part of Developer Tea. All of you who are listening, by the way, let me just say Lauren has been behind the scenes. By the way, she just trivia for everyone. Lauren designed the Developer Tea logo. I did. I had the honors and somehow it made it. Yeah. It's the same one that from two long years ago. We've cut the same one. But yeah, Lauren has been such an integral part of what this show is just because she's supported me throughout all of it. You know, this show isn't done like as a full-time day job. Hopefully you all know this. Obviously, we've been talking about whiteboard this whole time. But this show is done at nights, right? Or on the weekends. And Lauren has supported it throughout this whole process. So you all who we heard a huge thank you for being so gracious to me as I go through the process of making this show happen each and every week. So thank you so much to you, Lauren, for being so gracious. Thank you. And thanks guys for listening. Thank you so much for listening to today's episode of Developer Tea. My interview with Lauren Cutrell, my wife. I was so excited to do this interview. So I hope you enjoyed listening to us discuss the type of stuff that we're doing every day, a whiteboard discussing scram and agile and hopefully, hopefully demystifying some of these terms for those of you who are either new to the industry or maybe disillusioned by some of the project management stuff that you've heard over the years. Thank you again to Lauren. If you want to follow Lauren's progress and see what she's up to, go and follow her on Twitter at Lauren McKay. That's L-A-U-R-E-N-M-C-C-A-Y. Thank you again to today's sponsor, Flatiron. Flatiron School is the premier coding bootcamp for launching developers. They give you a guaranteed job or your money back. 98% of the developers who go through Flatiron's program end up getting a job within six months. So go and check it out. Spec.fm slash Flatiron. That'll take you to their bootcamp prep, which is totally free. If you go through that, end up going to Flatiron, you'll get $500 off in your tuition. Thank you so much for listening to today's episode of Developer Tee and until next time, enjoy your tea.