MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about being a team lead, specifically being a team lead. Why or why not? There's often a choice that you have in your career, and team lead starts you down a path sometimes toward being more involved in leadership. There's trade-offs involved there. 


You know, to have a good conversation, we have several current or former team leads. We have Afton with us, who has been a team lead. We have Jared, who is currently a team lead over at QA team. And we have Matt, who is currently a team lead over an engineering team. Justin, have you been a team lead before?


JUSTIN: Yeah. 


MIKE: I figured. And we also have Eddy with us, who has not yet been a team lead. I would like to, as usual, start our discussion with a story to kind of guide the discussion a little bit. And I've been thinking about this and how we might lead out. I decided I'm going to start by talking about a family vacation I took last year to Colorado. On the way out, we weren't quite where we were going yet. We ended up going to the Great Sand Dunes National Park. I think it's one of the less visited ones, and it's really beautiful. 


We stopped in the Denver area. I don't remember exactly where it was, so I can't tell you [laughs] precisely. But we wanted to get some fresh air. And we went for a hike. One thing I learned from my dad, which is a really good idea, is that when you're going for a walk or hike together as a family, it is a great idea to have the youngest or the slowest person on the group that you're with take the lead, be the person in front. The strongest walker or hiker you put in the back, and there are really compelling reasons to do that. 


If you put the fastest person in front, then they will have to look behind them regularly to stay together with everybody else. And pretty soon, they'll be way out ahead, and the group is all separated, which is a bad situation if you ever want to coordinate. That was particularly important back in the days before cell phones. But it works out great. I do the same thing with my family. I generally have the youngest person in front, and then we follow their pace. It works out pretty well.


MATT: That's how wolf packs operate. 


MIKE: Is it? That's good to know. It's just a really effective way to get everybody going at the same pace. We went on this hike. Like I said, it was beautiful. And we got up to a good stopping point where there was a loop that went around a small peak that [inaudible 02:27]. And my oldest son was looking at that peak up ahead, and he thought, I'd really like to do that. And he still had the energy, right? He really wanted to go ahead and do that loop. Or he actually just wanted to go straight up the mountain. [laughs]


I said, "You can go around the loop. There's probably a trail on the backside." And everybody else was kind of tired out and wanted to go down. In the end, we kind of compromised. I went with my oldest son. And we quickly went and did the loop around the top. He went up over to the very top, and I went around the side. And we met, and then we came down, and we met the rest of my family. My wife went with my younger kids; them go out in front. We thought we'd catch up to them before we got to the bottom, but they actually beat us by a little bit. 


I'm telling this story for a reason. My wife was an excellent team lead because she stayed with the people who needed guidance through the entire hike. My oldest son was the strongest hiker, but he did not stay with the team. He was just really hungry to go get to the top. And there was nothing wrong with that, right? It was great. You know, he's peak age physically. [laughs] So, you know, it's great that he wants to do that. But it meant that he wasn't really a good candidate to lead the rest of the group.


Contrasting the differences between what my wife did in staying with the younger kids the entire time, making sure she never left them behind, and my oldest son, who's just really eager to go and get to the top, I think, provides some perspective as to points that all of us may find ourselves in at different points of our career. Being in either position isn't necessarily bad, but they are different. And you kind of need to commit yourself to a role if you're going to be in one or the other. 


But, sometimes, you're going to be an individual contributor, and you just want to get to the top. There's some value there in contributing a lot of code to the team. And sometimes, you can provide more value in helping others along and making sure they get to where they're needing to go. I thought that was, in my mind at least, a good way to kind of frame this conversation. 


I'd also like to add that joining us a little bit late is Ben, who's also a team lead and has been a team lead multiple times in the past. So, I think I'm just going to open the question. And what are your thoughts, particularly towards the team leads or former team leads? What are your thoughts about the contrast between being a team lead and not a team lead, and why you would or not take that position?


AFTON: I had some thoughts while you were telling your story because I was a team lead over, at first, 8 to 10 engineers. That dwindled down a few for the longer term. But a few months back, I moved to a new team, back to being an individual contributor. And the dynamics of my new team were so different than I had experienced because the team was much smaller. The average engineer had a lot more experience than on my prior team. 


