w/nate taylor on leadership within software development

full transcript

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

I have another guest. We are having more guests on this thing because sometimes I just hate running my mouth for 15-20 minutes. I have my new friend Nate Taylor from Omaha, Nebraska. Nate, thanks for joining me and I appreciate it. Yeah, absolutely. I'm excited to be here. So for those of you who are wondering, hey, who is Nate? I will let Nate introduce himself. But to let you know how this came about, Nate, I'm sending you a link to if you want to post. That's just a way to my YouTube. But for those of you, and again, we'll get started here in a second. But this conversation came out of the fact that Nate tweeted, I think Nate slid in my DM's or I slid into your DM's, but Nate had a tweet about leadership.

I think I tweeted about leadership and tech and Nate retweeted it and Nate had a really good, thousand. Nate, you need to come out, man, that was really good stuff. So today we're going to talk about today we're going to talk about leadership within the software development community and also just keeping your employees gauge from a hiring major side. So this could absolutely be applicable to the job seeker side because I always say hiring managers are just job seekers with a job. And so, but again, we'll go ahead and get started this morning. So again, thank you all for doing the guidance counselor 2.0. We are going to talk about leadership and tech today with Nate Taylor.

Nate, go ahead and introduce yourself. Let the people know who you are and we'll go from there. So I'm Nate Taylor. I'm in Omaha, Nebraska originally from Kansas City, Missouri, bounced around the Midwest a little bit. I have a degree in electrical engineering and tried that for about a year with caterpillar and then decided that software was the way to go for me. And so I've been doing that for the last 20 years. Mostly as an individual contributor team lead solution architect, all that kind of fun stuff. The last seven years I was a consultant at a very local company, a very flat organization which left me try out a lot of different things, which was cool.

And then earlier this year came on as a director of software development at Pluralsight, or I've been now for three months. And I've been around them for about seven years as an author. So that's a quick intro of me. That's awesome. And by the way, I don't know. I didn't even tell you this. We had Don Jones on unicorn founders, my other podcast. So just let you know local connection there. We're slowly becoming more and more friends with people at Pluralsight, which is great. So Nate, I want to go ahead and dive in, man. And let's talk about leadership. Let's talk about keeping engineers, developers engaged within obviously, you know, their workplace.

Let's first off, just talk about your thoughts within leadership within tech. Let's start there. Just high-level thoughts. Maybe some good, some bad, and some ugly there. I think it's a scary topic for a lot of people. Because you and I are chatting before this started about like how networking scares people. And I think the word leadership scares people because they feel like it means they have to be someone like me that took on a director role. And on my computer at Pluralsight, I don't even have VS code installed. I've never installed Git, right? And they're like, that's scary. It's an individual contributor. So like, I don't want to give that stuff up.

But I don't think it has to be because like I said, for the last seven years, I was at a consultancy that was flat. I was definitely a leader there. I mean, that came out as I left. It came out during my time there. And I wrote code. I actually wrote more code than I wanted. I wanted to be writing less code and doing more traditional leadership type stuff, more stereotypical leadership stuff. And so I think that's a scary thing. I think sometimes it's good. When it's done well, it's amazing. You have someone that's in your corner that wants to see you succeed, that wants to listen to what your path is and where you want to go and help you achieve that.

When it's done poorly, it's horrible. And it's, you know, it's former engineers that kind of, I think part of the topic, right? So maybe this will lead into it. But former engineers that were like, well, I want to keep getting a raise. So I guess I'll go into management. And then they don't quit coding or they think that they're still code. And you're not getting the attention as an individual contributor that you need. Like, you're not getting the guidance, you're not getting the support because they're too busy putting out fires or trying to get the next cool system. Yeah. And so I want to talk about what works, what you've seen works and organizations and what you've seen that is kind of a dumpster fire, right?

So, so let's talk about your experiences. What is worked well? What do companies and high manage to be mindful of right now on how to build out a leadership track and what that should look like. And again, just some few thoughts from you this morning on that. Yeah. I mean, I think one of the things that's important is to understand that as cliche as it sounds, there's a lot of different ways for leadership. It doesn't, doesn't have to mean a title, although it can, right? So you can, if we look at just simply coding, you could lead an epic, right? So this major thing in your product, like you could be the point person for that.

That's actual leadership. You're having conversations with the customer, you're having conversations with the team on how you want it to go. You're maybe responsible for the deliverable. Like, those are things that leaders have to take on and you're doing it while you're a developer or while you're a designer, right? And so I think that's something that can work is, is have that. And I think the other thing that just is really important to keep in in mind is, you know, as a director or as a leader for me, my job is not to tell you where to go or how to get my job is to help you get there.

