building impactful teams w/director of engineering, chris holland

full transcript

auto-generated from the audio, so expect a few typos. the audio is the source of truth.

Hello, hello. Thanks for listening to Guidance Counselor 2.0. Listen, I want to give you a quick rundown of what this podcast is and what you're about to get into as you listen to these episodes. We had Guidance Counselors in middle school. We had Guidance Counselors in high school, but we didn't really have Guidance Counselors in college and now as professionals, we don't really have anybody to turn to to ask a quick question to learn something about the job search or to navigate your career. And so that is what I want this podcast to be for you. I want it to be a tool for you to navigate the job search and your career.

So that being said, I hope you enjoy this episode. And if you need to reach me, Taylor at vaco.com is how to get in touch with me old fashioned email social media at tdesint D E S S E Y N. And finally, please rate and review this in the app store because I want this to be discoverable for others so they can navigate their careers. Hope you enjoy the episode. All righty, all righty. Happy Tuesday folks. When I say folks, I mean nobody because it hasn't hit the internet yet. But for those of you who are tuning in, welcome to this. Actually, Chris, you got the, you actually got the last episode of the week.

You got the last episode. Chris has got the last episode of the week. I am heading out of town Thursday to go actually compete in ice hockey tournament in Pittsburgh. believe it or not Pittsburgh adult classic and so Wednesday To be totally honest with you. I got a lot of stuff I got to do just to catch up with work and stuff So today is the last guidance counselor 2.0 of the week no unicorn finders. No recruiters anonymous You won't see me. You won't see my face on the internet for the rest of the week So Chris Chris and I are hanging out today very very excited for those of you tuning welcome say hey We'd love to hear from you YouTube LinkedIn, Facebook, Twitter, TikTok.

It's great to see y'all all this morning. But last I reached you in from I know Chris would love to hear from Chris. You're in Austin, right? Yeah, I am. That's literally my favorite city next to Nashville, literally my favorite city. I was also just out there. But now we're friends. So now when I'm out there, I'll definitely hit you up. We can hang. Yeah, yeah, I'd be good. Any excuse to eat some tacos and talk So, yes, Chris, Chris goes last episode of the week. Yes, Chris, last episode, I'm out for the rest of the week. So, so this will be the last one.

But yes, for those of you who didn't say, hey, the reason why I tell people to do that, this is a networking platform, okay? Basically, literally had a guy yesterday, messaged the post and said he got a job because of this show, right? That's what it's all about. That's why I tell people to say, hey, that's why I tell people to comment, to bring visibility to yourself. We're not in the metaverse yet. Chris and I don't got goggles on. We ain't hanging out with our avatars yet, except that we pretty tight though. So the only way people know, if you are tuning in, is if you say, hey, so please say, hey, even if it's your favorite emoji.

And even if you watch this in the future, please say, hey, because there are people who still network, right? So do that. Second off, this is a Q&A show. I do this live for you to ask questions to my guests. This is a there are very few times where you can get a director of engineering like Chris on a call for free where he doesn't bill you So ask questions take advantage of it, right? And then I also want to give a shout out to the coffee sponsor of the show that Conference for those of you who do not know about that conference. It is a conference run by Clark cell.

He has got a Austin Conference which I spoke at in January and then he's got a he's got a July conference in Wisconsin which I would be keynoting, which I'm very blessed to have my first keynote ever at that conference in Wisconsin. But he also provides the coffee beans. You can go to his website, you can buy them. They're actually really good. Believe it or not, I'm sipping them now, I promise. I want to get to the people tuning in. Our shots. Great. See for you. DeAndre Chris Garrett bill Ricardo David from El Paso. How far is El Paso from Austin? Pretty far away. Texas big.

Yeah, yeah, it's it's a 18 hours. Matt, it's great to see you, Alex. I have this great see you. Sam from Brooklyn. What's going on? I love it. Sam from Brooklyn. I got to get back up to New York. Randall, it's great. So yes, take Haitian for the rest of the week. Exactly. Michael, it's great. See you. He's got the popcorn ready. Michelle Cody, JC. We got the crew out today. So enough of me running my mouth. Chris, let's give the people what they want. Who are you? What do you do? And we'll go from there. Hey, I'm Chris. So I've been in tech since the mid 90s, starting in web development.

One of my first job was webmaster, back when the webmaster's were a thing. I don't know if anybody remembers that. Yeah, my first web browser was NCSA Mosaic. I don't know what that is. That sounds old. It sounds old. Yeah, no, it's really old. It's real. I mean, if you even go before that, I used to use Gopher. But yeah, so I was fortunate enough to be in the industry, really when it started. And most of us didn't know what we were doing. And lived through the browser wars. And when Joss Grit first came out on Netscape 2.0, That was something. And yeah, I've worked at companies of different sizes.