So, as you were telling your story, I was thinking the leader of the hike would have a vastly different experience and vastly different demands upon them, depending on who they're hiking with. You know, you may have really young, inexperienced, or out-of-shape hikers [laughs] and also very skilled hikers. And keeping them together it takes more work or more coordination, more communication, more group understanding of people's levels and capabilities, and how you can bring those together to meet in the middle. 


Versus if your whole group is very skilled, it's going to take a lot less overhead to keep that group in sync with each other and moving along together. Whether that group is all skilled or all inexperienced, it's largely the same. The overhead of managing that group will be, I think, much simpler. [laughs] 


The broader the levels of experience of those team members, the more work it is for the leader to keep everyone together. And the skills required of the leader can be different, so high communication and collaboration and making sure everyone understands each other, so people skills and team building. And you need to know who you're going to be leading, what the dynamics are of that group, the skill levels of that group, in order to ever even start to think, is that the challenge I want to take right now? Is that going to get me where I want to go in the future?


MIKE: That's a fascinating insight. You're saying that being a team lead is not one thing necessarily. It's going to depend a lot on the team that you're working with.


AFTON: Yes, absolutely. The team that I was leading was, I would say, majority junior developers with a sprinkling of very skilled developers, and even developers from different parts of the world. So, I had a few team members in India. So, also cultures of the different team members can come into play as well. 


And when I moved to my new team that I'm on currently as an individual contributor, most of the team members are very skilled have a lot more experience generally. And also, everyone is local. [laughs] We can all get together and sit by each other, which makes it easier to understand one another, work together, build some sense of teammanship, easier to manage overall. 


So, yes, the dynamics of the team, I think, will change what's required of the team lead, the skills that they're going to need to help their team be successful, and change the experience of what the team lead can then gain from the experience of leaving the team.


MATT: I strongly agree with that statement. You know, as Afton was just saying, I believe, currently, my team is represented in six different countries. And that adds a little bit of complexity because of scheduling, some language barriers occasionally, and just getting the right people on the right project so the communication can be there. 


One thing I think a lot of people worry about is if they become a lead, that they aren't going to be able to contribute. Well, sometimes that's true. And you may not be writing a lot of code like you are as an individual contributor. Your contribution aspect is still there. It's just in different areas. 


Here at Acima, our leads do a lot of architecture, and lead the design flow, and help with requirements, and a lot of the higher-level stuff that, as a contributor, you don't get as much experience doing. So, it really depends on where you want to go in your career. But I would highly recommend, if given the opportunity, everyone take the opportunity to lead a team at least once and get that experience.


MIKE: So, Matt, you say that it's worth doing at least once. It's a valuable experience, even if you don't stick with it.


MATT: Absolutely. I've done this a number of times. I enjoy the role personally because I love helping lead the architecture and helping make some of these business decisions, where you might not have the opportunity as an individual contributor because you aren't in the right groups, you know, for instance, in meetings, things like that. I know everyone says they hate meetings, but they're a necessity. And if you want to build good software, it's vital to have that understanding.


MIKE: You mentioned the meetings; that will probably be a recurring theme. If you're going to be doing some leadership, you're probably going to have to meet with some people, which means that you're going to have a higher meeting load than you would otherwise. It's just intrinsic to the nature of the role.


EDDY: Can I add I feel like there's a stigma with being a team lead. There's an association with being bombarded with meetings. So, as someone who enjoys thoroughly coding on a daily basis and constantly contributing to a codebase, would that individual be a prime candidate to the same [inaudible 10:22] position?


MIKE: I might refer some to what Afton said [laughs] that --


MATT: I'd agree.


MIKE:  It's going to depend a lot on what team you're working with. If you're going to work with a large, diverse team, probably going to be a lot of demands placed on you, and you're probably not going to have much time to also be an individual contributor. It really does depend a lot. I've had times when I was leading a team, but I'd still spend most of my time coding. And, generally, that was with a fairly small team. And I still had lots of time to code. And I've had times when I had almost no time to code. It really depended on the constraints that were on me.