But if you say you want to be an architect, we're going to figure out ways and has to get you to be an architect. And if you say you want to stay at Coder for the next 20 years, we're going to figure out ways to make you an amazing Coder. Those, that's things that need to happen, right? Like it has to be that support where, at the end of the day, if you're, if you're successful according to your definition of success, then I feel like I'm successful if I'm your manager. Why do you think companies have such, excuse my French, shitty leadership, especially when technology within technology?

Because I see it time and time again, right? Within within what I do, the inner workings of thousands of companies now at this point in my career, right? You've seen in your careers. Well, why do you think companies fail in leadership within tech? I think it's a different, it's a different skill, right? So in my career, this is how it's happened. And, and I, let me preface this by saying, I take a lazy river approach to career development. So I'm not a lazy river. I don't have a, I don't have a sheet of goals. I know I've never moved towards goals. I've just kind of floated in the like, hey, this is an area I want to hang out for a while and share it all right.

But in my career over the last 20 years, I went from like a junior developer to a mid level developer, to a senior developer, to a lead developer, to kind of this hybrid thing and then ultimately a director. And each time it was because I was doing well at the level before. So I became a senior developer because I was doing good as a mid level. I became a project lead because I was good at a senior developer, which that isn't necessarily a prerequisite in my mind. And so I think that's a lot of what happens is we take these people that are phenomenal. And I'm not saying I was phenomenal.

We take people that are phenomenal at coding or design or architecture. And when we put them into this in leadership position, this management position, and they might not one, have the desire to do it. And two, they haven't spent the last 15 to 20 years working on that. And so they're not as good at that as they are system design. And so it's very easy to just gravitate towards what you're good at. And if you're really good at architecture, you're going to hang out in architecture and tell someone kicks you in the butt and makes you not. And companies aren't doing that, right? There's like, well, I don't know.

This Nate guy, he was really good. He contributed a lot. Maybe he got the most cards done in a sprint who knows what the metric is, right? But then they do that. They don't often assess for aptitude. And I don't mean like a test, but like just sit down and have a conversation. Is this something you want to do? Do you actually want to be managing people? And if the answers know, then don't force them in there because not only are they going to be frustrated. But I can tell you firsthand experience that their people are going to be frustrated, right? Like they're going to it's going to suck because they're not going to invest in you.

They're going to invest in themselves and they're going to be grouchy because they're not getting to design architecture or whatever it is. And so I think that's a big part of it is we just, you know, the Peter principle, right? We keep promoting. And we don't ever stop and have a conversation of like, is this something you actually want to do? So good. Well, I think one thing that's consistent of interest here with us on this is taking time and asking. Yeah, taking time and asking. And I feel like, and this is my joke. Maybe this is a thing, but I'm pretty proud of the sales, sales driven development.

SDD, we're not TDD and we're not BDD and we're not DDD and we're S I got to be careful though, SDD, SDD. Yeah. It's that like, what are your thoughts on that? Because I feel like organizations just run, run, run, run, run, run. And I feel like, especially now with with how tech is, I mean, we're in, we're in historic levels of boom right now. Companies are snatching up everybody. I'm sure you're seeing it as well with trying to hire. And I almost feel like if companies like took a minute to chill and like actually figured out their organizational structure or leadership structure, and maybe like they got behind on a few things, I think they could get ahead the next 10 years.

Yeah. I mean, I think so. I guess I don't have a ton of experience just because like, like you said, it's a boom right now. And when I was thinking about these things, it wasn't, or when I was living them more, I wasn't necessarily the boom. But yeah, I mean, there's, there's always that desire to, to go go go. And sometimes that forces weird structures, right? Like, well, we don't have someone for this thing. So let's just put this person there. Right. And then you talk to that person. And you have a, you, this is one of those times where not having a leadership title can actually play out because there's a, there's a, there's a a syndrome called white, white coat syndrome, where you go to the doctor and they take your blood pressure.

And it actually raises because you see them in the white coat and you get nervous. And if we're just going to change your black, your blood pressure would be better. Right. The same thing happens with leadership. If your boss or the CTO or the CEO or a director or VP comes and talks to you, your answer, because you're not an idiot is going to be like, yeah, I'll do that. Right. Like, yeah, no, I like my job. I do not want to get fired. Thanks. Exactly. And then you have someone that isn't, doesn't have a leadership title, but, but is kind of in that leadership.

And they talk to you. And you find out that that person doesn't want to be doing that. Right. And so, some of that is the power dynamics, I guess. And so we just put people in those positions and they're like, I really don't want to do this, but, um, I guess that's what I have to do. So what are some tracks? Right. So what are some tracks? Because because I, I put out something on Friday where it's like, I think companies right now, and for those of you who are watching any questions, any leadership questions, please ask Nate, add us, comment us, I'll throw it up on the screen.