My first big corporate gig was at EarthLink. The ISB, it's still around and doing pretty well. I joined them just before the merge with MindSpring. And I started my career in mostly in front-end development before CSS was around, and then it just kind of came out, and then I learned to embrace that pretty quickly, and then sort of switched to backend development. And then I got into leadership in 2006, and I sort of, in this process, I developed a lot of my full stack engineering acumen on both the front and the back end as well, but also develop my skills as a leader and sort of learn a lot of things the hard way.

And then from there, I served teams of different sizes from a couple of software engineers to kind of growing them to 20 and 40 was at my last gig. Yeah, so that's sort of, yeah. I love it. I love it. So how long have you been leading teams for now? What'd you say? Since 2006, that was kind of when I first jumped into leadership. I love it. So one of the things we talked about backstage is I took some notes, motivating teams, coaching people, making a point to understand building diverse teams. Obviously, all these topics can probably have their own 30 minutes. So we have a lot to unpack here.

Can you just talk about maybe what your secret sauce is? Let's start there. I mean, what, you know, obviously, I think some of those are your secret sauce is what you said. But can you expound on those for me? Yeah, for sure. So I think one of the most impactful things that I've been fortunate enough to do is ask, ask better question. Sorry, Siri, just come to life. Asking better questions and part of this process is to really listen to the folks on the team and really sit down with them and really try to understand the challenges that they're facing. Right. But that sounds simple.

Chris. Right. Because that's the thing. I hear that I'm like, yeah, no shit. Right? I mean, talk, talk, I mean, in your experience, has that not always been the case? No. And so there's a, you know, and as a leader, you know, it's challenging, right? Because you're having to kind of deal with a lot of issues at a high level, right? So we're accountable for the executives, we're accountable to the executives that we work with. And, you know, a large part of our job is to sort of, you know, give them proof of stewardship of what we're doing with our team. Right. And so... I love that.

For stewardship. I love that. Right. And, you know, part of it is sort of gathering metrics from folks and, you know, how many points we did in this print, just last print, and, you know, our services do ratio. You know, and so there's a lot of administrative work that that kind of occupies our time. And at the same time, a lot of the challenges that are being actually faced by engineers are pretty deep engineering challenges. And so most often we don't have the time or the acumen to kind of dig down into there, right? And what I typically see is kind of like, well, we need to make this deadline, do whatever you can to make this deadline happen, right?

You know, we need to deliver this. Hey, everybody, you know, let's get together and do this. And it's like, and then it still doesn't happen. And then what I see many leaders do is like, okay, well, let's do scrum. That's going to fix everything, right? And so now you take a team that's already having challenges delivering software at a sustained pace. And now you're throwing sort of weekly or two weeks arbitrary deadlines on the work that they're doing. And it literally solves nothing, right? But there is a lot of thought leadership out there that's, you know, Scrum is going to fix everything. Right. And there's a lot of articles, there's a whole industry around that.

And I love it, I love Scrum, but to me it only works if you fix what 99% of your problem is, right? Which is what? engineering software. There's a lot of wisdom that's been around for decades to engineer better software faster. Sure. From principles of, whether it's object-oriented patterns, principles of screen architecture, There's a lot of things and a lot of wisdom that has evolved over the last decade as well. And what I found is many engineering leaders haven't really taken the time to kind of learn these things and sort of work with their teams to apply them to their challenges, right? And yeah. So you're saying, so you're saying, so what I'm hearing you say right now is that essentially Engineering culture is broken on a very low level to where people are trying to throw Band-Aids on it from a scrum or agile.

I know they're kind of the same thing with different flavors, but like they're essentially not fixing the root of the issue. Is that what I'm hearing you say? Yes, and that is an issue that is pervasive to our industry. And I've been able to sort of, so I've experienced this firsthand and made a point of addressing it And every time I have, it has paid dividends in a big way. But I've also validated this while traveling around the world and speaking at conferences, right? Like back in 2018, I started speaking at conferences around the world and I talk about these things. I literally lay out all of this in pretty thorough presentations, I have high levels and I have very technical presentations and I sort of give this sauce out to people.