MATT: Because our listeners may or may not know much about Acima and our structure, I came from a smaller team initially. And, on that team, at the time, we were extremely small. In fact, our team name was Nano. Our lead was able to write a lot of code most of the time because we were a very senior team. And we just kind of divided up projects and went at them. So, there wasn't a whole lot of guidance that he had to provide to us. 


Whereas, as Afton stated, the Atlas team is larger and has a lot more junior representation. So, it's a different role as a lead, a lot more mentorship, a lot more guidance, different tool set to lead that team as it is a small, more senior type team.


AFTON: I've been thinking a little bit about this. Eddy's question seemed to be kind of saying, when would this be a good time? [laughs] Like, I've done the team lead for, you know, a year, year and a half, and still love to sit and just write code. Going back to individual contributor, I was in heaven [laughs], spending a whole day writing code again.


MIKE: [laughs]


AFTON: Super fun. But that doesn't mean I didn't love the new skills I was developing and the new challenges I faced as a team lead. My situation was that I had been professionally developing for about three and a half years, is all before I started acting as team lead. And, at the time, I had been around the longest. I had a lot of business knowledge and a good foundation of technical skills. So, I felt like I could be a good mentor. Even if I was lacking in some technical skills, we did have some more experienced developers very available to me and on my team who I could rely on to help with technical leadership.


I do think it's an amazing experience that everyone could benefit from. You know, if you're given an opportunity, think about, well, first of all, the team dynamics of who you're being asked to lead, what it might require of you to lead, and how much time that might leave you to continue developing your technical skills. And if there's potential that you won't have much time, then to realize that you might start to feel like you're falling behind in your technical development, your own technical development, if it requires so much of the other skills to lead a team. But if you are being asked to lead a more experienced team, then you may have more time to continue working on your own development. 


I think it's really important to look ahead in the future. Think, a year from now, if I take this role and this is what I see it looking like, a year from now, is that going to move me ahead in my career and where I want to go? Or could this potentially be sidetracking me to somewhere where it might actually hinder my ultimate goal? 


So, think ahead of the future: a year from now, am I going to be glad that I did this? Is it going to put me in a better place? Or could this somehow put me in a worse place [laughs] hold me back from my ultimate goal? So, considering your goals is very important. Think about that and take the time to know where you want to be and to say, a year from now, where do I want to be? Two years from now, where? Five years from now, where? And now, does this fit within a path to get me there?


MIKE: Well said, Afton. You said --


MATT: The way I look at it is, let's use an example. Say I am going to work on my car. I have a toolbox. All I have in this toolbox is a screwdriver and a hammer. I can't get really far with that screwdriver and hammer only. And I see taking on new challenges, for instance, being a team lead, and there are other roles absolutely that help you fill this toolbox. It's just adding more tools to that toolbox. 


When we're individual contributors, sometimes we also get stuck in the weeds, right? We don't see the broader scale of things because we're picking up a story. We're trying to meet the requirements of that story. And we don't have a lot of input on overall architecture or how it's going to work with, say, other services. 


And I think when you take on that team role, you start to build those skills as well, more so than you might as a contributor, because you're seeing the bigger picture. You get to help guide how all the things are going to work together, defining contracts. And what does the structure of this look like? Is it a new service that we get to roll out? 


And you get to help design all these things almost like an architecture role, right? I think it would be a great segue into an architecture role if that's where someone would like to go with their career. And on the other side, if you want to go into people management, also get experience there. It's just I see it as another way to add tools to that toolbox.


MIKE: Kind of combining what you're saying there, Matt, with what Afton had to say, you may be at a point in your career where you look, and you just see that hammer and a screwdriver, and what you need is maybe some wrenches, [laughs] and some basic tools. You don't need a very special tool. You don't need, like, a transit for doing surveying. You just need some wrenches or a saw.


Depending on where you're at in your career, looking at the team lead role, some of the tools that you may be putting into your box are not the ones you need right now. And maybe what you need is more language skills, you know, some of the basics. It's important to look at what you need next in your toolbox.


MATT: Right. Like Afton went to an entirely new language. Now, her toolbox is filling up on that side. 


MIKE: Exactly. 


