Subscribe
Share
Share
Embed
Explore your curiosity - Interesting people with fascinating stories.
Life consists of three things:
-The stories we tell others
-The stories others tell us
-The stories we tell ourselves.
Mark, welcome aboard to the show. Thank you so much for joining us today.
Speaker 2:Thank you for having me. I look forward to talk talking about this.
Speaker 1:I I wanna jump into a horror story. What is the worst moment you had managing an engineering team? Things were going terribly wrong. Many of us engineers, find that our best stories are actually overcoming those worst white nights of coding into 3AM. What's your 3AM story?
Speaker 2:Oh, yeah. There's all sorts of fun ones. So it's just a matter of pick and watch. I guess it was probably about four, five years ago. We had one of those production crunches.
Speaker 2:We had gotten something out that had gone out probably a little bit before it should have, not quite as planned as well as it could have. You know, business needs, kind of driving towards goal. And, of course, things got missed. Things didn't get tested quite as tightly as they should have, and we ended up kind of paying for it. And in those situations where it's like, we can't roll back.
Speaker 2:We can't, this this feature has to go out to meet business objectives that the business has already committed to. So it is kind of pulling the team together and scrambling and figuring out, okay. Well, whose whose piece is this that's, you know, not quite quite right? How can we get all hands on deck to help out? What what challenges do we have to making that happen as a team?
Speaker 2:Do we need to pull somebody else in that may not even be on the team? Maybe there's some expertise that we're missing around this this area here that we're we're, we're dealing with. So so it is it is that they happen more than I would like to admit. You know, we do our best to plan. We'd be as proactive as possible.
Speaker 2:We try to, plan out those contingencies and get those requirements just quite right, but it's the best best we best we can. They seem to bite us, and we have to deal with the situation in the moment and scramble and
Speaker 1:make it happen. So there's there's two versions of this and maybe more. One is where you know what the gap is and we just need to fix it.
Speaker 2:Yep.
Speaker 1:The other version of it is we have no idea what is causing the problem. Don't know who it is. We don't know what the problem is. We might not even have certain business processes mapped out to the level that we understand the flow because it's some other API that's basically making all kinds of decisions.
Speaker 2:Yeah.
Speaker 1:You're now working with the team.
Speaker 2:Yep.
Speaker 1:And there's the person who is basically responsible for the piece of code. Mhmm. And you're basically saying, hey. Let's bring on more people to help. What's the emotional state of that person potentially at that moment?
Speaker 2:Depends. Where are they at with things? Usually, is. So as a as a team lead, we we do have to be careful about kind of understanding we are moving fast. We are potentially breaking things, but are we stepping back for a moment to have some those critical conversations to understand where is your head at and to relay intention.
Speaker 2:Hey, we're bringing this person to help us out as a team, not because I don't trust you or that I don't feel like you can get this over the finish line, but I know they have some expertise that we we need here. We didn't make this happen for for our client, for, you know, whomever. So so it is being very delicate about those situations and recognizing them as they're happening. A lot of that is is that communication. It is that body language of you can tell when people just gotta, you know, start shying away or, they they start feeling a little bit threatened, kind of kind of pick that up in the language as well of you you start to sense that and just like, hold on.
Speaker 2:Let's take a time out here. Let's you know, you and I, let's break off from the group here. Let's let's go have a quick discussion around this. So so it is is how do we, again, drive back to team? How do we as a team find success?
Speaker 2:It it goes, as you just kinda mentioned, you know, this is their code. This might be their problem. They they might have it might have originated with them, but it's not as a team, we're not pointing fingers at them saying, hey. You screwed up. You put us in this situation.
Speaker 2:We're working long hours because of you. It is no. We know that tomorrow it could be me that that has this problem, and my team is gonna back me up. So how can we jump in together and help that person out knowing that at some point that same thing's gonna happen to you? So so I feel like if we can come at it the right way, then it doesn't feel as threatening.
Speaker 2:It does feel like we're all in this together. It's a collective success, and it's not necessarily, oh, you're fixing my screw up. And I I I have been in those type situations before as well, being a team member, and lots of finger pointing, lots of we're going through this because of you. And, you know, people left left the company. They've they've kind of we weren't pulling they weren't pulling back and having those conversations.
Speaker 2:They weren't understanding what exact emotions, feelings. These are high pressure, high stress situations, and it's very easy to kind of tip people in the wrong direction if we're not really being careful about how we handle some of these very delicate situations, and it is difficult. I mean, some of most challenging ones that I've dealt with in the past are those high stress situations because everybody's keyed up. Everybody's on edge. And there are times you just take a breath, take a step back.
Speaker 2:Let's go let's go walk around the building for a second. Just get away from the situation, clear our head so we can come back and come at this from a different angle. It's really imperative to take those moments to make sure we don't just end up just spinning our wheels and not really accomplishing anything.
Speaker 1:Yeah. This is this is I mean, you're giving these these tips as if it's nothing, but but this is incredibly, incredibly important. The the dark side of not doing this is that, you know, engineers panic. They go into this mindset of I'm going to be fired. Then their ability to perform under stress is completely out the window.
Speaker 1:It becomes emotional. It feels like this other person, if they're forced onto to you, then they're basically there to to find how you screwed up and you're gonna be fired after this. And then the other aspect of it is a thing that I think, you know, PhDs and software engineers appreciate is that sometimes to solve a really tough problem because some of the times these problems are incredibly difficult.
Speaker 2:And, you know, you
Speaker 1:you wouldn't have had the problem if it was easy. You might have spotted it way ahead. So this could be like, you know, mutex issues and and parallel issues and all kinds of weird bugs that happen, you know, once in a million, but in production somehow it's happening every single time. Right. You need to take that step back to be able to let your back end processing work.
Speaker 1:So there's a lot of really important techniques here that that come to play all at once, and it's really easy to mess it up. What about the team? When you when you are in the hiring mode, when you're building out a team, how do you balance this idea of and I'm gonna make a few assumptions, keep me honest here if you disagree. There is a huge difference between an a player and a b player in software. It's not five to 10% better.
Speaker 1:It can be five x better.
Speaker 2:Yes.
Speaker 1:And and a c a c player will completely destroy your code base. Like, they will destroy your business. So so the differences between the good, the bad, and the ugly, so to speak, in engineering are massive. It's not marginal. True.
Speaker 1:And then on the other hand, what I've observed is that sometimes these a players come with a bag of of issues where they might not be I'm being very mild here. They might not be the best team players, and that's okay because they're temp they can do the job of three developers. How do you balance that?
Speaker 2:Very carefully. You're right. You're right. So a lot of them do come with baggage. And and sometimes you have to actually ask yourself, is that baggage worth it?
Speaker 2:Yes. Can I go get a better a player that's not gonna be toxic to the team? And and I think that's that's where I drive in that. It's like, if that a player is bringing down the rest of the team, then they're they're probably not worth what they're bringing to the table even if they are 10 x. It is a really careful balancing act of, you know, having those right b players.
Speaker 2:And the c players, I mean, sometimes it's like I got stuck with the c player. You know? I I I kinda come from a consulting background, and I I don't necessarily always get to choose who lands on my team. So it's like, how are we gonna build support around that person that might not be great at that thing to make sure they don't kind of bring down the team themselves. So it is a very that whole, like, team construction of, like, this person's really good at this thing, so let's let's find somebody that's good over here till we can help kind of balance things out.
Speaker 2:I mean, like I say, sometimes we don't have that luxury between, you know, it's like this person's available. They're coming in. It's like, okay. Well, we're gonna have to kind of figure out how that mix works and to make sure that this dynamic, you know, that we built is still gonna be healthy and still gonna be productive. But whenever we can, it is nice to be like, oh, man, I'd love to have this type person on my team.
Speaker 2:Can we go find it either at a higher or somebody that's rolling off a different team? How can we construct that kind of I mean, I've been in those teams that are just, like, unbelievable. I'm I'm not sure how I got so lucky to construct this group because they are awesome. And, you know, it's like, how can I shower them with praise? How can I encourage them?
Speaker 2:How can I build them up? How can I push them out of their comfort zone a little bit to to to make this, like, very high functioning team, you know, just a little bit stronger, a little bit better? Those are great.
Speaker 1:Great teams. Let's take some assumptions. Let's say that we do have a Tabula Rasa. We have a clean slate to build the team. What is the thinking process in order to build that team?
Speaker 1:Is it just is it just, well, we have to hire a players and everything will be fine? Or is there a more complicated look to it? And I'm going to throw you a curveball here. Does the architecture even matter? Because I make the argument that the architecture and what you're building actually matters deeply to who you wanna hire.
Speaker 2:I think that's fair. I think, I I don't know that I'd go quite that far, but it is very important in the overall mix of things. To me, so I so I I have served as, like, the employee growth role in in some of those things in the past. So for me, it's very important to understand where people are at, where they want to grow, what's the next step for them. So I I really love to find you know, I don't I don't want necessarily all the a players because, you know, that that brings its own kind of headaches and challenges of, you know, the alpha dog in the room kind of thing.
Speaker 2:Why why did you do this, you know, this code pattern or anything else? And why didn't you do it the way that I wanna do it? It's like, I need a little less emotionality at times. And and through that, you know, how can we bring on some of those b players that we think could be our next a players? How do we help build them up?
Speaker 2:How do we put them in a position to succeed, to mentor underneath a a really strong a developer or architect, and help bring them up? Because if I'm just pairing a players together over and over and over again, well, it's on my pipeline. My pipeline's probably pretty sad. You know, how am I continually building this organization, this team to excel and to be, you know, the the next great thing? At the end of day, those a players, they they cost money.
Speaker 2:They're not cheap. If I can swing in a b player and I can build them up, yeah, I might lose them at some
Speaker 1:a b player, but would you agree that they are an a player that just hasn't come into their a player game yet? Usually. Because as as opposed to a b player that just is average in their capabilities, they have huge potential. You just need to guide them into manifesting that potential. So I would almost push back on you calling these these kind of younger developers who, you know, haven't yet reached that a status.
Speaker 1:They're not b players. They're just they're just not there yet.
Speaker 2:Right. Right. So yeah. And then that's important distinction between how we're seeing those b players. You're right.
Speaker 2:There are b players that will never be a players. They're just perfectly content to be b players. Growth has kind of stopped. That's concerning to me, and I'm usually having conversations with them about that, about you're here. I need you here.
Speaker 2:What does that look like? Is there something I can do to help motivate, help help drive it? But you're right. There there are there are places that it's like, this is a team contributor. They're good at what they do.
Speaker 2:They have a ceiling, and I have to I have to accept them.
Speaker 1:So tell us about that structure. Right? You've got the the high power, you know, got the accolades, expensive. Then you've got a set of kind of more junior, but you can see the role potential there. True.
Speaker 1:Right? That mix. How do you set it up to make sure that that relationship is incredibly successful and these kind of younger developers turn into everything that they can be?
Speaker 2:Yeah. I think it's it's just being very deliberate about how how we construct that. How how do we, do that pairing, like I say, from a kind of a mentorship type aspect of finding that groove of one, it's, you know, having the one on ones with kind of team members and understanding, especially with the younger ones, you know, where do you see your career going? And with with the caveat of, I know you're young. And part of that is just kind of exploring things to try to figure out what speaks to you and what what it is going to kind of click with you for the long term.
Speaker 2:So so there's a little bit of it that's just like, I wanna throw some of these very promising younger developers on different types of projects to see what they do and see how they handle certain situations, how they grow under certain people, and who who they click with as well. There are certain I mean, try as I might. There are certain people I would pair together, and I'm like, this is gonna be awesome. This person's gonna learn so much from a senior developer, and they just it just doesn't work. For whatever reason, personalities or just approach, it's it's hard to kind of put into words what that is.
Speaker 2:But it's it's not like, okay. We failed that time. You know? It's just like, okay. Well, that didn't work.
Speaker 2:So let's try it differently. Let's let's learn from that, and let's kind of come out fresh and figure out who is the person that this person's really going to jive with, and that's really going to help them kind of exponentially make those gains to make them quickly kind of close that gap. Because as you were saying before, the those those the developers that we're kind of thinking of, I'd almost always rather have that junior that I am that's hungry, that is learning, that is doing the new things, rather than even the senior developer who's been there for ten, fifteen years. That's kind of They're comfortable. They don't necessarily want to push the balance of their skills.
Speaker 2:It is what it is. So I'm usually getting more out of that junior developer than I am even more seasoned senior developer that's
Speaker 1:kind of
Speaker 2:done the things and, you know, been been through a lot. But that growth potential isn't there.
Speaker 1:Yeah. The the you're touching on two incredibly important points, I think, and it's this this hunger that engineers may have or or not have. So it's you know, you could have the raw potential to write that raw intellect, and that's what I call speed of thought. Right? You can think really fast and put these puzzles in your head together really quickly and kind of see the right picture as opposed to the wrong picture, and that's a whole different discussion.
Speaker 1:Yep. But then you can also be a senior developer and you have all the experience, but you just don't have that passion anymore to to to showcase that you can do the impossible and you can do the amazing things. Is this is this just like you're tired and old or is this a cultural problem with their with how the organization is communicating, running, incentivizing? What have you seen happen in reality?
Speaker 2:That's a great question, truthfully. And one I've probably struggled with over the years. Like, what makes this person kind of push the boundaries versus and it can change over time as well. There are certain developers I've met during my career, and I'm like, this is gonna be my next star. And then for whatever reason, something changes, something falls off and that never happens.
Speaker 2:They just kind of settle in. Kind of the biggest thing from my side, kind of watching developers is if we're not challenging, if we're not having conversations trying to figure out where they want to be, where they want to go, that you just kind of fall into that groove. And it is, you know, nobody's checking up on me, nobody cares about me, Nobody's giving me a more challenging task. It just kind of is what it is. So how can we get ahead of that?
Speaker 2:How can we be proactive? How can we have those conversations? And even when we do, like I said before, it isn't necessarily just the the lightning bolt that changes everything. At the end of the day, there are certain people that just aren't gonna be able to make that jump.
Speaker 1:Yeah. So so I'm I'm for the purpose of this conversation, I'm assuming that they can make the jump because otherwise it's a, to quote Joy from Friends, a moot point. Let's assume they have the ability. What's your point to Sue, and I 100% agree with you, that this is a management problem. And there are certain there's this paradigm.
Speaker 1:Right? You have these great engineers that get promoted to managers. They might suck as managers. But then you have managers that are great human skills, but they don't know shit about code or as good as they should for Yeah. From an architectural standpoint to guide the team on important decisions.
Speaker 1:And this is an impossible situation. Do you have to find the person who's an amazing manager and also is great at code, or can you compromise on this?
Speaker 2:I think it was compromised. I think it does find that that balancing act of is is there back to the team construction. Is there that that person that is strong team lead can kind of foster team, has enough technical chops where they can support, but they may not be your strongest technical person on the team. Maybe you have that super senior developer that that they're they're not management, but they can architect. They can code better than anyone else on the team.
Speaker 2:So how how are again, balancing act. How are we, forming that team that has all of the the the different pieces that it needs so that we can kinda come together and and and be successful. I again, it it doesn't always happen. We we, you know, try as we might. We don't don't always get to choose kinda what that composition looks like, but I think I think it is I would rather have that that balancing act of you have these strengths, and I understand you do not have any of these strengths at all, but you compensate for me in these ways over here.
Speaker 2:And to your point of managers or people that get promoted up to management that, you know, shouldn't have or don't want to be, again, I think we need to be having those conversations very early with them. Like, I see management potential in you. Is this something that, you know, speaks to you? I've seen I have been with so many developers who are just so good, they just got the you know, just promoted up into management. They had no desire to be in management.
Speaker 2:And then, you know, people, like, looked at them like, well, why aren't you good at this? You know? That was your next step in your career. Well, that's not what they want. This was never in their kind of life plan.
Speaker 2:They just want to be the great, you know, knockout programmer, knockout architect. Management was not for them. But if we don't have those conversations and we're just promoting them up, goes, hey. This is your next step, you know, we're only hurting ourselves through that. So it is part of that conversation.
Speaker 1:Do you
Speaker 2:just principle. Yeah. How do we see people and how how are we listening to them? Again, having the conversations about what do you want? What's gonna make you happy?
Speaker 2:What's gonna make you as productive member of this team? Okay.
Speaker 1:This is such an important point. I think it's hugely overlooked. Like, do you want to do this? I will throw a wrench in this. I have found that in certain cases, the people who don't want to be managers have the potential to be the best managers, and the people who want to be managers might possibly be the worst ones ever.
Speaker 1:And the reason why this happens is because of ego and, you know, this need to manage to tell people what to do Sure. That doesn't end well. Yeah. And then the people who are, like, these great team players and they kind of see the management role as me telling people what to do, that is not attractive to them. But actually, they have the chops to create this team dynamic that is incredibly successful.
Speaker 1:But then I I'm playing the devil's advocate here, but I also totally agree with your your previous comments that that absolutely. It's not it's not a contradiction, I think, in this case.
Speaker 2:No. I I I agree with you. And for in those type situations, I'm usually giving that person is like, no. I don't wanna be in management. But it's like, you're right.
Speaker 2:They're like, it just makes too much sense. You're perfect at this. I'm not necessarily contradicting them. I'm not telling them no. I need you to be at management.
Speaker 2:I'm usually just kind of feeding them, like, management type responsibilities and just seeing what they do. See if they start taking to them and then, you know, having the conversation. I'm like, what do you think a manager is? Because basically, we're already performing as a manager, and you're knocking the ball out the park. You're unreal at this.
Speaker 2:And sometimes it's just a mindset. They have this vision of what a manager is, and it's just the blinders are on. It's like, can't see anything other than what I've perceived a manager to be. And at the end of the day, it's like, take the blinders off because there's so much more to this space than what you ever thought about. And I I I need to help get them to see that.
Speaker 2:If I can, then then I've succeeded, and helps kind of carry them to a place that they they never thought they could be. So I I I that is gold. I couldn't agree more.
Speaker 1:I I almost I'm not a big believer in in, like, you know, we need to change language and words matter that much. I think actions matter, but but I find myself disagreeing with that many times. And I'm gonna make a comment to do exactly on that, vein. I feel like we shouldn't call the managers or bosses. Really, what they are, their mentors, their guides, their sherpas.
Speaker 1:Yes. And I think that that I couldn't agree more that misperception both for the bad managers that are bomb waiting to happen and for the amazing ones that just don't wanna be the you know, that. It's just a misperception. I I think that's incredibly, incredibly insightful. Yeah.
Speaker 1:I I appreciate that,
Speaker 2:Mark. Completely agree. And two, that the point of the the mentor, I I I could couldn't agree more that that's almost the most most important piece of being a, you know, quote, unquote, manager. How are you building up that to a team? How are you building up that that next generation that's coming up?
Speaker 2:But there are people that I've I've run into that kind of push back on that. It's like, I don't wanna be the mentor. That's I don't want that responsibility. And again, it's just like, you have so much knowledge to give and to impart to other people. You really work well with this person over here, and you've been kind of doing some of that with them.
Speaker 2:So why don't you just play around with that space a little bit more? There's there's no obligation. There's no anything. If you come back to
Speaker 1:me and be like, I don't
Speaker 2:like this. You know, stop stop doing this. Fine. We're good.
Speaker 1:But this is really important. So this idea of of, like, an experiment. Right? There's no obligation. Let's just do an experiment and see how it goes.
Speaker 1:And if you don't like it, you backtrack. No problem. Yeah. I think the finality of, like, oh, you're a manager now and I might fuck it up. Like, that's I think that's incredibly scary.
Speaker 2:Oh, yeah. Yeah. I agree. But it but it is, again, helping people see the value that they bring to the table every day. It's like, you are my strongest DevOps engineer.
Speaker 2:All of this kind of resides within your head. Right. Help out that next generation. Help out that next person because it it makes your job easier. You know?
Speaker 2:If you can build up these other people, then, you know, you can kinda focus on some of the higher level stuff that you want to do, and you're not, you know, doing all the admin type stuff. But it it's just it's getting that across because there are you know, some people are just like, I know that's management. I don't wanna I don't wanna do that. It's like, yeah. I get it.
Speaker 2:I get it. And maybe there's a piece of that if I step back. It's like, as as managers, are we putting something off? Or may maybe it's not me, but maybe it's a manager they've had in the past that's kind of given them a shade of, I don't want to ever be that. Yeah.
Speaker 2:And so maybe it is just redefining what a manager is, and helping them see it is just giving back. It's helping someone else. Right. It is, spreading that knowledge you gained throughout your career because I know somebody's done that for you. I know a mentor has been in your corner because there's almost no way you could have gotten to this place right now Yeah.
Speaker 2:Without somebody kind of looking after you and helping you out along the way. So There's
Speaker 1:a few problems. One is the fact that negativity is more salient. So if we kind of go over to social psychology, then negative experiences are etched in our brains, while the positive ones kind of slide. So absolutely, we we are constantly thinking about that worst manager, that horror story that we heard from the friend, like, those are the things that are etched in our memory. The other aspect of it is that, you know, these the the good things happen small and slow.
Speaker 1:The bad things are all at once, and they're awful. I think that's a big, you know, that's a big part of it. Let me ask you this. We started with the with the horror stories. Mhmm.
Speaker 1:After the horror story, sometimes these horror stories repeat themselves two, three, four times.
Speaker 2:They do.
Speaker 1:And sometimes it's with the same person.
Speaker 2:Mhmm.
Speaker 1:And the rest of the team is now, look, this isn't about helping each other. This is one person and there's a pattern. There is a decision to be made, quite a dramatic one at that point. Is this the end or is there a plan to put together here? My first question is, how do you make that decision?
Speaker 1:Is there a plan to be put together or is this the end?
Speaker 2:So my hope is if we're doing it right, we're seeing kind of after that first event of like, let's do a postmortem. Let's kind of understand what happened here. What would we have done better? What can we learn from this event right here? And part of that is me understanding, again, as part of the team, I'm not pointing any fingers, I am understanding where are my weaknesses?
Speaker 2:Where did we drop the ball? What the kind of those foundational pain points and elements? And from that, how do I need help support going forward? Maybe I had somebody in charge of something that they really weren't you know, an expert at or or even very good at. How how can I shift things around or how can I, you know, add that later support to them so the next time there was somebody kind of giving those checks and balances on that accountability?
Speaker 2:So that hopefully we don't hit that the second time. But I I do understand what you're saying that, you know, there there are times when it is just almost unavoidable. So it is that second time we see kind of the same pattern from before and then it is kind of pulling them aside and saying, hey, I noticed that kind of we we we fell in the same trap we did last time. Talk me through this. You know, where was your head at?
Speaker 2:What was going on? And then again, if it's if it's the third time that it is, it's like, We we we have a problem You know, we we keep repeating the same mistakes over and over again. You're it's it's we're not learning from it. We're not getting better. So and and those times, you know, it it becomes a tough tough decision, you know, is is Are we taking this person off the team?
Speaker 2:Are we letting this person go? Usually it is, again, we're having those conversations along the way. We're setting that expectation of, hey, I need you to step up and do this better next time. Again, it's a one on one conversation. I'm not having this, you know, as part of the team.
Speaker 2:Of course. If we do see that pattern that's forming so that, you know, there shouldn't be much surprise to it. It's if keep stepping on these landmines, something's gotta change.
Speaker 1:So so, Mark, you you I love how you glance over these incredibly insightful and and important comments, and you just glance over them as if everybody understands and knows this. So I'm gonna pull you and our audience back to something you said. Sure. You talked about checks and balances. Mhmm.
Speaker 1:What are those checks and balances? What do they look like? What are the engineering and we'll keep this a little high level not to go too much into, you know, tech jargon. What do those checks and balances look like, and how do you do them right as opposed to wrong? What value do they drive?
Speaker 2:Yes. Usually usually when I'm we're in a project, we're looking at you know, maybe we're looking at the next week's sprint. And we're we're looking at the stories, we're saying, you know, this one has some risk. I'm gonna give it to my top developer. This this one's interesting.
Speaker 2:I think this could be a growth area for kind of one of my junior developers or or, you know, whomever are on the team. I'm gonna assign them this. But I I know that one has a little bit of risk to it as well. So how again, how am I gonna pair, hey, senior developer or, you know, super smart developer over here, I'm gonna pair them with you. I I you're not working on this thing, but I want you to check-in, you know, every couple of days.
Speaker 2:How are things going? What challenges are you having? Why did you approach things like this? Why don't you do it like this instead? So it is kind of having that kind of mentor within the project, and it doesn't always have to be kind of the same person working kind of within each kind of set of work.
Speaker 2:But it is somebody providing that accountability, providing those checks and balances so we don't get to the end the sprint and it's like, oh, you didn't finish that? What what happened here? You know, it's it's not the reactive. You know, we we can be as proactive as we can along the way to make sure we land in a good spot. And two, that senior developer can raise this red flag and say, hey.
Speaker 2:We got a problem here. This this is not going well. We're three to four days into it. We're at risk of not delivering this thing. And okay.
Speaker 2:Let's let's recalibrate. Let's let's reset. Maybe I need to reassign that to somebody else. Again, you know, this is not a reflection on you that we're taking this work away from you, but we need to get this across the finish line. This is probably a little bit greater challenge that I probably maybe I shouldn't have given to you at this point, but, again, we're gonna learn from it.
Speaker 2:We're gonna get better. And, you know, don't don't take this personally. This is a learning experience. We're gonna we're gonna hit this hard next time. We're gonna go come fresh and we're gonna have have a successful flip kind of kind of next next adventure.
Speaker 2:So so so it is just making sure we are coming at things correctly. We're making sure we're setting ourselves up well. Because, again, if that one critical piece doesn't get delivered, it almost doesn't matter what else the rest of the team did.
Speaker 1:Right. That's that's
Speaker 2:what everything you're looking at. And so why didn't you deliver that? That was the thing that was really important to us.
Speaker 1:To our managers in the audience, you know, sometimes software is a pipeline, and if there's a a leak in the pipe, nothing will work. So, you know, these things can be critical. We're dependent on each other. But what you're describing at high level is extreme programming, peer programming, and then mentorship, which really is using an element of design review and code reviews.
Speaker 2:Yes.
Speaker 1:I was horrified to get this feedback that code reviews don't work. My pushback to I didn't push back, but my thing that was going through my head is like, you're not doing your code reviews right. So so let me ask you this since I know you're you agree with me that code reviews are incredibly important, design reviews. How do you do them well? And and what have you seen where they're just awful not working, not delivering the value?
Speaker 1:Because there's definitely a way to do them very well. And and there's a way where it just doesn't drive value. And and that's why I'm assuming that that executive is like, oh, code reviews are a waste of time.
Speaker 2:Yeah. I I I think it is a a cultural component. How much importance are we putting behind those code reviews? At the end of the day, if you're checking a box, code review comes in and you're like, I am super busy. I've got 10 more important things to do today.
Speaker 2:Sure. Looks fine. Object. That's there. That that is where we get into the code reviews don't matter because we as an organization, we have as a team haven't put value behind it.
Speaker 2:It's just another thing I've gotta get done today that's in my way towards me being productive and the thing that I'm going to be judged on. So, again, how do we reset that? How do we say, well, this is important to the team. This is developed important to our code base that we are releasing it, and we are standing behind, that we are proud of what we are releasing. And the standards that we set from a coding perspective, we are all in charge of that.
Speaker 2:And that falls on all of us. So if we come at it from that perspective, then it has more value. We are kind of standing up to our own standard that we So part of that sounds a little trite because, yeah, that's nice, but we're all of up against the gun. We're driving towards this release that we have to get done, so I don't have the extra time in my day. I get it.
Speaker 1:I get That that is a very dark path if and because if you are taking that stance and you're doing offline code reviews as a check mark, and it's not just some small thing that you can review offline, but you actually do have to have the proper code review process, which is Socratic. You what's gonna happen is five years later, you have a whole bunch of spaghetti code or what the youngsters are calling it nowadays, anti patterns. This is this is a really bad outcome. And what happens is that at some stage you let's say you get lucky from a business perspective
Speaker 2:Right.
Speaker 1:Your code's not gonna scale, and then it's gonna start breaking. You're gonna have more quality issues. You're not gonna be able to handle load and scale, and you've never done, like, a multi agent, you know, hit the the the the API test to see what is your lead way, runway on scale and load, so you have no idea when it's gonna blow up in your face. So, you know, you again, you're you're getting you're just, you know, sliding through these topics which are so insightful and so important. You said standards of of coding.
Speaker 1:You said proud. I wanna lean into that for a second because I think those are such important comments that you made. What is the sense of pride in your work, and how does that link up, which I think incredibly links up to this idea of having pride in your work? Why do those why are those two things inexplicably, connected?
Speaker 2:Yeah. I mean, when I think back through, you know, I I've I've been in technology for, you know, twenty, twenty five years now. And there are places where the first job I got out of grad school, I pointed back like, they're still using that system. It pains me to know they're still using that system twenty years later. Like, why haven't you rewritten that?
Speaker 2:But it worked so well that it just fit the need. And they didn't feel the need to upgrade it and kind of moved on. I think as creators, you know, we take very much pride in what we put out in the world Yeah. And knowing that it makes a real difference. I mean, it it shattered my my thinking when the first system I ever built was like this affiliate management system.
Speaker 2:And the person who was in charge of the affiliate department said, you just saved us from having to hire two workers. And I'm like, never occurred to me that, you know, I could have this much impact with that one little thing that I developed. So it is I want all of us to have that much pride in what we do. And part of that is having those standards that say, you know, what we're putting out is quality. We're not cutting corners.
Speaker 2:We're not, just socking away tech debt that, you know, well, that's gonna be somebody else's problem. Right? You know, I'm gonna be long gone by the time somebody has to deal with that. I if if I'm ever hearing any of that from team, I'm just like, no. Let's step back.
Speaker 2:Let's reset because something went horribly, Orion Communications. And and we have gotten to a akin by that toxic state of Yeah. This is going to bite us. We are going to get into the scaling problems. We are going to get into situations where we are not building software for the business.
Speaker 2:We're building software for today. You know, what's gonna what's gonna get this check-in done?
Speaker 1:Oh, we're gonna rebuild that anyway later. Yeah. Don't worry about it kind of thing. Okay. So you're in this incredibly difficult situation.
Speaker 1:How do you get out of it?
Speaker 2:Well, things first. Usually, when I've been in this situation, it is business kind of pressing the the the technology team. Hey. I need more features out the door. These bugs need to be fixed.
Speaker 2:You know? It is that pressure cooker type situation where people kind of get inked to these bad habits. Yeah. And it does just become this I don't have time to do all these things that we should be doing. So it's it's up to us as technology leaders, managers to go to the business and have those conversations of, here's here's what's happening.
Speaker 2:Here's what I see happening on the ground, and here's the impact to our business. I understand all of these things that you have put on our plate are super important. They are all number one priorities, but we have to back off because here's what's going to happen if we don't. And if we aren't having those conversations with the, the C level executives, the kind of upper level managers, they just assume everything's fine. Nobody's telling me otherwise.
Speaker 2:So yeah, I'm going to just keep pushing partner requests down on you guys and get that software out the door as quickly as possible. And again, this is not their world. So to them, it's just I'm just doing what I need to do my job. But if I'm not having that conversation, if I'm not going to them and saying, hey, this is detrimental to our business, then what how are they to know otherwise?
Speaker 1:That's incredibly important and insightful because, you know, great engineers can put out shit code in the wrong culture and wrong environment. Yes. And, yes, there's a business executive applying pressure. And I'll I, you know, I I am that business executive in my day job. Mhmm.
Speaker 1:And striking that balance of, you know, come on. Is this is this really a month, or can this be done in a week? Right. Sometimes that's the right thing to do. But in other times, and I think this is the one that is sometimes underused, is hold on.
Speaker 1:Do we need to clean up some technical debt now? Do you need an extra week, an extra two weeks to to do this right now that we've tested it, now that we've MVP ed it, now that we know that the requirements and the customers have are solid with what we've done? Do we need to do some cleanup? And that is something that very often we don't get to that stage. And that is incredibly risky.
Speaker 2:You're right. And I and I wish there was a magic wand where I could say that, you know, we, you know, everything kinda comes together and we we can have those conversations and those things crop up. But right. It it more often than not, those things do fall through the cracks. We can bring that again, trying to big spotlight on those things saying, hey.
Speaker 2:For the quality of what we're putting out for our customers and how they're going to kind of interact with our products and our brand, this is really important. Some of those battles I win, some of those battles I don't. But, you know, we keep showing up, we keep shining that awareness on it and hopefully we do break through and, you know, we make some key wins along the way. And other times we're just like, well, our yeah, I think of that tech debt catalog that we kind of have kind of ever growing or, you know, it's just, you know, ever expanding or kind of falling. How are we bringing that to kind of those key stakeholders and saying tech debt is getting to a worrisome state of here's what I'm seeing of you know, could potentially buy us in the next six to twelve months because of this.
Speaker 2:How are we as a team gonna come together, an executive or leadership team could come together to address this. So it's not we're sitting here twelve months from now having the exact same conversation and now it's starting to impact our business.
Speaker 1:Yeah. That that's that's really important. I mean, my perspective, it's about I think it's a it's an English to English translation problem. Right? The engineers are talking about the dot net version and on, you know, database processes happening in memory versus SQL.
Speaker 1:To then to the executive team, that's garbage. Like, that's Chinese even though it's English. I I think the the challenge there is to translate that into English and to say, look, and this is a little bit difficult to do. It requires some work. But to translate it into, oh, we won't be able to go above a thousand customers.
Speaker 1:Right? Yeah. Yeah. So translating that to, let's call it, requirements. Like, this is our scale stress load capability right now.
Speaker 1:And if we wanna exceed that, then we have to do some work. Right?
Speaker 2:Yeah. Definitely. Or it could come down to, you know, our cloud costs are gonna balloon and your, you know, your expenses are gonna be good one. X when they were y. Yeah.
Speaker 1:You know, how And it's not always about getting some reserved servers. Sometimes you have to change architecture.
Speaker 2:No. I mean, it is it is a sales job at the end of the day. It's like, how can I sell you on the importance of the things speaking your language, as you just said, the things that are going to matter and impact our bottom line? So so it is that kind of, you know, can I speak both of these languages and can I can I do it well to make sure that we can get what we need? And and again, back to having pride in our work.
Speaker 2:We have the time to do this correctly Yeah. And release the software that all of us are gonna be proud of.
Speaker 1:I I would argue, we talked about kind of managers and engineers being promoted into managers. I would argue that that skill that nobody has initially of learning to speak the managerial language, even though you're directly interfacing with engineers. So being able to have those two different versions of English, that's a skill that, you know, as a team lead, you're you can struggle with it. But when you become a director, you have to nail that. You have to know how to do it.
Speaker 1:Otherwise, you're just not gonna make that role.
Speaker 2:Yeah. The executive communication is is so important. I I had some great mentors of my own of, like, you know, you just you just sent me a novel. I I needed the four bullet points that
Speaker 1:Wallet text. Oh my lord.
Speaker 2:Wallet text is so fun. But it's like, I need you to know all the details. Like, no. I don't need to know the details.
Speaker 1:I've done a
Speaker 2:impacts me. Tell me how I can help you. That's what I need to know.
Speaker 1:So I had a mentorship process with one of my engineers, and I was like, rewrite that to three sentences and explain it to me in my language. And he tried. Oh, lord. Did he try and fail? But ultimately, after trying enough times, he got it.
Speaker 1:And it's a shift of a mindset. It's incredibly important. Mark, this has been so much fun. We're so over time. My wife is gonna is this is supposed to be thirty minutes, not forty five.
Speaker 1:So okay. We're gonna wrap up. Alright. There's one question that is scripted. It's the only question in the show that's scripted.
Speaker 1:It's incredibly difficult question because it's personal. Alright. If you had to go back to 20 year old Mark, what would you advise him?
Speaker 2:Oh, that's an interesting one. So So I to say it's been an interesting journey and career. I started out as a dot net developer, did that for kind of fifteen or so years, ran my own business for a while, was consulting for ten years and through the consulting journey kind of went into the management ranks of director and vice president and now kind of on the CTO side. So it has been very rewarding. For me, technology has always been about how do we help the business.
Speaker 2:In my early days, probably geeked out on all the kind of the new and the greatest and everything else. I'm sure
Speaker 1:you still do.
Speaker 2:Not as much these days, but yes, There are times when it's like, oh, man. That is awesome. You know? Just got diving into it. Just being hands on.
Speaker 2:But but, yeah, it it is that transformation of things and, like, how I see business, how I see technology helping the business. That's been really kind of key for me. And I was a psychology major, you know, in undergrad in college. So this I had almost never even used a computer, you know, back in those days. So this has allowed me to kinda come full circle, the management side of things, the people leadership, to really be able to invest in people and help them out, kinda tapped into that other side of who I was and kind of brought that back into focus.
Speaker 2:I don't know that I would necessarily say do anything differently. It's been a great road and I think I've landed exactly where I should be. It's, you know, had my fair share of missteps and I wish I hadn't have done that along
Speaker 1:the way but you know, we
Speaker 2:grow through those things and they make us and truthfully, I wouldn't have gotten here without some of those missteps. No, I would tell them to have fun and and to explore the opportunities that come to you and to embrace them.
Speaker 1:Mark, thank you so much for joining the show today. I deeply appreciate you.
Speaker 2:Thank you, Art. It's been great.