And then I get all the hallway discussions with engineers who cut, you know, who come to me after we're in there like, oh my God, yes, yes, now we've been doing scrum but literally not doing any of these things and it's that we make such a big difference. Right. We did, right. And. Well, cool. Can you talk about some of those things again because I want to get practical here. Can you give just just an TLDR like bang bang bang bang what are what are the things that that need to be fixed. Yeah, so the the very first thing is like most teams are writing code really fast and in a way that introduces technical debt, right?

So if you look at your productivity when you start your project the first two weeks, you know, you feel very productive because you're kind of writing a lot a new code, right? But as time goes on, and I can be as soon as the fourth week, you have such a pout of crap on your hands. It becomes almost impossible to deliver something new without breaking something old. So how do you fix that within an organization? So the three main things that have been impactful for us that has been, that have been impactful for us, are sort of patterns, clean code, and test driven development, or there's aspects of extreme programming.

So patterns can be any number of things, it's really sort of how you compose software. And it could be the, you know, Martin Fowler's patterns of enterprise architecture, it could be the, you know, the solid principles, there's a number of those. It's sort of, you know, imagine this complicated blob and you need to separate it. That's very, very difficult to maintain, imagine it being able to break down the complexity of your business into individual maintainable components. And when you change your component because you don't have as much coupling with the rest of your system, you're not breaking the rest of your system. Right? Sure. And it sounds simple in theory.

And it actually is once you have the proper guidance, but most teams just completely ignore that. And there's a lot of very complex code that is really smart, but it is impossible to maintain as soon as the next day. So patterns are the first thing. Clean code, there are a number of books on this topic, but it's basically code you can look at and not have your little head blow up. Imagine avoiding having a class with like 20,000 lines of code. And imagine having methods and functions that are pretty small. And imagine having viable names that say really what they are. Function names are very descriptive.

Anytime you have to put comments to explain what your code does, I'm not saying don't do it. I'm just saying maybe your code could be a lot more readable. So clean code is the second thing. And then the third most impactful thing that is of these three things, this third thing has been the most impactful for us. And that's test driven development. And it's very much of a mental shift. Yeah. And why is it a mental shift? Because I'm a recruiter, right? And I've heard about it, but why is it such a mental shift within organizations? Right. So quite simply, when we first learned how to write software, it's, you know, somebody comes at us with, I need a system that does this, right?

And so in our mind, we translate this into behavior in our mind. And so once we have the mental picture of what the behavior is like, then we translate this mental picture of the behavior into working code. Okay. And then we will stimulate the working code and then look at the outputs after the fact. Right. So looking at the outputs, looking at the outcome is the last thing we do. Right. So that's sort of the typical process. The mental shift with test-driven development is imagine those outcomes that we check at the very end, we make that the very first thing. Okay? So we bring outcomes sort of as a first class citizen into the software engineering process.

And when somebody comes at us with requirements, the very first thing that we try to do is break down those requirements as a set of desired outcomes. And instead of documenting them, we literally just write a test to capture the outcome. And once that test is there, then we write the code to make the test pass. And this is where it messes with your mind because you wrote a test, but you don't even have code for it yet. Right. Well, isn't the general take on TDD from an upper management perspective or business perspective? It like it slows down dev times it takes too long, but it's one of those where it's like slow down to speed up, right?

Yeah, so that's the thing under the right conditions You can actually go a lot faster, right? And that's what my teams and I have found out is So the misconception from upper management usually is, when you add tests to your system, you're adding them after you've gotten your code to work. So that's like a lot of duplicate work, right? But when you do test-driven development, you write your test as your writing code, and it's actually faster because think about how you stimulate your system. simulate your system. I write a check out system on a shopping car. I build all those things front and back end.

And the only way I know that my system works is if I open up a web browser, I do a bunch of clicking, I submit the thing, then I look at my database, I look at the records, and I'm like, okay, did it work now? So there's like all these manual processes that you're doing just to answer a very basic question is, is my code working, right? But when you're working in a TDD workflow, a lot of this manual labor to stimulate your code and verify what it's doing, it goes away. It goes away and you're moving a lot faster. And so, and I've demonstrated that many times over with my team's work with the speed that, and the quality of the products that we're able to deliver, and the deadlines that we're able to beat.

But I've also demonstrated this flow in workshops. So I've done it in the US, in Germany, and in Holland, I've had like all day workshops where it's me kind of live coding in front of people with a class of 30 season software engineers, season software engineers, right? Who've been around for a while and they're just gonna follow along, right? And at the breaks, every single one of them was something they're like, oh my God, like this is so fast. I cannot believe this, right? So it's there, right? Right, I love that. I wanna get to Cameron's question again. If you have any questions for Chris, please hold them up.