MATT: I feel like a lot of people are very apprehensive. And there's kind of a bad stigma behind becoming a lead because of the meetings. But there are skills to be gained. Being able to communicate with business and understand their language and translate that to technical language it's a really positive thing if that's something you might have a little interest in but are apprehensive because you don't want to be in meetings.


AFTON: Yeah. We were discussing earlier how much time is spent in meetings. I don't feel like they were detrimental. In all those meetings, I felt like I was learning communication, collaboration, higher-level business. How do you make decisions? Project management was a big one. I spend a lot of time studying [laughs] how to manage projects. 


So yeah, those are all really good skills to have, like Matt and Mike were saying. But realizing those are the skills you may have to focus more on, of course, again, depending on your team dynamic, but just to realize what skills you're going to need and that that may be your focus for that time. Being aware knowing what you're deciding, what you're choosing is important.


BEN: Kind of a different topic. You know, one of the things that I've seen with businesses is that a lot of times where they fail the most, it seems, is with management. We kind of think of management, at least I have, I guess, as kind of, like, this easy thing that you can learn really easily. And probably anybody can learn how to do it. But I've seen people manage coders, but they kind of are not being the manager. They really just want to code, and yet they're in this manager role. 


They're kind of doing their coders a disservice because they're not really fulfilling the needs of that role, but they are the ones that have that role. And, you know, nobody else can really do it but them. And so, I guess that's one caution I would give out. Like, if you're a lead, be a lead. Don't be in the lead role and just try and keep just being a coder because you do pretty much everybody a disservice by doing that, I think.


MIKE: To go back to my talk about the hikers at the beginning, you might be the fastest hiker in the group. Hiking up ahead of everybody doesn't benefit anybody but yourself. It doesn't get the project over the line. The project is to get everybody up there. There's a lot of value provided by being that person who walks in the back and helps the others along. And acting like that's not the most important thing that you're doing is problematic. 


Micromanaging and telling people what to do is usually not very helpful. Helping people out and, figuring out what the requirements are, and removing obstacles for people is immensely useful. You can spend all day removing obstacles for people, helping them along, and move the project forward much faster than you would if you were just chipping away at your own little piece.


JUSTIN: If you look at your effectiveness as an individual, you need to look at yourself as, like, how can I multiply my effectiveness? Where am I most effective? Once you understand that it's through helping other people be more productive themselves, it's kind of a game changer. That's one of the reasons why I was kind of attracted to this app sec actually was, you know, oh, I can go out and help a lot of people now develop more securely and more productively. 


But, you know, as a team lead, you have the closest insight to all of your team members, and you know what their strengths are, what their weaknesses are. And you can go in and talk to them each individually and help them get over the things that are affecting them, and help them be more effective engineers, more effective communicators, and lots of different things. 


And so, it's kind of a great opportunity to—you've probably heard of this—but be a leader servant, where you are helping others and, ultimately, you aren't being the great individual contributor that you possibly could be. But you are raising the overall work output of the group and helping them in their careers and, you know, just as individuals. So, I think it's one of the best ways to really help other people, you know, a great position to be in just because you can help them at that personal level.


MATT: Helping other people level up is extremely fulfilling as well. A great analogy would be sports. You might be the best player on the court, but if you're not a team player, your team isn't going to be successful. If you're just going out trying to score all of your team's points all the time and not passing the ball, your team isn't going to win. So, sharing that knowledge and picking things up for them, you get double covered; perfect time to lift someone else up and get them some points. And that's how you win. 


As Mike said, the only person you're helping is yourself sometimes if you're not fulfilling those other needs as a lead. I feel like you're even doing yourself a detriment. And it doesn't reflect well. So, you just have to be really open to what the role is. And it isn't just going out and getting all the points for your team. It's helping your team win.


JARED: You know, Matt, I really like those sports analogies. I've been listening and reflecting upon my career and where I'd been a leader. And I've been thinking about when I first got into a management position when I was managing a restaurant; I came at it from the approach of...everybody's heard this phrase, "If you want it done right, you do it yourself." I stressed myself out. I was a very mean and angry person.


