Transitioning from Development to Management

This is Building Better Developers, the Develop-a-newer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We're continuing our discussion with Tim Stratton, a developer extraordinaire, we'll say. We'll give him a nice little title there. We're continuing going through a series of interviews. And in this case, we are hitting a lot of topics around somebody that has been a solid developer for a while and is looking at transitioning or is in the process of transitioning into the more architectural managerial type role. And we've talked about some of the things that got us here, some of the things that he learned along the way, getting those early years out of the way and growing a solid technical background and foundation. And now we're moving into how those things have prepared him for the next phase of his career and some of the things he's running into. This episode we're going to focus on, basically it's a managerial mindset. It's lessons learned as far as what makes somebody good as a manager, what some of the responsibilities and maybe some of the best goals to have when you're trying to lead a group and grow beyond simply writing code where everything sits on your shoulders and building out a team that allows you to expand your skills into that team and leverage their skills so that you become better as a whole. And with that little maybe cryptic introduction even, let's get back to talking to Timothy. Before we move and go forward, I do want to swing back, there's two things that you mentioned that I want to come back to. One is you talked about being, I put down the note of being as a manager sort of taking on the pain. You worded it differently, but it's really, you want to have the frustration over your team. And I think that is a, again, it depends on what you, there are management books on how to be a better manager that talk about that and how the, and I can't remember which one specifically said it, but basically summed it up that the goal of a manager is to remove obstacles for their team. You set up a good structure, the people at the bottom of the pyramid, if you think of like, I guess the CEO at the top, and then you get down to all of the worker bees as you call them or whatever. But really it's the lower people on the totem pole that are the workers that actually do stuff. They are the ones that get things done. And so the best structure then is as much as possible to have the people that manage them and as you work your way up, that those people are removing obstacles for the ones below them to do their job. So a CEO is basically trying to set a vision and put things in place for those, whatever they are, the vice presidents to be able to know what they need to do. And then the vice presidents need to be able to get things out of the way and line stuff up so that their directors know what they need to do. And then the directors need to be able to do that down to the managers. And you eventually get to the point where you're basically one step off of the doers and you're in that case a lot of times getting, I think, actually in all cases probably, is getting a lot of feedback from those underneath you. And the better the relationship with them, you have the better for them to be able to say, this is what's slowing us down. This is what our problems are today. And then the better managers are able to take that and sort of keep their head up a little bit and look ahead. If you think of, you know, like if you're on a train and you're going to the tracks, there's people working on the train as it's moving down the tracks. But then you've got somebody that's looking ahead to make sure that, you know, oh, there's a cow up there. We need to have somebody clear the cow off the track or whatever it is. It's not a great analogy, but I think that's a very it's a real important thing to consider before I think you go into especially going from a technical to a manager role because there is a I hate to say it this way, but you're sort of being taken care of when you are when you're a coder and a developer and even sometimes up to sort of architects and lead designs where there are people that that's their job basically is to make it easier for you to do your job, for you to focus on what your your strengths are. And as you step into those manager roles, then you become one of those people that has to recognize the strengths and potential obstacles others are going to reach or going to run into and then work with that to make them sort of a coach because you want to get the team so that every member is is working with their is effective and they're working in their areas of a strength and you're offsetting their weaknesses and you're removing obstacles. So it's it may seem like a prestigious career move, but for some people it isn't. And it's not I guess it's not as much prestigious as it is. It's a it's a change in focus. I think that's why some people don't want to they they prefer to never go into the management path and instead stay stay more technical. And I think this that's sort of and I'm sort of in the same boat, I think, in my trajectory. And I think that's sort of where the solution architect is, is comfortable for me is that it does sort of bridge that gap is that you're you're doing very technical stuff, but also you're working with customers and you've got teams and things like that that you're working with. So you're helping while you are being a sort of a doer in some extent, you're also in a lot of ways clearing paths for others and helping them. And this goes back to as you talked about laying out those designs and that communication so that maybe you maybe you're helping to maybe break up some of the big and large problems so that those workers don't have to think about them as much. They've got much more of a marching orders kind of thing. So they don't have to think about that whole picture as much. And they can instead focus on more bite sized pieces and get some solutions done. Certainly. Just to speak on that, what I've learned and what I've read is that management is where you may be 90 95% in the weeds as a developer or coder. Management is it should be if not zero, very small five, maybe 15% of your time is in the weeds doing development. And the rest of that is relationships. That's what I learned. You have to set up the relationship, the relationship to the ones under you doing the work, the relationships to those around you and above you to communicate that work to then be able to pass that work off, aligning priorities, aligning processes. All of this is relationships. That's what I learned. And if you want, that's what I'll say. I'll say it assertively. In fact, if you want to be in management, be ready to build relationships. Whereas most technical people are the introverted type. It's not to say that the introvert can't do management. In fact, I'm an introvert, but be ready to, at the very least, come out of your shell enough to understand the people who are doing the work, understand the people who need that work done, and align with them. I got some tough feedback, and I'm fine with that. You have to be ready for tough feedback. One of my seniors told me you got to stop chopping onions and start just tasting the broth. Because I was trying to still do a little development here and there. I can't tell you when the last time I actually wrote code. It's been a few weeks, in fact, which is fine. And you have to be accepting of that. It's no longer you trying to bear the weight of the development task yourself, but you're empowering others to do that. And in empowering others, they're hopefully taking on some of that productivity that you maybe had in yourself. Because you've cleared the path for them. Exactly what Rod is saying. Being able to just take on those frustrations, because frustrations are going to slow anybody down. Filter out the noise for your team. Because there's plenty of people that have plenty to say, politics, narrative, so on and so forth. Filter that out for them. Don't let those things get them in a place where they're getting frustrated with the work. Because plenty of work is going to be coming their way if you're doing the job right, at least hopefully. And so from there, I told my team, I may not be able to always create an environment for happy development or happy developers, but I guarantee you I'm going to strive to make sure everyone is a healthy developer. And so frustrations may come. They may have to refactor some code here and there. And here's some tough feedback on a pull request or something. But that's part of the job. The frustrations, the hurdles and the politics, all that is not part of the job in my mind. I shouldn't expect that of developers. And so that's where the relationships come into play. I have to build those relationships and bear those frustrations for them. That is awesome. That is an excellent, I guess we'll call it a soapbox or whatever. But I think that is very, that's well stated. And I it's very important for people to realize that. And it's honestly not even look up technical managers. It's, I think just managers in general, that's one of those that sort of things that it is a shared experiment, experience or required skill, I think, regardless of what you're managing or whether you're, I've found that whether it's coaching and managing, as I sometimes see those somewhat similar as in whether you're coaching a little, you know, little league T ball team, or whether you're managing a fortune 500 company, I think that those relationships and that, that ability to, you know, to work with your team and to be a part of them, but also work with them and lead them is is key. And that that chopping onions thing is so common among developers and it was our developers turned managers. And it's actually one of the things that I early on, I sort of, I was lucky the first time I was really a serious, like a full, a real manager, I mean, I'd been sort of like a player coach kind of role of a manager that was also just doing stuff, but also helping to manage the team or lead the team a little bit. But I, I walked in a role where I was told, you know, this is this is manager, period, we're gonna we're gonna do management stuff. And you're not going to have to code, you probably will not code at all. And I, I didn't. So I will almost was not allowed to fight it. You know, it was I did have some things where I said I had sessions where I sat down and I would talk them through designs and help out some of the developers and coders. But generally speaking, and I did I did zero, I didn't, I had no coding stuff on any machines that I had. I don't think I even logged in very often other than to be a face to do email for, for months, and it made a difference. Because there were other people there was five or six of us that were sort of, you know, all peers that had our development teams. And the ones that had grown up within the company, because I came in, this is at sprint, and I came in fresh into that management role, there were a couple others that have been developers and had sort of graduated up to that role. So they still had ties back into the code. And it challenged them because there's a lot of times that they they would, and I know their developers would complain to them and say, Hey, look, let us go do our job. You need to go do these other things. You don't need to be doing the coding part, the developing part, you need to be doing the managing part. And so that's something, you know, something throughout there. Sometimes it's it helps to when you want to make that kind of a change or that kind of a step in your career, sometimes it's good to get sort of a clean start in a sense, where you you move somewhere where you don't have the tie to the, you know, down to the core level. And actually, sometimes I find that that's, it's, it's sort of nice now walking into some of those where I'll say, Okay, this is what you want me to do. Don't even put the code on, you know, put the source code on the machine, or I don't want to log into the repository or something like that. I want to see documentation, and I want to talk to people so that they become, in a sense, they if I need to know something about the code, those people become my hands and feet, as I'll say, Hey, this thing doesn't seem to be working, right? What do we know about it? How do we fix it? And instead of me looking at it, they, you know, I basically am now a sounding board for them, where they'll say, Well, here's what we're seeing. And here's what we think can work. And, and sometimes I don't even have to say anything, just them talking through it, they'll say, Oh, you know, but let's do it this way. Or they'll say, Yeah, this seems like exactly what we need to do. And then it's like, Okay, great. I'm glad to have listened. Go do it. And it's I think that is a that's part of a natural part of the growth, though, is is growing, particularly when you're good at what you did before, as you're good as a developer. It's hard to, it's not really completely set aside, but to somewhat set aside that skill, as you you focus on a new one, it'd be like, you know, if you're a master basketball player, now you're going to go play baseball or something where you have to sort of set aside the basketball stuff. So you can learn this, this new sport and the new set of skills. But that's, that was, I love that. That was awesome. That's why we do these interviews is because, you know, get some great little snippets like that, or, or, you know, minutes or two of just pure wisdom. Well, one more that I want to touch on, just because you'd mentioned the reading is it's sort of funny is that I think that's, that's so key. You have to read maybe not books, but you need to at least read, you know, be reading articles, or now you can at least listen, you can do podcasts and things like that. But I think you, it helps them a lot to immerse yourself in content around that. And it reminded me of something that was sort of shocking, I guess, a little bit when I when I first heard it, is that there was a pastor that said, you know, if you're going to be a, if you're gonna be a pastor or a preacher, then you've got to read. And his argument was that there's just, which is sort of funny to me, because this is something, you know, this is in a 2000 year old religion of Christianity, they have, you know, you would think there's nothing new. And yet, there is, there's all these new viewpoints and news experiences and everything else. So if something that's that, especially at its foundation, so set in its ways, you know, the Bible is, I guess you can do translations, but it's, it's not like it's being, you know, there's not new, it hasn't been expanded upon in a long, long time. How much more so, you know, our world where technology, there's new, since I graduated college, there've been, I bet hundreds of new languages, and at least dozens that are in, you know, mass use. And that's just the languages, that's not including the libraries and the frameworks and the platforms and all of the different stuff that's out there that I think even as a manager, it doesn't matter what it is, even if you just touch on technology, you're gonna have to be comfortable with learning. And that's, I think that actually, when I, if assuming I ever someday retire, that may be the hardest part would be to not continue learning. And it may be that that's not it. Maybe if I, you know, quote, retire, I'll still be one of those people that is constantly just, you know, keeping up with technology, even if I don't use it. Yeah, it's, you know, you've got to, you've got to keep refreshing that, that pool. And that will do it. Let's wrap up part four, we do have more ahead, there's plenty of time that was spent talking with Timothy, hope this is bringing you some, some insight and some enlightenment, as well as it did me just to, you know, really to get another person's perspective of how they have grown a career from, you know, from scratch, as all of us have to do. And I think even when we're maybe in different stages of our career, some of the steps, particularly the successes and the mistakes or failures that others have made can help us refine our, our plan, our roadmap for moving forward so that maybe we, you know, take advantage of some things that helped others, or we avoid some of the obstacles others have run into. And this has been, this episode in particular has been a joy for me to do in talking to somebody that is newer, you know, newer in their, their managerial process of their, their career and how they're progressing, because it does remind me of some of the things that I learned early on, and particularly some of the things that I have experienced with managers that I've worked with and for that were successes or things that I looked to emulate as I, as I moved forward and seeing that this is not, it wasn't just me, it wasn't just my personality or how I, and we'll say clicked with those people, but these are some things that are, you know, maybe some common traits that you're going to find if you want to be a good leader, if you want to find a good leader, work for somebody that, that makes work enjoyable and not too much of a chore. And since I think this has probably been about as much of a chore as I'm going to push at you this time around, we will wrap this one up. So go out there, have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernord.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Nord. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Nord site. You can also find it on Amazon, search for Rob Rodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developer.com if you would like more information. Now go out there and have yourself a great one.