 We're going to talk about my journey with leadership. So we're going to see some photos here, some of which might be a little cute. Some of you have probably never seen any of them see these photos of me, because if anyone else has my house, it's going to be cute. So I want to tell you where it starts. And it starts with me as a baby. Apparently, I had plans. And they may be more good plans, but I was going to ask you on them. I was fearless. I was interested and curious. And it started early. My dad told the story when I was five. My sister was two. We were in San Antonio at Marriott. I think my dad was at a dental convention. And somehow, I took my mom and took my sister and left to learn the hotel. And hours later, we were discovered by housekeeping in the basement. I apparently got in a service elevator and got all the way down there. So I'm sure my mom was freaking out. But anyway, that's how it began. And I believe I never really slowed down in terms of having that drive and wanting to take risks and do interesting things to me. My next chapter is in the Boy Scouts. And I'm the one here in the middle holding a film on sign. This is not your 12th year, so pre-Teen Marty. And Boy Scouts for those that you don't know, they trained their boys to lead and the boys actually run their groups. They run their patrols and their troops. So 12-year-olds, 13-year-olds are put in charge of running these outings and all these activities. And so at this young age, I was trained, at least in several levels, to be a leader. I don't know how good of a leader I really was. I don't have that good memory of that, but I was put in charge of things. And so it went on. The next chapter was me after high school in the Army. And I must have super-graded my parents and some of my friends. I decided not to go to college and joined the Army instead. I was not a leader in the Army, though. I was a supply manager, followed up orders, and was part of a large team. And so it was a very good experience. I didn't always agree with the orders I was given, but I recognized the value of the team and the value of that structure and strong leadership. And all those experiences started to build my sort of understanding and beliefs around leadership and how that can help things go forward. The next chapter is sort of the not unexpected chapter. And that was being a parent. I would learn more about leadership and about meeting folks and dealing with adversity and challenges and surprises as a parent. And with my current sort of roles various leadership positions that Jeff is alluding to, I've drawn more on what I've done to be a good dad to be effective there. So we already have a little bit of my introduction, Jeff, I did all these things. These are the things that I do now. I think I'll have some form of, I'm in the formal role of running, how I could work to mention, have been running that for 13 years as a business owner. And so many challenges, running a small business. As a software consultancy. So not only am I working with entrepreneurs and businesses to rescue their software, build software in any way, ship their products. I'm also dealing with the internal struggles of teams and communication and just solving business problems internally. Like how, I've been doing mistakes for five years over the years and I learned, I adopted. And so many lessons came from that. We had Boulder Ruby, which actually originally was the Boulder Denver Ruby group, which I felt bad that Denver didn't have any group. So I tried to split and I realized that wasn't gonna work so well. And then I picked Boulder only. Luckily, DeRail started shortly after Boulder Ruby started. So that was nice for non of those guys who were able to run DeRail for so many years. But that's against small organization of a media, which I still run, so it's been 13 years actually. Boulder Ruby's been going on. And at Ruby Central, it's a big nonprofit where we're running Rails company, Ruby company. There's different leadership challenges that are involved there. And finally, Boy Scouts. I am an adult volunteer with my sevens troupe in Boy Scouts Nationalist Weekend on Sunday. I did their leadership training for the boys next round at Boy's Day for leadership. So I think a lot about leadership and I think about it in a lot of different ways. So the question is, what is a leader? And we can look at the dictionary here, if it works. And this is fine, but isn't really a very useful definition. It's a little too broad for my taste. We can certainly look at some iconic leaders and you can see that they come from all different kinds of backgrounds. Some of them aren't very formal positions like they're political leaders or they're military leaders. But some of them aren't just they start the movement and they're gonna make it happen. No one put them in charge. They just took lead and made it happen. And so leadership can happen really anywhere. We have some other examples that perhaps I'm trying, but maybe you're not the ones that want to make it. Maybe, it's like we all are, you're not really a leader because these are many leaders that we are forced to follow or at least deal with, avoid or whatnot. And so it does really bring up the point that just because someone's been hired as managers because they've been put in charge of them or people doesn't really make them a leader. So what is leadership? And here's a definition or explanation that I found recently that I really like that we're gonna come explore briefly. So the first part that I like to highlight is that it's a process of social influence. But this process isn't really defined, it's not limited. So it could be like they're given authority or given a role and you've got to give folks orders or whatnot, that's true. But it could be in sort of influence. It could come from like you're just leading from behind or you're helping out your group in various ways. And these are all forms of process or social influence. The next piece here is that it maximizes the efforts of others. So by introducing the efforts of others, we're talking about a team, a regular group. And after your point of your leadership is that you're maximizing. You're trying to make your group stronger, make it better, make it produce more, whatever is important to that group, you're maximizing whatever it's doing. And there are lots of ways you can accomplish this. Finally, there is a goal we're working towards something. Leadership has some direction. And this is important that we not only sort of acknowledge this goal but we keep in mind as we decide what we're going to do. So as we sort of kind of come to this conclusion, to be a leader you have to hurt it. It's not something that should be given to you. You're not really a leader at that point. And we're gonna talk a little bit today about what that means. There are many paths to leadership. Certainly my path was that I had this great drive and curiosity of the world and I was just going to make it happen. Whether that was a good idea or a bad idea didn't really matter or I was gonna make it happen. And that's been true for most of my life. Luckily, as my experiences grew over the years I got a little wiser and smarter about some of the things that I did. I can tell you that looking back at different points in my life, I shook my head like really, I did that. What was I thinking? And so for each of you, your path to leadership might look completely different. It doesn't need to look like anybody else's. It doesn't have to have that formal route. It doesn't have to have this, I was born to be a leader kind of thing. It can come to it in different ways. So what I'm curious to explore is what is this like in software? Let's be a little more concrete, a little more specific. This is a quick list I put together. This is not meant to be said if there could be some other things to be here. But when I think about a technical leader these are some of the things that I think they're going to be doing. The first piece is kind of probably the obvious one that we would think about is the fact that you know how to build software. And I can be actual writing code, that's how you make sort of like high-level architecture design, how you go about communicating with your team and the process of which you go through to build your software and ship it, maintain it and all that. So there is this knowledge piece that we know what we're doing actually in the software. Second piece is they make technical decisions. So yep, yep, we expect a leader to do that. They don't have to always be the one to make a piece sort of driven by a group process but ultimately they're responsible for the technical decisions happening. There's this communication piece here, communications is pretty important for teams and we're talking internally so how does the team work together but also outside the team. So like how do we work with users, how do we work with business interests, how do we work with external providers and services that we need. All of these things are important especially if you're doing anything complex where there's lots of coordination that communication becomes either more important and thus the technical leader needs to own this piece. Mentoring others, I think this is a one thing certainly this community has embraced and now when I look out there at the greater software community, mentoring is a very common term that we hear. Certainly when I got started with doing this in the 90s I don't think I ever heard mentoring ever mentioned when I was doing software. I mean it happened in a way but it wasn't spoken, it wasn't something that we actively did. And then finally that's a good example and I think this is all true. So what's interesting though about this slide that you really look at all those five points what if this wasn't a leader? What if this is just a teammate of yours? Wouldn't you want that person in your team? The answer is yes, at least I would say yes. These are fantastic and so the thing is you can have leaders at all different levels in your software groups, new teams and they don't have to actually be in a formal position. So one question that I get fairly often is part of the difference between a senior and a middle-level developer. And not that I contend for this slide to be definitive either, so that's a very sort of complex nuance in a lengthy discussion. It could be an easily talk on itself, probably make a conference on it if we wanted to. And, but these are some of the things to stand out for. So one of the things is I don't have to tell a senior what to do. I do have to give them some direction, like here is what I want you to accomplish, like here is what I want you to build, here's a system I want you to design, here is this team that I want you to kind of work with. There is some sort of like here's your mission. But I'm not going to go in and tell them how to go about doing it. I know they know how to do it. I trust them to do it and do it right. I don't have to babysit them, that's great. I know how to work effectively as a team. They have that experience and they can do that. And that definition comes up and they always do. But they'll be on the handle. This, to me, is some of the biggest separation that I see between a senior developer and a middle-level developer. And so when I look at these different points, I see them as examples of leadership or life leadership. So a senior developer, at some level, has developed these leadership capacity that they now use to do their job. So, we're now going to transition to talking about how you, as an individual contributor, as a junior programmer, wherever you are in the journey, how you can do some of these things, the things that you can use to cultivate those skills and become more of a leader before you're given that position, before you're ever put in that place. The first piece is you lead by understanding. We are knowledge workers. What we know or know how is so crucial to what we do in our job. So understanding and knowing what we're going to be doing to keep. So the first piece here is knowing the purpose. What is the goal of your team? Your product, your business, sort of what is your, what are the goals that users might have when they want your software? Do you know these things? If you don't, you need to find out. You should ask. And then once you have that, it's going to guide you to work. So many times, day-to-day, we make tiny decisions about how to implement something, how to design something, what's your approaching take on the software you're building. If you don't have answers to these things, if you don't have that bigger picture, you're going to be working in a vacuum. You're not going to know whether you should go this way or that way. And so many times when I've seen over the years where you might be given a task, you know, a business owner has asked for a specific feature a certain way. And maybe they didn't think about it. And a senior or myself or someone will catch it and say, wait a minute, this doesn't make a lot of sense. Like, I thought the purpose or the goal of what we're trying to accomplish is this. This seems to cross purposes with that goal. And so that sometimes will be asked to these things. If you don't have this big picture, you can't be effective there. Know yourself. We've already touched on this today. I left the feedback piece earlier if you can read any questions. And this is, this is pretty important. We do a lot of relationship stuff with PotcoWorks and I've done a lot of mentoring over the years. And one piece I've noticed is that often times these juniors come in and they really don't have a good sense of where they are. They might think they're more, they're further along than where they are or they might actually be very down on their own abilities and doubt them. And so really getting a good bearing of where you are is super important. So here are some things that you can do to sort of build this self-awareness that you can now have a better sense of yourself because you're gonna be meeting this. You have to be honest with yourself also. You know, it's okay. Like I'm not gonna put my life where I'm old enough to like I am who I am and I accept that I have faults we all do and I don't have that bluster that I had in the 20s where I thought it was just hot shit and it was amazing. And then reality around and I realized, oh okay, yeah maybe not so much but you need to use this place where you're okay with this. You need to have that time for self-reflection. You know, go and learn about kind of bias. There's all these ways that we maybe put on sort of blinders who are not aware of what's around us and how we're interacting with the world. And this is very important to how you can grow and become a better person and a better developer and leader. The flip side is knowing your team, people around you. We're all different. We all have different values, how we're gonna work, communicate, how we learn. If you don't know how to interact or relate to your fellow teammates, you're not gonna be very effective in an interaction. So start paying attention to this sort of thing. I'm not just suggesting that you like make dossiers on folks but like you can certainly get to where like, oh I know, like Andy loves to learn this way, right? When I'm talking to me, this is how we're gonna sort of work through a problem and I know she'll get that because that's how she likes to sort of communicate. And so sort of build up this awareness. I almost didn't put this in. I feel it's almost in the obvious category but I do wanna stress this that our industry moves so fast. How we built 5, 10 years ago, 20 years ago is many ways so radically different from how we work today. So you have to be continuously learning. Now I know for those of you there in the touring crowd, you have this sort of like, life-type learner model and that's fantastic, that's exactly what we're kind of going at here. But here's some of the things that you really need to stay on top of. You need to understand the trade-offs of all the technologies, tools and processes you use because there are trade-offs, there's nothing, there's no silver bullets, there's nothing like, yep, we're always using Ruby or we're always using whatever like, you just haven't seen enough to know better. But there are trade-offs and you have to understand what the trade-offs are. You also need to write your knowledge so that when you take all these tools or new methodologies or wherever they are so you can evaluate them as well. You can have intelligent conversations with your team with, you know, manager or whatever about why we should go in this direction, why we should sort of advocate for use of this new technology or not. If you don't have this, then you can't be part of that conversation. So the ability for us to make decisions is as much as what we know. It's very important. So these are all different ways you can go about that. And it's going to be the foundation that you're going to be using in your work. And sort of as sort of a wise lesson I got from 80s Saturday morning cartoons knowing it's half the battle. Lead by example, right? So this is probably something that you've heard countless times. Of course, leaders lead by example. And it's true, it's actually very important that this is indeed how we are. And we're going to start off with talking about how actions matter. And you need to model, behave and the value you expect for your group. And you can do this when you're just beginning on a team, when you're just new to a team or like you've been there maybe a year, you'll have to be a senior to do this. You can identify what is the behavior, the values and the way of working that's important to this team or to me personally, any model. You make sure that you're accountable for how you are here. Because it's going to be the basis of which you're going to set an example. And influence your team. Acting with integrity, this kind of falls up with that. You can't really fool people on your team. You know, if you're not, if you can't really walk the walk, if you want to go really, if you are authentic, they're going to totally tell. And what's worse is they're not going to trust you. They're not going to respect you. They won't want to work with you as much. And that's not a good place to be, especially if you want to be a positive influence on your team. So acting with integrity. I would say that most of us have this drive to deliver quality, but you might not have the first full way about doing about it. And I think that if you want to sort of step up to the next level, be that example, sort of lift up your team, you need to definitely deliver quality to be to have these high standards and you need to strive for excellence. Now this is like, how would you go about doing this? Well, one of the concepts that I love, we haven't heard about it, is called kaizen. It is a Japanese philosophy of continuous improvement. It comes from the Toyota Protection Systems of the 50s, so we manufacturing deferred that term. And kaizen is this idea, it's got a few parts, but one is the philosophical part, what's sort of the action part. The philosophical part is that you have this culture, where you're actively engaged, you're looking for ways to constantly improve and make suggestions and make everything better around the way you work, to all the way to where this becomes your way of thinking. And I myself personally, this is just how I've been a long time, so when I finally came around to seeing kaizen, I was like, this is awesome, it's exactly what I love. And sort of if you ever want to become a better person, you have this personal growth, you wanna go through, this is, you're gonna be doing kaizen for yourself. So what does that look like in action? This is what they call, it's pretty straightforward, it's sort of a very scientific method, you will. They call it the kaizen event, but it has really kind of four basic steps, when you check and act. So the idea here is of course you're playing out, what are you trying to prove, like what's your approach to that? Great, okay, cool. Now if you do the thing, it's not quite like drawing the album, it's similar. And then didn't check, so you have to measure, like did it actually move the needle, did it actually get improvement? You have to evaluate this very data-centric, let's see results. And then finally, you adjust and repeat as necessary. And lean start-up is what is that? Also has a similar kind of feedback where they're constantly using this build learning loop where they're iterating very quickly over, over their software or their process to make it better. So all this kind of comes from the same source. So the thing I would say here is that don't underestimate how important setting this example of how it will be, and that you're growing, you're getting better, it's gonna be on your team. And the other piece to kind of say here is that people are gonna notice, they're gonna say, wow, so-and-so is really just kicking ass, this is great. Like they're gonna see this, and it's gonna start to snowball on you where you're gonna get better and better, and you're gonna just all of a sudden, it's commotion, it's gonna be awesome. So I do wanna stress this, it's really important part of becoming the process of these leadership skills. This next piece is, falls into sort of the intangible category of wills. It's kind of the, I hear like, go near for a while, kind of sort of phrases and whatnot. This is kind of this area. And I group this first one as sort of nothing gets missed. And this is the idea that, especially if you're doing a sort of fint or sort of complex process of what's going on, it's very easy for those that are planning to miss something, to not realize that this step hadn't been done or hadn't been assigned to someone. And this is the idea that you're looking out for those sort of things. And you're being proactive, you're not waiting for someone to assign to you, to tell you to do this. You're gonna say, hey, I noticed that this thing needs to be done, and either you're gonna communicate about it. So hey, look folks, this week, are we gonna do this or are we skipping it? Or I'm just gonna knock this out. This is that idea. This is not the, not my job thing. Like, oh, that can't be that, so I'm not proved to do that. So I'm sorry, pass the buck, use someone else's gun to do that for you. Again, just drive some bonkers if you get that over and over again. So this is not that. And also here, I put this, no job is beneath you. Like, if you see the floor needs to be swept, you know what, I'll just grab a broom and I'll do it. Like, I don't mind all of my sleeves. I don't care if I'm the boss. I will do whatever job it takes to get done because that's what leaders do. And that helps the group succeed, is that we make sure we don't miss something. Being autonomous, this is, might be a little obvious, but this is something that I want you to work towards if you're not there yet. This is sort of kind of like, now I know I'm a senior almost, but this is the idea, that you don't need someone else to direct you. That once you can give it enough like, here's your task type information, that you can be self-reliant, that you can now go through and get whatever you've been assigned done. And I say here, or your reputation with a team knows you're delivered. Well, if you assign it so and so, that's gonna happen. I know it'll happen and it'll be done well. That's where you wanna get to. So, this isn't a lone wolf mindset. This doesn't mean that you're like, yep, I got this. Nobody knows how I'm not gonna talk to anyone. I'm gonna go off my own and knock it out. It's not that. You still keep a team-first mentality, but that you don't meet others to make sure you do your job right or that you get it done. So, still find the ask for help, and I'm just suggesting that's us to take, that you wanna get to where you are self-reliant. Oftentimes when I am sort of talking with other leaders and other people of managers, these are all the kinds of things that they look for. And I've noticed in the years that they're really good employees. The ones that I feel comfortable putting more tasks on are the ones that do these sort of intangible pieces. So you wanna be a lead by lifting others. So this is the idea that you can maximize your team. You can help your team by helping them out. So, here is this look to help concept. This is that you're keeping your eyes out for ways that you can help someone struggling. I've got some examples here. Maybe you share some tip or approach, some script you've adopted. This really makes a difference, making more productive. This is the share of talent. So that you're trying to, anything good that you've sort of come across that helps you do better at your job, you're building that out to your teammates. They're going to run back. They got obstacles in the way that you can help out with. These are all ways you can help. And that helps your team. The next piece is mentoring. Teaching is fantastic. I think we've kind of already established this. It's a problem that already you've heard a lot about mentoring. But it's super important that this is something that you can do. And you can do it even when you're starting off. You don't have to be a senior to give back and mentor in some ways. And actually with my apprenticeship and things that hot code works, some of the best mentoring interactions that I saw was when sort of an early mid, our advanced junior was working with another junior. It's fantastic. So I encourage you all to look for any opportunities where you should mentor. But that is a hardware practice. So even though you might not be a leadership role, you might have your job certainly helping out and mentoring is something you can do. So we've talked a little bit about communication and how important is the team. And this is something that I see as a real difference maker for folks getting started. Because in our work, understanding what we're building, understanding what people are doing is really important and communication is how you arrive at that understanding. So it's a course of effective teams. I do want to stress here this idea that you practice with me through your communication. And we'll get to feedback just a bit. But like this idea that you are aware of how you're talking, the words you're using, how you're relating to your teammates or where you're working with and are you being empathetic in terms of that? There's a lot to go into there. I won't get into any specifics, but this is something that you want to think about when you're communicating, how empathetic are you being? Listening to learn is a great way of thinking about when you're taking information. And I think you have this Katrina that was mentioning this with TV, the International TV, the PR, like last curious. It said like, I can't believe she said I did that wrong. I'm like, that's interesting, why? I don't know why I would do that. Or why do I do that one piece? Or why do I write a quote that way? And this is the same idea here is that you're hearing something, you're taking information, and maybe it doesn't make sense, but you should be sort of like a detective and find out what is that? Why? Why are they different? Why are you reacting? What kind of learn from this? Our communication piece is something that we do quite a bit of hot coders, we're a distributed team, so we're not physically together anywhere. And so we stress this over communication piece where we're always communicating, we're using different methods for communicating, and that everything is available up there, so if someone is not around, when a conversation happened, they can get to a lot of that information. And so if you are remote or if you're on psyche, you think about how well are you communicating? Are things being siloed or being, only discussed for water cooler, or are they only happening in certain meetings and the rest of the group isn't aware of it? So you as an individual contributor can make sure that you're really communicating. Everyone's clear about what you're doing and you're understanding what they're doing and what's happening. So we'll talk about feedback. It is a gift. It is a really important way to teams improve. And I was just tickled when Jeff went, the feedback round on the questions. So we're gonna talk a little bit about that now. So here's a thing. If feedback, both in how it's given and received, is done right, it can be very, very powerful. It can be very inspiring and motivating for your team. If it's not done well, you can imagine that can be destructive to relationships. You can kill morale, you can create distrust. And so it's important that you think about how you give feedback. Creators doesn't thrive it. It's what that in there, you should never be criticizing publicly because it's just shaming and that's not gonna be conducive to what you want. So getting feedback. Here's a little acronym that I like to recommend that sort of, this little framework for how you can give feedback effectively. And it's called ASC. The first piece here is as actionable. You should have an outcome in mind. What exactly are you trying to accomplish by doing this feedback? What do you expect is gonna happen with this feedback? Specific. It should be concrete and detailed. If you get into a generalized, I'm just, you know, you always do this or whatever like that, exaggeration, probably not true. Also, that's a lot more of a tacky, sort of a tactic that you're using there. You can definitely hear when someone says something like that, that there's sort of a wounding or some sort of issue frustration that they have internally and they're now letting that come out. So it means specific. It's pretty hard to argue when you get all specifics about this happening. On this day, these things happened and this was the outcome of that. And so let's talk about what we can do to make that better. And if I'm kind, there's lots of ways you can get this feedback. You can be tactful. You can still give them the feedback. You can still say like, this wasn't good. This was bad. This was, this was harmful. Or whatever it might be, you can say that in a way where they know that you care and that you are being kind and how you deliver it. That makes it a little bit easier for that feedback to be received. So on the other side, we have receiving feedback. So the first piece here is self-awareness. You have to be ready. If someone's giving you feedback and we're gonna assume this feedback is probably critical. If they're getting positive feedback, that's gonna be like, oh my God, I don't know if I can take this good feedback. We're talking probably about critical stuff. And you wanna hear this though. You have to get to a place where you're okay with this. And here's the thing about a lot of this is that it's not necessarily about you. Almost all of this stuff is about your actions. It's about the things that you've done. And that doesn't mean that intrinsically you can't do better. That you can't be different because you can. That's one of the most amazing things about us is that we're so adaptable, we can grow. The way that I was, when I was with my children, we're so different from where I am now. And I see them, my kids, I see there's so many people. So as long as they're willing to do the work, it's right, they can get to where they can make it better. So if someone tells you something's not good or you're messed up, you wanna hear that. Because if you don't hear it, guess what, you're gonna keep doing it. And people are gonna know that I'm like, oh, that's that, you know. He always does this and he always does this and you know, likes, whatever. I'm gonna give up on that personally because I don't think that they'll ever change. Well, you have to receive that feedback because that'd be possible. So again, we have nice and accurate and active. First piece is accept. And there's a lot to this. I'm reaching fairly brief, but there's body language. You can tell it's like, look, I'm ready to receive feedback from you. Like I'm interested, I wanna hear what you have to say. It might be painful, but I'm open to that. And so you wanna show it in body language and your demeanor and everything you can. You have to take it, that's fine. But like, do your best. Clarify. I'm gonna plug active listening. Oh, that's a, you look this up on your own time kind of thing. I don't have the time to go into active listening. But active listening is a technique you can use when you're taking the feedback that allows you to really fully understand and be able to take that in and put to action. And I think the thing that you guys touched on earlier was that if someone is going to be effort to give you this, no, they're saying they're not an asshole and they're supposed to be, but if they're doing this in a trying to help you out really way, they're not persistent or whatever, then there's some truth to what they're saying. So in their reality, their perception, their viewpoint is valid. And so you need to take it, it may not be your viewpoint, it may not be true all the time, but it is at least true in this one instance. And that you should think about that and think is this, maybe that's more true for more folks. Take it in. And finally, you might know from providing valuable feedback. Now what you do with this feedback is it's only a different matter and you don't necessarily always have to act on it, but it's good to take it in and reflect on it. I like to plug a book called Rattler Panda. And I love this graph, I love the quadrants here. And what we're talking about with this given feedback really kind of falls in the Rattler Panda category where you care personally, but you're willing to challenge directly, you're willing to give them that tough feedback and say this is how you didn't do so well or whatever it is. Something is probably uncomfortable. This is not gonna be an awesome conversation, but it's the one that needs to happen if we're gonna grow and things are gonna get better. And so that's this quadrant up there, Rattler Panda. The one I like here, the other one is rudeness and defeat. And this is where you care personally about someone but you're not willing to challenge directly, you're not willing to house our conversations. And so that's kind of like letting them walk around like muster their shirt, they don't know, you know, embarrassing like, I've never heard their feelings. Their feelings are already hurt, but they never realize is that they're acting like an ass or whatever it might be, no one's willing to challenge them. So rudeness is actually the worst at all before. So I think we'll say here that kind of right when I'm pointing out here of the talk is that this isn't easy. I'm not suggesting that this is gonna be something you're gonna knock out like a month back and I'm gonna take that off of you now. Bad ass now. It's not gonna be that at all. It's gonna take time and effort. I mean, I personally, I'm not sure how long it took me to do a lot of work, but it's been many years. You do need to be intentional. You need to set out a plan and start working on this. And I would just say to get accepted at a time. Don't try to do this all at once. Think some area and start working on that. Good to practice. Make sure you get it down and move on. So like if you can hop into a DeLorean and like fly your way back to like the 80s and see like T.H. Marty or everybody you can see Marty back in the 90s or not, you know, it would have been rough. I've grown so much of those years and it's something that we all have this journey where we're at this point in our journey and we want to go there. We're gonna have to put the hard work to get there and be easy on yourself. You know, give yourself space to grow and get better. But you can do it. And the thing that I, when I was kind of thinking about all of this talk, I realized, you know what, like being a good leader is actually just being good. Like whether you're in a leadership position or not, if you do all those things, it's awesome. Like, everyone's gonna like, why don't you be on their team and be around you because you're gonna look to them. There's so many positive things about doing all this work. It may be really hard, but it is totally worth it. So, in closing, I just wanna say you don't need a title. You don't need to be in an advance position. You can do this and you can be a leader now. Question in the cigarette, Marty. There's a saying or like rules known kind of in startup world, small company world that the company takes on the characteristics of the founding team, right? The, that tends to be their strengths and weaknesses. Do you think that plays out in teams within the larger company? Like, does the team of eight developers led by one person as a team doesn't tend to work like that leader? Yes, absolutely. I've seen this to be true. I think that certainly my own teams, they're probably, there's a, they're pulled a little more towards them, more direction in how they interact. And for a better or worse, that's true. I've worked with a lot of different teams, organizations over the years, where those that were in charge clearly set the pattern. They set like a sort of irrigate with like, this is like what we expect. These are their values. This is how we're gonna work. And so people just sort of like pick it up and they just kind of, they fall, either they fight it and they leave. It's bloody or it's rough. Or they adapt, you know, like, okay, I was online and I'll be like, I'm supposed to be here. So I think it's definitely true. Related, there's an idea that you think about and like the growth of teams, where again, like I think that it's kind of set or plays out frequently or whatever, that if you have a top level leader, CEO, head of the company, whatever, then there's second tier right under them that most often the successor CEO does not come from the second tier, it comes from the third tier because the second tier is set up to like compensate for the weaknesses essentially of the leader and the third tier is really where there's like the same kind of entrepreneurial spirit or like leadership characteristics and so forth. Like I'm curious, have you seen that play out and particularly in your work with kind of parachuting into other companies in their growth cycle, when you jump in, like what are the things you observe in these small, like high growth companies? Yeah, so I think certainly there is sort of following the patterns that the individual set up, sort of there is how we communicate. These are the current tendencies that we create about how we work together and how we're successful together. And so back in Korea, I think it was like sort of like a people coupling that they get comfortable with. And so if there's a lot of change, you have to break that up or it won't work, like they won't change, it won't adapt well because this is how we work, this is work for us. We don't really want to change, we don't live and that's tough. And I think certainly I temper how aggressive I am when I have a client comes in and they've got to make mess in their hands and a lot of times in this rescue it's not technical in nature, right? I mean, yeah, they might put some shitty code, they might be some bad design, you might have hired some folks that really were in over their heads, that's all true, generally can be true in a lot of cases. But it's really how they communicate, how the process they use, how they think about software, what they value. Those are all not in alignment with really what they want. They'll say, I want these things, but in reality, that's not happening on the ground. And so it does happen, you just have to see what they really change, so then they are. You know, sometimes they're not and it's like, it's literally the bad news, you know? I agree both about that. The friend from the software world would always say, I've never seen a project fail for technical reasons. There it is, you know? And it's just, you see it play out over and over, even when the technical reasons get the blame, right? Yeah. It's like, yeah, no. Like, and I wonder if it's just like the technical problems can typically be solved. The human problems are at least harder. And so it's like easier to play, oh, if we had chosen this different language or framework or whatever. Do you see like when you're jumping in and talking to companies like, do they understand that? Are they blaming the technology and the choices or do they understand it's like. I've seen a mix, I've seen a mix for sure. You know, it's, sometimes it's, it's lots of little poor decisions stacked one after another that kind of adds up. And there's definitely like, well, I guess we're here now. This is sort of, how we build software. This is the quality we're willing to earn or we're not getting the time to do what I want to do. And you know, they make it sort of like a, just they just accept this is reality and they kind of give up and it's kind of sad. I understand it though because if the organization is fighting you, your spirit's gonna be crushed when, you know, you're like, I wanna do all these things. I've been told this is how you build software and I went this and they're like, no. Just like that. I was talking with a friend who joking, like you know when somebody says something that they frame it like a joke but you can tell they're not joking. And he said, you know, people like you, be me, have really put us in this predicament. I was like, okay, say more. Where now we have all these people with a year, two years, three years experience and they think they know all these things and really they don't know anything. It seems that there are more companies now who either choose to or have to like make use of people early in their career. Where 10 years ago, like if you went to just a, you just picked a random team, it didn't necessarily have folks who were a year in or two years in or whatever. Then the idea of like a junior developer is almost new within the last like five, eight years. Like there were always people, obviously, some people had to enter somewhere but even at that point they were, they had done degrees, they had been programming on their own for 10 years, they had their own little projects and all those things. Like is the path we're on sustainable to develop these junior people into mid-level people and level people into senior-level people? That's a good question. And I think the answer is no, we're not quite there yet, but it's changing. I mean, I think probably a lot of you have seen this really hard to get that first job. That is tricky and you can see it through like a lot of the things that I talked about, like with that senior dev portrait of the first thing you want to see your dev is drops and they don't have to worry about it if you die. A lot of these companies really aren't set up to take in juniors and help them get there. And I've seen, you know, I've hired a few sort of trained grads on their second job and I think two of them had really bad experiences. And I don't, I think it's okay to have a bad experience. Before they came to you, or before they came to you. Yeah, that's a great question. Two bad comments. You know, it's okay, I think it's okay to like go someplace and realize, yeah, that's not what I want to do. I don't want to team like that. Now I know a question to ask my next interview. So I think that that's all fine. You still want to stay too long. But the problem is that if you stay too long in a place that's doing it wrong, we'll say, and you know, it's probably a little harsh, but like it's setting up a lot of bad patterns where like we'll have these people come in out there and we're gonna learn a whole bunch of things about how to build software. Because the things you've seen model for you was not good. And that's not, like I can give you examples of how this way of building software is gonna be better. You now see how, if we follow this process of this, how we work together, that's actually gonna be better for you and the team and everybody. And so I think that there are a lot more companies now aware of this and more cautious and they're thinking about how can they learn more people with little experience. And I think that that's true. I do think back to your point here is that certainly when I got started and back in the 90s, there was always people coming in and they were not expected to do too much. I think now there's so much demand and there's companies so desperate to try to build off their team that they're like, let's just get this junior, put him in there, and then they're putting them into a position that they're not really set up to succeed. They're putting too much pressure on them and not up to any kind of guidance and that makes it worse. So I think that definitely the last 10 years we're seeing that now that there's so many new people in the workforce. I mean, you guys have got a lot of good things going for you. You've got a really good example set. But these places don't, there's a lot of companies that just build software internal, so bad. So, this is my last question. It's on clients, I guess. I'm back here for a question. But my last question is like, do you think a person can be underserved by only seeing the good examples? Like is it dangerous in a way for someone to go into a job where things are done well and then not understanding the pressures, the pitfalls, the problems of what happens when it doesn't go well? I think there's some truth to that. There certainly is the idea that if you never see it done in a different way, one, it might not, there might be, because first of all, there's lots of different ways of doing things that can work. So this because we have this one model that works really well, doesn't mean it's not a model that's really close. And so, if you've never seen any other different ways of working, then one, you're not, you probably would have a good way of recognizing how we get from this terrible place and process and an approach to this good place, like it's just too big to divide. And I think there is value in having those experiences and certainly consulting, by the way, gives you just sort of a hyper speed in terms of exposure to things, especially if you're put into rescue legacy tech projects of others that deal with your duty. And I think that that gives you more of that knowledge about sort of what works and what doesn't work. You'll see it like, wow, yeah, we modeled the way of uploading images this way and that really sucked. That was painful in this way. And now I know. It's not just because I saw blog posts that says this is the one true way. It's like, I saw it in a different way and I felt pain. I'm like, dude, I don't like that anymore. I like this. I see why it's so much better than I tell you why. Building software for over 21 years, I've seen it evolve from back in the day. Holy shit, you'd be like, they're gonna build software. That's my name. Where are all my tools? Yeah, I don't have tools. And now it's like, shit. I remember when my first Ruby application, like getting this thing or running on a web server, like, holy shit, fast CGI, yes, that sucked. And now it's like, oh, this thing is good. Do a few things and push and boom, there's your app. It's like, it's nice. I mean, it makes you go faster, but you also don't appreciate all the little things that are kind of building up this ease of your development process. To your point, like, I'll all have students and they'll get frustrated in the last moments before project is due and they'll be like, fucking aroku, it doesn't work. I'm arokuing all my stuff. And I will turn to them and say, you will never speak a ill word about aroku. You don't know what it was like in my day. When the times, when you use the buy a server and mail it around and then send it to a data center, like, no, I reject your disparagement of these tools and technologies. Yeah, they open the whole, can you go like, you know, a cycle, power cycle, buy a computer there in the data center? Or like, load the sites down because like there's a power college in that city or whatever, like all these parts. Anyway, we'll not say I want to highlight out of your talk was the idea of trade-offs. You know, I think Katrina was talking about feedback, meaning in context, trade-offs and like the software choices happen in a context. I think that's one of the hardest things to understand in any time you are, whether you're new to a field or you feel like you're still early in your growth curve, if these things have right answers, we would just pick them, right? But these solutions that you use for one client, for one company, for one scenario are going to often be the wrong choice in the next one, right? And so it's frustrating and also empowering a way that as you say, like after 20 years, 21 years, like you can still be learning new things because the context is constantly shifting. And it's not just a matter of like piling up all the right things I got before, but it's can I apply some of those right things in this new context, figure out what things used to be wrong are now right and what used to be right is not wrong. Hi, my name is Cody. You're talking about people processes that are harder to fix than technical processes and projects don't fail for technical reasons and so on and so forth, right? What would you say the best recourse is for an individual contributor, somebody who doesn't really have power over people processes in a situation where you can kind of tell those are failings or processes, they're using wrong communication channels, whatever, but somebody who doesn't really have a way to effect change. So the first thing is, are you having one-on-ones with your team lead? You are. So one-on-ones are a great place to have these conversations. I recommend that you take more of the sort of data analytical approach to it, like here, if we did this, it would improve these things. It would allow us to do these things. So a very large, rational approach to this is opposed to a very emotional one. And I would just build that up, like build your case. Here's why we should do that and put it forward and see what happens. You could also lobby your fellow teammates and say, hey, let's talk to them and our one-on-ones about this and all this kind of thing together and eventually they're like, wow, what was I talking about? We should do this one process and we should change that. And so it kind of depends. I mean, I will tell you when, in my first job, I actually went to the CEO and opened up a policy. And I thought that meant that you could go into the CEO and talk to him about things. He was very polite and listened to me and nodded and nothing happened from anything that I told him. And I thought I had good reasons, but I was also pretty young. And I would say that just sort of timber your expectations about how fast any organization is gonna make changes. But that's how you start it. And I would also say that, see if you can suggest a little trial period or have this group give this a go and see how that goes and measure it and sort of track the results. Because then at that point, it's hard to argue with data. You have data on your side and they can say, okay, cool. Yeah, but that actually makes it a proof. It's a huge issue. They're like, I really like the suggestion and the process. And don't try to make it too big either. Because make it too big and there's too many things that go wrong. And there's too many, the bigger the scarier it is the more resistance the organizations get pushed back on that. And for good reason because we try to change everything. A lot of stuff can go wrong. So I would say that's what I would recommend is think about a small, incremental, very rational thing you could shift and see if they, see if they bite the lip of one of them. To highlight a piece you said earlier, I think there's always a powerful role for this like peer review issue, right? And when the team lead or when the director says, hey, this is how we're gonna do things. We're gonna do a code review on pull requests. You might think that's a great idea but whatever one's gonna say, no, we're gonna have time to fucking code review on pull requests. Can't believe they told us to do this, right? But when it comes from the peer and you say like, hey, I'm up to do more code review on pull requests. We'll be like, yeah, I'm in for that, that'll be great. It's about time. We looked at each other's stuff, right? And often it's the case that whatever you are feeling and on the verge of saying, other people are feeling and they're afraid of saying. So it is, I think a metric of leadership or like perceiving the leadership that you're getting is how receptive are they to that advocacy? And are they willing to listen? It's maybe a small step and then they go, okay, great, thanks for your thoughts to see it. But second, if you're willing to put yourself out and I think it's important that you title it like taking lead, not like getting lead, receiving lead, being a pointed lead, right? But to say, I'm gonna be willing to step out of it and try and make the place I wanna be a part of or try and make the process I wanna be a part of or make the team I wanna be a part of. I think any good leader is not gonna feel threatened by that. They're gonna try and amplify what you're doing. And it's a sign of bad leadership we're gonna like. Hey, Marty. Hi, DJ. You, we have the Marty B. Fly reference. So I'm wondering what point in your past would you now hire yourself? Yeah, I don't know, that's an excellent question. It depends on what I was expecting. So actually I really love hiring people on potential. If I feel I can bring them to a place where they're gonna thrive, they're gonna be able to succeed. So, I mean, I think I did pretty well when I started programming. I got to program a little bit later in my career. So I was in the Army and then I didn't tell you all this. I was a professional musician for a number of years. Did I do it? What was your Army job? I don't know, a mother's hotel, an anti-tank industry. The anti-tank industry. So I just, I had two till missiles at Tanks. You're such a lighthearted person. And it's like, oh yeah, also he's a mobile Tanks. I was trained to kill, so. I actually was a SOC winner. So I had, actually, I almost, this is another side of Marty. So you're seeing a SOC or, but I almost had special forces. But the problem was I had to re-enlist for five years and I decided that Marty had a lot more potential outside of the military than inside the military. And as much as I enjoyed certain projects, I wanted to, so wait, wait, yes, I can learn about the SOC and clean the SOC cause we all kinds of crazy things I didn't do already. But, so. How did you hire that guy? Army Marty was pretty raw. Pretty, I think, Army Marty, we need to have some softening before. I almost probably went, Army Marty, that guy on the team were like, I mean, I had a good heart, right? I mean, I was a good person inside. I'm like, seriously, you're so insensitive or whatever. Like, that was, that was really wrong. It's, it's very cringy. I think that people are like, we didn't really think very highly of you. So you're making progress. I'm definitely making progress. So I think by the time I got to programming, I had to make different life experiences that I was pretty hungry. I wanted to work in a team. I wanted to learn and grow. And so I quickly got, I took speed back in pretty quickly and I learned pretty fast. But, so I think I probably would have, for a junior role, of course. I think about since your year. 19. That one? 97. 97. So I think by about, this is interesting for me about year seven is when it's sort of switched where like I had this confidence. Like, I think I could probably go with that. Before that I was like, I don't know enough about computer programming and computer science to actually do some of these things. But I think at that point, I recognized I had this experience and perspective because I had like this non-technical look in the business side of what probably was solving that was different from a lot of the programmers. And I was able to then use that to more effectively come to solutions. And I loved discovering solutions. I worked with people to find that. I didn't have any ego about like, I'm gonna be the one that writes on the phone, whatever, like I didn't care. I was like, what can we accomplish? What's your solution? Can we build together? And so I was, you know, that's what I need seven years in. I was at that point. And at that point, that was like, yeah, I mean, I would have been a good, like put him on a project and he'll work well with the team. But before that, thank you, Mark. Yeah, thank you.