As I grew in a leadership position, I learned that that's not how you manage. That's not how you handle people. And when you're a lead, people are the most important aspect of that. At this point, as a lead, you should be coaching, and mentoring, and training, and allowing your team to also take leadership responsibility and empower them to do their role. 


And also for me, I think that, if you want it done right, do it yourself, came from a lack of trust. And so, as a lead, you also need to trust your team to do it right. But also, you should train them to do it either the way that you would do it or the way that you would expect to have it done. But also give them the leeway to learn and expand there. 


I don't know if this is even a controversial take, but I don't like the idea of people wanting to be leads. That, to me, always seems like a red flag. And I'd like to hear everybody else's experience. But I truly think that leaders are found by different leadership and say that, you know, "You are level-headed and can handle stress. And I think you can handle working and meeting these other people." 


And for the most part, they step up to the plate and learn this new skill set. I've never really looked at it like, oh, I want to be a lead. It's that I've been asked to be a lead by somebody who saw potential in me. And I said I'll give it a shot and see where that goes.


MIKE: If I had somebody say, you know, "I want to tell people what to do," then I would not want them to be a lead on my team. On the other hand, I saw somebody who was already helping people around them, mentoring, taking their time to help somebody when they were stuck, going out of their way to remove blocking issues for somebody, or to go get a question answered. Well, that person is already doing what I would want from a leader. There's nothing wrong with aspiring to help people. I think that there is something problematic with aspiring to direct people tell them what to do. What does make things feel better is helping.


MATT: You also hear people say things like, "A good leader hires people who are better than they are." Team leads generally aren't management. They are just leads that help guide their team, right? As a lead, I feel like your goal should be to make your team members better than you, at least try. Give them the skills that you have and share them. Also, learn from them. So, you're gaining skills as well.


EDDY: This is sort of, like, a point-blank question to everyone. Has there ever been a time where you've been afraid to promote someone who is one of your highest producing individuals on your team to assume the role as a team lead, knowing full well that not as much code will be going out or, like, higher difficulty tickets will take longer, et cetera? 


MIKE: Yes. [laughs]


MATT: Also, yes.


MIKE: Absolutely. Because there's going to be reduction and just absolute...the amount of code that's getting written. There's a trade-off there. Somebody who's good for the lead role; however, you probably won't lose that much output because the multiplier that Justin was mentioning means that they will be helping other people get more done. So, you don't take as much loss as you might think.


MATT: You may see a drop up front. But if they're doing what they were put there to do, you're going to see a lot of gain on the tail end because everyone else is going to be able to be more productive, and level up their skills, and make up in that difference, right?


AFTON: I keep hearing so many parallels to Parenthood. I just need to mention that real quick because [laughs] one possibly unique thing about our culture here is that we have a wonderful culture of mentorship and learning together. And I think that that must inform our feeling comfortable moving a high producer into a lead position and letting things slow down for a bit, but eventually level up because everyone's benefiting, learning, having good experiences, and growing together from this.


Just like, you know, I think it was Jared who said earlier, if you want it done right, you have to do it yourself. And my first thought was, yeah, I had to let go of that when I had to start teaching kids how to do chores around the house because [laughs] it's not going to be done right. It's going to take longer. It might not even get done. 


But I need to start letting them learn how and do that job for a while, keep helping and instructing, and, eventually, they will grow better. Very like parenting, you want to give everything you can. It's going to take some time, extra effort, but they're going to level up. They're going to grow into capable, skilled people, and that is, you know, worth it.


MIKE: And if you don't give them that opportunity, your kids reach 18, and they're not prepared [laughs], right? 


AFTON: Yeah. [laughs]


MIKE: And that happens inadvertently. You think, oh yeah, I'm trying to be helpful and trying to do everything. You help people out by giving them a chance to fail a little bit.


BEN: I think that's a really good point because it's kind of giving up control to some degree. One other thing I was going to say is that it's not necessarily the highest producers. I mean, that may be obvious, but there's some people, you know, that you can tell they would really hate being a team lead, [chuckles] you know, they just want to be in the code. And that's fine.


MATT: And it's not for everybody. It really isn't. Some people just have no interest, and it isn't what they want to do. And that's okay. One of the things that I just would love to be able to do is remove some of the stigmas that come with the role and have people have a more open mind to that opportunity. Because there's a lot of positive aspects of the role. 