I know Nate would love to hear from you. But Nate, for me, what are some, some tracks or some ways companies can keep employees engaged without promoting to leadership? Because like, for me, it's like, man, like, I know after my entire career working with software engineers, they love to mentor, but they don't necessarily want to lead. They want to tinker around with new tech, but they don't necessarily want to like architect. Right. Like, like, so what are your thoughts? Like, what are some good ways companies could like listen to this live show, take notes from Nate, and then integrate it into their environment because of what you said.

What are some areas that companies could do? Well, I just made the answer a whole lot scarier. Yeah. Pardon me. Here's how I know things. Yeah. No, I think I think the one of the things that I liked the best in my career was when I was early on at Caterpillar, they had like a lot of big corporations, right? There was pay grades. So you were like a 13 to 14 to 15, whatever. And I have no, like I've been gone for 15 plus years now. So I have no idea if this is still true for them. But when I was there, and so there was like, you could be a 13 or let's say a 21 probably, you could be a 21 and that could be a manager.

But as a technical person, maybe you don't want to go into management. And so what a lot of companies do is they stop the tech scale at 20 and 21 and above as management. And what Caterpillar did was there is a scale all the way up on tech as like each of the manager. And they called these tech stewards. And you became more of an expert on things. And so if you think of Caterpillar equipment, one of the important things, this is the one that always took out for me. One of the important things is you need to be able to see what you're working on, right?

So you need lights. I honestly can think of so many more things that would be more interesting to me than lights. But they had a tech steward on lights. And this guy was phenomenal. Like you could go ask him questions and he could rattle off like I was just wondering. One or that one, right? He lumens like all this kind of stuff. And he's like, well, you need seven of these versus two of these, but two of these are going to drain more power and all this kind of stuff. That guy makes or made Caterpillar successful in part because he could help you define the lights.

And so by not saying like you have to go into this area. And so when it comes to software, you can do the same thing, right? Like one of the ideas we talked about among my friends while was like if you had, you had an expert on front-end technologies, right? Like they could be coding, they could code maybe 20 hours a week. But the other 20 hours a week, they could be making sure good practices are going on across multiple teams, right? And then you could get even more specific. Like if that front-end technology group gets too big, well, okay, now we've got a CSS expert and a JavaScript expert or a React expert, all these kind of things.

Someone that knows just the browser. And so there's there's so much depth that a team that an individual could have. Like you'll never you'll never hit bottom of the deck, right? And so I think that's something that companies can do is still have your person work primarily on a project, 20, 25 hours a week, 30 hours a week, but also let them be that internal advocate and internal expert to say this is how we do things at my company at XYZ. This is the patterns we use. Because honestly, you probably only have one or two of those in the company anyway. And everyone are like, well, I'm just kind of copying what I saw.

So why not throw that in front of why not let an expert take that on? And then they don't have to go into management. And it's very valuable to you because now very large teams and the consistency is there. Now they can grow in different ways. Like you are investing in your employees. And so it's not like it's a cost center. Once they hit that level, it's still providing actual ROI. No, I love that because I'm starting to see titles like, you know, obviously you have senior, and then I see some senior ones, senior two, whatever, then you have like staff and then you have different stuff.

And then you go into, I've seen stuff like principles and then I've seen fellows and I've seen technical members of staff. Like, like I think companies do need to get creative. Listen, titles are not everything, but I think as a hiring manager and organization within leadership, I think you need to, you need to have that. Right. Vaco has been historically flat. Right. We have been very, very flat. The end of the day, you recruit or yourself, there's not much middle ground. But as we've grown, we've, I do, I think we could do a better job. I think so. I think there's different more. There's different ways to level things that we have.

But I think title isn't everything for everybody, but it is for some people. Yeah. And I think companies need to be aware of that. And obviously kind of, uh, obviously have those two tracks, right? Which absolutely love. I didn't even think about that. So that's fantastic with, yeah, well, Caterpillar thing. Well, if you think of what you just called out, right? Either seller you recruit, like, there's things that an very experienced recruiter has learned that will take years for a very junior recruiter to learn. Correct. And our current model in the industry is just to like, well, I had to go through that and it sucked.

So you have to go through it, right? You've got to actually play. Why are we okay with that as a company? Like, why can't we take some of those bigger lessons, help that younger person or less experienced person short circuit that and skips the wrongs and be more productive quicker? Well, now that senior lead, whatever recruiter, they're providing value in addition to landing clients, they're also growing the company and saying now this person that might get two clients a year now or right? Like, how is that not more valuable? Yeah, absolutely. So let me ask you this. So I asked you a question. Joshua, I will get your question in a second.