Hey, Chris, I'm a growing developer with long term of becoming a director of VP of engineering. What would be your top two focus such key advice points for career development to successfully grow into these roles based off your experience? So the first thing is, is getting into leadership, period. So going from individual contributor to getting into leadership, it's a major shift. The first thing you need to be an effective leader is a drive to put other people in a position to succeed. And that becomes your job. and it can be challenging because, yeah. I think a passion for people, like when I, I mean, I've interviewed a lot of people in the show for three years and I think the biggest thing I've heard is that, man, you gotta love people.

Yeah, yeah, absolutely. As an individual contributor, you have a lot of control over your performance, right? Because, you know, as long as you learn, you can improve your own engineering acumen, you can work effectively with people to understand requirements, you can meet the deadlines if you do these things, you will be a successful individual contributor. When you become a leader, we are held accountable to the success of our teams. So, it doesn't matter. My engineering acumen is almost irrelevant if the folks on my team are not good at their job. If they're not, if we're not delivering on our deadlines. And to do this, you're gonna have to solve a lot of people problems, and a lot of organizational problems.

And so you have to have a drive and willingness and like you said, Taylor, a passion for helping others succeed. And to be successful, you're gonna wanna show the track record of this. And so whether you go from, you know, to to to manager or to director, you know, VP, it's that's that's that's pretty fundamental. Absolutely, absolutely. Let's see here. Sam from Brooklyn comes in. Can you dive into how TDD can dictate the process of actually writing code? Do you think that the resulting code is a better quality? Yes, it is, but it doesn't have to be. In other words, the nice thing about TDD is, you don't have to deliver the cleanest, most well organized, the most well composed code in the right away.

You can just get something working and as you move to your next use case, you can refactor as you go, right? And that's the biggest thing about TDD is that It embraces refactoring as core to the workflow, and it makes refactoring risk-free and painless. And if something is painless and risk-free, it gets done. The reason code doesn't get improved is because people are afraid to improve the code with good reasons because they don't have any task for it. So yeah, the code that, and also TDD forces you to compose your software in a way that is more conducive to a maintainable system because it sort of forces you to think into components that you can sort of, you know, break apart.

I like that. Sam, let me know if that answers your question. If not, we can definitely revisit that. I'm wanna go. And I do have a good amount of videos on my YouTube channel. It's bit.ly slash TDD-Vids. It'll redirect you to my LinkedIn channel. I have a lot of live coding videos on there. From a number of years ago, I need to update a lot of those, but the more recent ones are still pretty relevant. I love it, I love it. Let's see here. I wanna go to Alex here. When you're hiring, do you reply to cold emails from job seekers? Yeah, because of course, I mean, I talk a lot about, you know, cold emailing and networking and trying to DM's.

If you do, what makes those messages responsible? Like, what makes them, sorry, responsible? Sorry, because I'm responsible. Maybe it. Yeah, like, for me personally, Lincoln messages is the most impactful thing. So if you see me posting a role where I sort of layout what I'm looking for and you're interested in it, I definitely welcome a LinkedIn message. And with a brief outline of where you fall in the skill set that I've outlined in there, right? So I'll mention things like, I care about object oriented design and the solid principles and test driven development. And you may not have all those things, which is fine. And that's the thing that I've done with my job regs is if I have a job reg for a senior level position, what I'll do is I'll make it an up to senior level position.

So if I find somebody who has demonstrated this e-goness to learn during the interview process, I'll bring them in, for example, at a mid-level position because they can't quite cut it at the senior position. And if we can agree on the salary, then you're not talking about that backstage, right? Is that kind of evaluating the business as a whole and not for position? So you're saying though, Chris, is that you like to hear people talk about maybe something you posted in the job description. So if Alex heard a message, you'd be like, hey, you know, I saw where you have TDD in your job description.

I love TDD. Here's where I've done it. That's going to make you respond back to a cold email. Right. Yeah. So, one of the engineers I had hired, so here in Austin, I like being involved with some the local coding boot camps for people who are early in their careers and they're just kind of graduating from those boot camps. So I attend the events and I give everybody, you know, I walk around to the tables and I give everybody sort of the very similar advice in the same thing, right? I give them my email, my LinkedIn, and then a link to my coding videos on YouTube.

So one graduate actually, and I usually never hear from anybody. So I'm like, okay, whatever, right? Right, right. But one graduate actually looked at one of my videos, which, look, I'll be honest, they're pretty terribly produced, right? This is me at a cigar lounge with people playing dominos in the back, you know. That's fine. That's fine. You know, but it's for yourself, whatever. And so he subjected himself to one of those videos and he actually sent me a video of him replicating exercise that I was doing with a bunch of slightly different twists. And I was like, and I watched his recording, it was like, this is amazing.