I personally...I love it. I love being able to work with the other teams, which, as an individual contributor, you don't get quite as much opportunity. You know, Ben, you and I work together a lot, especially recently. And it's great because I may not have had that opportunity otherwise.


AFTON: If there is a stigma, that can be mitigated to some extent by just having a clear structure in your organization, having clear definitions or descriptions of each role and what's expected. And if someone is assuming this new role, they know what they're getting into. They know what new skills they are going to need and what demands will be upon them. Then, people can just make informed decisions. Is that what I want or not? 


I'm trying to understand the stigma that you're talking about, Matt. And I'm just kind of assuming that maybe if people think it's going to be something that it ends up not being for them, or if they have frustrations because expectations were not met, which could lead to a stigma of it being a bad thing or the meetings being a bad thing. But, anyway, clarity on what the role is, what the expectations will be, what the demands will be, I think might help.


MIKE: Well, and there's different kinds of meetings, right? If you're in a meeting where you're barely engaged, and people are talking about stuff that doesn't concern you, and it runs on for hours, that's excruciating for me anyway. [chuckles] You have to be attentive enough to see if your attention is ever needed. So, you can't really put your attention elsewhere, you know, you don't really need that attention there. So, you're in this in-between area where it's really hard. 


That kind of thing can make anybody say, "Well, I hate meetings," if they've been in meetings like that. But this is kind of...it comes down to our individual responsibility. Especially if you have a lead role, you have an opportunity to kind of define what that meeting looks like, say, "Well, we're going to have an agenda. We're here for a reason. The reason that we're meeting is because we need to solve problem X. We need to talk through it." And the whole reason that you're meeting with somebody is because you need to communicate and come to some shared understanding. 


And once you've met the purpose of that meeting, then you can be done. And the kinds of meetings that have an agenda, that have a clear goal, and that end with action items and a decision, those are invigorating. That kind of meeting doesn't drag you down. It actually is very rewarding. You can be architecting and feel much like...and is even part of the coding process in defining, you know, say, architecture, or determining requirements, even, you know, refining stories.


It's all part of the coding process, just as much as having your fingers on the keyboard, you know, typing code. The stigma of meetings or the sense that, oh, I'm just going to be in endless meetings, even if it was true, which it probably is not, the meetings that you're going to be in, that you can influence, you can make actually very effective. And it's not a negative thing. It can be a lot of fun.


MATT: Yeah. And I kind of have a personal rule that if a meeting doesn't end with any action items, that meeting was all for naught. Meetings need to have agendas. They need to have action items that can come out of them, and then they're productive.


MIKE: It seems simple. Like, well, it's really that easy? It kind of is. [laughs]


MATT: I would have no problem if people were in a meeting that I organized, and they got an understanding that they didn't need to be there. They can just drop. You know, hey, I don't think I need to be a part of this meeting. I'm going to go help out my team or take care of other things that need to be addressed. And, you know, maybe that's something that people could set as a rule. If you don't feel like it's necessary that you're in this meeting, you are free to leave.


EDDY: Let's say that you just, like, naturally enjoy being in a leadership role. Would it make sense in regards to being a team lead for a development team? Would you say that it's a requisite to have knowledge in programming in order to be effective in that role?


MATT: For an engineering lead, I would say yes. For an engineering manager, not as much. Though it is helpful when you understand what your team is talking about, right? And it can help guide them because that's part of the job, aside from just HR duties. But there are a lot of CTOs at companies that really don't have a whole lot of technical experience. They're just really good at guiding. They're great with ideas and helping build teams to see those ideas through.


MIKE: I think that somebody who's very effective does, however, understand the engineering process. Even if they are not necessarily in the code, they understand what it means to engineer something, that creative process of building things. 


AFTON: Yeah, when I started as team lead and was trying to really grasp what it would mean to be successful in that role, I did a lot of research on the various roles in engineering. And most of what I came across when talking about team leads was actually referred to as a tech lead, a tech lead meaning that their role really is to be a technical leader, which meant they needed technical experience and, you know, a lot of development skills. So, above that, would be more manager, like they were saying. So, here, I believe, team lead is essentially a tech lead role.