Thank you for asking that. And if everyone has any more questions, we're going to wrap up here with with Nate. But, Nate, the the the final question I have to ask and I know this is kind of I didn't even prep you on this should managers code go. So that's very very topical. So I've I've had this debate internally for the last three months. Not that I not that I should code or not because for right now, like I don't even have the time, but should I even have the access? And so so far for three months, I've deliberately not requested access to our GitHub repo.

There's some probably some good documentation on there that I could read, but I also know that for right now, my nature would be to like, let me start looking at PRs. I'm like, I don't I don't need to be doing that, right? Like they got it set up. And so I really think that if you're going to be a manager, your number one job is the success of your team and the success of your team's probably not happening if you're coding. Like, could you are you the best coder on the team? Possibly. Like, that wouldn't be the case for me for sure. I have some amazing people on my teams.

You might be the best coder, but that doesn't mean that your team's successful by you coding. You need to be fostering your bot, learning how to how to work with people, how to help them have their success, be your success. And that's not going to happen if you're focusing on hitting Jira tickets and PR and all that kind of fun stuff. I love that. I love that you mentioned that so concisely. I appreciate that. So so this is going from a career perspective. Joshua goes, how would someone get started in software development? I have my thoughts that I've been preaching on. Nate, I want to see if you obviously have some thoughts.

So the joking answer is go watch all of my courses on Pluralsight. I mean, that I wouldn't mind if you did, but that's not going to necessarily help you. I think it's very similar to how you grow as well. And so software development exists to solve problems. You have problems in your life that might be solved by software. And there's nothing that says that you can't go watch some courses, go read some blogs, watch some YouTube tutorials, whatever, and learn just enough to get started so that you can start solving this problem. And then when you run into problems, go look those up. Right. So here's an example from 15 years ago.

My wife was really getting into fitness. And so we created a calorie tracker for her. This was in 2005 maybe and like those didn't exist. So I wrote a VB6 application, which was old at the time using access, which was old at the time, but it allowed her to put in her macro nutrients and track it. And then she could go back and say, I had the same thing today. Let me just add it. That taught me a lot about software development that I didn't know, even though it had already been coding for five years at that point. But it was a real problem. It was something that she was interested in.

It was something I was interested in because she was interested in. So what are those things in your life? Maybe it's like the generic answers that to do list. Maybe that's it. It's probably not. But what are those things? Right? Do you have a big library of books? Right. A library application. Are you a movie buff? Start writing a figure out a way that you can like cross reference movies and scenes and actors and all this kind of stuff. Do something that's interesting to you because you'll be more invested. If you go in my spare time, I train Brazilian Jiu Jitsu and Judo. I wrote an app that tracked the hours I spent at the gym.

That's probably not interesting to you. And you're not going to stay involved if that's not a thing that you're interested in. So find that thing. Learn the language doesn't matter. PHP, Python, JavaScript, dot net, pick a language, start working on that. What do I need to do to get this up and running? Let's just print something out on the screen. Okay. Now I'm running into this issue where when I add these two numbers together, they come out weird. Research that issue. And just keep building that way. And I always say this is a hiring manager. I've said it as an interviewer for years. The word production is meaningless.

Like, I don't mean did you get paid to put this somewhere. I'm it. Have you have you done this? Right? If you stand up a domain like couch jitsu, which was what my blog is for Jiu Jitsu, like that's production. Right? Like it's out there. People have read it. I didn't get paid to do it, but that doesn't matter. Right? Like I've gone through some of those issues. And so that's how I would say is find something that's interesting to you. You know, kind of take an MVP approach, minimum viable product. What's the least amount of work I need to do to get get some progress?

What's the next step? What's the next step? And in, you know, three months, six months, 12 months, you'll look back and you'll be astonished at how much you learned in that time and how much you're so good. That's awesome. That's awesome. That's great. We can end there. Nate, thank you again for coming to our man. I really, really appreciate it. For those of you who are watching, definitely connect with Nate. Nate, where's the best way to connect with you? Linkedin, Twitter? Where is it? Either of those, Twitter is probably the one I read the most. And so that's T-A-Y-L-O-N-R. That's not a typo. That's a whole other podcast episode about how that came about.

But that is that is my Twitter handle or you can find me on Linkedin either ones fine. I love it. I love hearing from people. That's awesome. Man, well, thank you again for coming on. Yeah, thank you again for tuning in this morning. We appreciate it. And y'all have a fantastic Monday. Thanks, Nate. Yep.