And so there were a number of issues in it. But so I started kind of coaching him right away, right? I invited him to one of the slacks I belong to and we just kind of went back and forth. And then at the time I was actually hiring for mid-level engineer and I downgraded that rec from a level to, you know, junior. And so that, and what I just described is pretty risky, right? Like, as an engineering leader, I am accountable for the effectiveness of my team. So when you have a rec for a senior and you're downgraded to middle level or middle level or downgraded to a junior, you got to make sure that you have something in place to grow this person, to get them to the level that they need to be.

But the way I look at it is, you know, as we talked about, a lot of people focus on the wrong things. And I found that as well as people who identify as senior software engineers, staff software engineers, principal software engineers, there are a lot of very basic principles of composing software that they really don't have the acumen for, right? And so if I bring in somebody, you know, at a senior level salary, and I'm going to have to teach them all those things to be effective, I can literally take somebody who is earlier in their career without sort of, you know, a lot of the bad habits that, you know, have been developed and kind of teach them the same things and kind of get them effective in a similar amount of time, right?

And so, and to do this, you know, I've put a bunch of things in place, right? I've got, I usually like to put together a wiki that's a learning roadmap wiki. And you can jump, at any skill level and you can just kind of improve your skills based on the roadmap. And this wiki is a link to a bunch of free tutorials on YouTube and articles and things are available for free, right? So that's one of the things. Another thing is I developed sort of Kataz, you know, a Katai martial arts, it's kind of repeatable exercise to kind of Yeah, yeah. On a scale, right?

So there are a bunch of them which are good out there, which are free, but I've developed a couple of our own and I have different folks in our team sort of learn through those. And I put a big emphasis on pair programming. So, and that's the nice thing about sort of being in a remote world now. People can share their screens. Right. So you can collaborate and share your full screen. Whereas when we're in the office, pepper programming was just kind of awkwardly sitting at, you know, next somebody's desk. Um, no, it's, it has become, uh, uh, even more like that. So I put these things in place with a number of other things, which has really helped sort of rapidly sort of, you know, grow talent.

Um, it's out of the teams. I love it. I love it. Well, as we wrap up here, man, Tom Flos, if you're having fun with friends. I want to ask you one last question, right? Is this call, this show is called guidance counts are 2.0 because we had guidance counts as a middle school, high school and college. And that was adults. We don't really have like a guidance council, right? So what would be your biggest piece of advice to your younger self from a career perspective? Like the biggest thing that I've been fortunate enough to do is find sharper people than I am to learn things from them.

But I would say sort of do more of that. And I would point my younger self to a lot of things that I've learned over the years and be like, Hey, you know, look for this kind of people. So yeah, I love that. All right, man, well, where can people find you? Where's the best place for people to find you obviously, you know, you're we're streaming on your LinkedIn right now, but where's the best place people can touch with you? Yeah, LinkedIn is great. So for me, that's the best place to be feel free to connect with me. Send me messages, say hi, I love chatting with people.

I have a link to my calendar, calendarly on my on my LinkedIn. I encourage people to sort of you know, use it, set up sessions, you know, with me. And I've, and I just like to, you know, randomly help people, I like, you know, carving some time out of my day to day, just kind of do that. Sometimes it's starting to find their founders, they hit me up. Sometimes it's early career engineers sometimes, it's just more experienced engineers who just want to geek out on some topics. And it's a lot of fun, and I've learned a lot from a lot of people in this process.

So, you know, I love it. I love it. All right, y'all. Well, thanks again for hanging out with us today. Chris, thank you, my friends. Stay on so I can say, body you afterwards. But y'all have a great one. Go connect with Chris, shoot him a DM, and I'm off again for the rest of the week. And we'll see y'all back next Tuesday. See y'all. Y'all have a good one. Peace. Hey, you did it. You listened to an entire episode, and I am very grateful. Cause you know why? There's a lot of podcasts out there. a lot of episodes and I myself rarely finished an entire episode.

So I appreciate you so, so much for listening. Quick reminder, please rate and review this podcast in the app store. I want this to be discoverable to others. And the only way that happens is if you take the time right now and rate and review it, please, like right now, unless you're driving, then don't do it. So thank you again. If you need to reach out to me, tailor at vaco.com or at T. on all social media handles and I hope you have a fantastic day.