JUSTIN: Just a quick comment about the CTO and any leadership position that isn't coding directly and that can go up from manager to director to VP. The ability to know what it takes to build something and know when, you know, there's some BS going on on the engineering side that's a very vital skill that those leaders need. If those leaders don't have the ability to detect when the wool is being pulled over their eyes or when they don't know what's really going on, or they don't have the skills to find out, they usually aren't that effective as a tech leader. 


The best leaders I've seen, or some of the best leaders I've seen do, come from an engineering background. They founded the company as the original engineer, or they came up through the engineering ranks. And they happen to have the very great leadership skills that allowed them to be at the top. And those types of people actually inspire great loyalty and inspire their workers to work hard and to be able to see their vision. 


It's not easy, certainly not. But if you do have those skills or if you have interest in going in that direction, it's worth researching how to do that, how to be a leader, because not everybody just picks it up naturally or anything. It's something that you study. It's something that you decide you want to go do. And it's something you practice. It's something that you interact with others and receive feedback on. And that's hard, receiving feedback. And actually, I'll go into that receiving feedback a little later. 


But all those things, it's a lot of work to be those leaders, especially ones that can inspire their engineers and be able to share the vision that they have. And it's what inspires people, you know, to go that extra mile and to make sure that the work that they're doing is correct and that they care about their work. The great leaders can share their vision, and they can also understand what work is needed and what work is really going on.


AFTON: This is my first career job. And so my experience is limited to here at Acima. But I would imagine that what's expected of you, or what you need to be able to do, skills you need to have, or the amount of technical skill you need versus managerial skill could vary greatly depending on the company, like the size of the company you're working for. 


If you're a brand-new startup and they're trying to get things established, the demands on you may require lots of technical but also lots of managerial skill to fill a role as the company is trying to get established. Or if it's a larger company and they have enough people and enough foundation to have just a tech lead who doesn't have to do anything managerial or just managers who don't actually have to know anything technical [laughs]...I don't know; I'm just imagining that that actually could vary greatly, depending on the company you're working for the size of the organization. 


And one thing for me: when I started as a lead, I was trying to understand my role and what was expected here at Acima so that I could put some kind of boundary on what was expected of me because I know myself personally. If I don't know kind of what success means, then I'll just keep pushing and trying to do everything and get overwhelmed or, like, burn myself out very quickly. [laughs]


I tend to try to do it all unless I have some kind of ceiling I can say, this is as far as my reach needs to go, or these are kind of the boundaries around what I need to do to do my roles successfully, to meet expectations, to exceed them, to be effective, to have the greatest impact in my role.


MIKE: I think you're dead on, Afton. There's companies that have HR-only managers, right? They have no technical expertise at all. But they do a great job of the aspect of management that has nothing to do with technology. And then they have tech managers who are purely responsible for the technical side. But I think most companies, the roles will have kind of a hybrid of both. I think you're dead on, and figuring out what the requirements are where you're at is going to be really valuable so you'll know what the expectations actually are.


EDDY: I just want to add this has been extremely insightful. I'm better grasping the idea of what a team lead does. [laughs] Because prior to this, again, I fell victim to the whole, oh yeah, team lead, meetings, right? So, this was great.


MIKE: And it's been good to have you, Eddy, as that voice who's not done it before who can ask those kinds of questions. Really appreciate it.


JUSTIN: I briefly mentioned this before, but I think that team leads need to remember to be humble and to ask for feedback from their team members. Getting that feedback is key to leveling up your team lead ability. And finding a mentor who perhaps is another team lead or some other tech leader is also key. And that way, you can gather that feedback about how you're doing, what your weaknesses are, and what you can do to get better.


MIKE: Thank you. And maybe that's a good place to draw this to a close. As you're considering taking a lead role, find somebody who can talk to you about it, who can mentor you, and kind of explain to you what's going to be going on and can help you as you make the transition and grow your toolbox. Thank you to our panel today. It's been a great conversation. I guess we won't see you again, but you'll hear us again [laughs] on the next episode of the Acima Development Podcast.