Career Journey 3: Assembling & Nurturing Engineering Teams | Code Story's Noah Labhart

0:00What I really try to do is I try to ensure that it's not me against you. It's not boss giving feedback, right? It's us facing our shared goals. And so in the beginning with the best advice I was ever given with my wife to treat all problems this way. It's also got the problem. That's right. Yeah. It works. It works in relationships too, right? It works in marriages. It works in relationships. It's the same sort of idea like, hey, we're on the same team and we're facing this problem right here together. And this problem may be that you're not performing well in this area. it. And we've agreed that you've agreed and you've signed off on like, you want to get here, right?

0:40And me as your, yes, manager, but also your boss, your mentor, your friend here, I want you to succeed. Hey, listeners, at Dev Interrupted, we spend our time talking to engineering leaders about what makes them and their team successful. But how do you know what makes an engineering team great if you don't have anything to compare it to? Last year, Linear B released the first-of-its-kind Engineering Benchmarks Report, and it's quickly become the industry standard for teams looking to understand and benchmark their software delivery performance against industry peers. Live today, Linear B has released its 2023 Software Engineering Benchmarks Report.

1:17This year's report analyzes 3.6 million branches from over 2 ,000 dev teams and across 32 countries. Discover the all-new engineering investment benchmarks, deep dive into data by team, size, geolocation, and industry. Plus, see how elite teams perform against Dorometrics and get acquainted with brand new benchmarks introduced this year. Become the envy of engineering teams everywhere. Download your free copy of the report today at linearb.io or use the link in the show notes. Hey, everybody. We are back on Dev Interrupted. This is your co-host, Connor Bronsden. And today I'm delighted to be joined by a fellow podcaster, Noah Labhart, co-founder and CTO at Variable.

1:55Noah, welcome to the show. Thanks for having me. Super stoked to be here. You might also know Noah as the host of the podcast Code Story, which features loads of amazing tech leaders, such as our very own Dan Lyons. But in his own right, he's a founder, a CTO, and software architect who spends a lot of time reflecting on the careers and the products that other leaders have created and understanding the best routes to be an incredible engineering leader and build excellent engineering teams. If you aren't familiar with Code Story, definitely check it out. I know I really, really enjoy your podcast and your email newsletter is great as well.

2:29I appreciate that very much. It's a labor of love, as I'm sure you know, but you get to talk to some amazing leaders. Well, we're very glad you were able to join us on the show and it's definitely something we resonate with because that's kind of our favorite thing as well is talking to these incredible leaders and learning from them and challenging them on their approaches. It's because of those conversations that you have on the podcast and your career experiences that they really make you a perfect person to have on our show to continue this series that we've started on the career journey of being an engineering leader.

3:01You describe yourself as someone who is passionate about building world-class teams, and that's exactly what we want to talk about today. How to build great teams and be an excellent engineering leader. To start, there's an intriguing approach that you've taken in building your engineering teams, particularly with hiring career-changing engineers. Can you explain this concept? Yeah, sure. Sure. So, you know, I think it's important to define what a career changing engineer is. And, you know, in general, generally speaking, it's someone who, you know, perhaps worked in a non-tech or non-programming environment prior to getting into a tech job.

3:37Right. Probably in the middle of those two things, there's a boot camp or some sort of self-learning process where they have learned the practical skills to come in and do some programming. So what we've done at Variable is really pay attention to those types of individuals. One, because they're excited, they're hungry, they're new in their career as far as the technical side of things. So they're really excited to dig in, to build new things, to sort of create a name for themselves. And then two, they have a perspective on the environment sort of from a user standpoint. They see the world not just from the coding IDE and then the command line.

4:21They see the world as the end user because they used to be one. And so we've seen a lot of value in having team members that have those experiences in their career prior to coming into technology. It helps them create a well-rounded product. So I hear you talking about these advantages and the ability to create a well-rounded product, connect with customers. These are obviously huge benefits for an engineering team. What about downsides? Are there any things you have to adjust in your process to account for maybe more junior or non-engineering backgrounds? How does that affect your product planning and development process?

4:55Sure. Great question. So usually, the most optimal way we try to set this sort of situation up with career-changing engineers is to have some senior talent on the team alongside them. Right. So and that doesn't mean that, you know, one senior engineer per career changing engineer. Really, we have some folks that are computer science background, have some experience in architecting software and building software that have proven they essentially know how to do that. And a really important part of that is to have them in a leadership role or in a lead architect type role to be able to oversee and to teach these individuals.

5:40So I mentioned that, you know, career changing engineers are super hungry, right? And so giving them challenges and giving them feedback, it is well received by those individuals. And so having a little bit of senior leadership that helps to instruct those folks and lead those folks sort of to the water to drink is important. And in the early days of Variable, that was me. It was me and then a handful of essentially career-changing engineers. And what was cool about the early days of Variable was that we were figuring it all out together. And I was able to provide sort of the computer science sort of foundational algorithmic know-how, so to speak, to create that foundation and create space for these individuals, not only to kind of learn as they go, but also a space for them to build something to put their name on.

6:37And I think that is something that's critical, to give a person that type of opportunity that's career changing. Again, like I said earlier, they just eat it up. That makes total sense to align these senior leaders who can help mentor and teach while also having these high growth individuals with this high incentive to improve their skills and learn and bring this different perspective. However, I am certain that there is challenges you've seen around maintaining that balance given that you've also scaled your own efforts in other areas with CodeStory, with growing the organization. How have you maintained that balance between these career-changing engineers and more traditional backgrounds or more senior backgrounds?

7:21So if I was to put a percentage of career-changing engineers versus more traditional computer science type folks, it would probably be something like 25 % to 75 % of actually 25 % computer science and then 75 % career-changing. And that's not a hard, fast rule, but just kind of for discussion purposes. So think about that from a team composition standpoint. What is interesting about career-changing engineers is they're not always career-changing engineers. After about a year of working in a startup environment where you're throwing everything, we definitely believe in throwing our individuals into the water and watching them swim with coaching from the side of the lake, but with the appropriate coaching.

8:11And we want them to immerse themselves and do well. So after a year of a startup type experience where they're shipping code regularly, they're learning on the fly, they're doing those, they essentially start to develop into seasoned engineers, right? And so one thing that's really important in the process that we do with our career changing engineers is to start to identify people with two things. One, people leadership capabilities. And then two, architectural know-how or the potential to be an architect, I think is a better way to say it. And those individuals, we start to grow and give opportunities into either growing in the people management side or growing in the architectural side.

8:54Again, throwing those sort of opportunities at them and growing them into those individuals so that as they step into those roles, we're bringing in more career changing engineers underneath them. They're able to passionately grow them either in their architectural know-how or in leading them as people because they've been in the same position. So it creates this sort of secession, this sort of, I don't like the word hierarchy, but ladder of secession where everybody's pouring into the next generation and it works out really well. I would think that that kind of investment in career growth and just simple skills growth is also probably a great retention play for you to ensure that these career changing engineers, it's given an opportunity to stick around and continue to grow the organization and deliver the benefits of being fully ramped and more senior.

9:43Absolutely. That's absolutely true. In fact, I have several individuals who were with us from day one who were the first hires that are still on the team today. From July and earlier, February, January, February timeframe of 2017, they're still working with us today. Some of my lead engineers and actually some of my senior management that were in those roles and they grew into the roles that they are in today. That's a fantastic testament to this approach you're taking. I wonder what the key traits are that you're hiring for as far as the senior engineers who you hire in to help lead and mentor these teams.

10:18Because some senior engineers don't want to do that work. They want to focus on the code base. They want to take their own approach, whereas others are very excited to do that mentorship. How are you selecting for that in the interview process? That's a great question. So there's two things in our interview process, specifically for the senior side of things. One is the technical capabilities. We want to see that you're a senior. We want to see that you can do the things, that you can architect a good solution, that you know what you're doing. The other part is we bring them into the office. We do a whiteboard session.

10:53Everybody's got their coding challenge. Everybody's got their technical challenges. Like, yeah, I interviewed at Microsoft and Google, and I was there for seven days, and we were on the whiteboard for six of them. right? And they asked me, you know, how many manhole covers it would take to fill this room and yada, yada, yada. We don't do that. What we really do is we put some of the individuals in the room that they're going to work with and we give them a problem and we start solving the problem together. And what we look for is how they respond to people giving feedback, either positive or negative, or changing the equation of the problem in flight and how well they adapt to the change, but less of, it's important to be able to solve the problem, be adapted, but less about that and more of like, how does they work with a team?

11:38How do they ask questions to the team? How do they respect the other team members that are bringing questions to them or seem like, I don't think that's going to work because of this. Is there another way we could do it? And what that brings out is that sort of collaborative nature that is required for a variable engineer because that's a key part of our team dynamic. what strategies are you employing after you bring in these folks that you think are a good fit to continue to foster a culture of collaboration and communication that you clearly value on your engineering teams yeah absolutely there's a couple of things that we do one of them you know one of them feels maybe a little bit less of fostering but more of a stamp in the ground it's a we ship code on the first day so first day you put your name in the stack so this is your platform right And it could be a bug.

12:26It could be something small. But your name's going to be essentially in the... You're going to have a commit with your name on it. And so we do that. Past that, we give people high autonomy here at Variable. We give them high autonomy and high expectation. So I'm going to give you a project. I'm going to create the bumpers on the bowling alley so that I know essentially where you're going to bounce back and forth. And I'm going to watch you deliver results. My expectations are here, right? I'm not, I believe in you. I hired you for a reason. My expectations are here, but I'm not going to micromanage you.

13:05I'm not going to tell you how to get it done. And what we observe for the people that are successful here is they start collaborating with other folks that have worked here longer. So they're going to their leads. They're going to the senior team members. They're saying, okay, this is what I'm thinking about how to solve this problem. I need this resource or hey, I need to bounce this idea off of you or hey, can we get on the whiteboard and solve this problem? So that collaborative nature comes out of the people that are successful on our platform. And that's how we measure it. If people are going into a silo and trying to build everything themselves, it's a red flag.

13:41Immediately, it's like, hey, something's not working, right? You're off on an island by yourself. You're not going to be successful this way. We need you to come back into the folder. there. How do you figure out when you need to cut bait? Because I think these concepts are great, and you clearly have this distinct engineering culture that you developed with very clear intentions of here's how we want to build and sustain our kind of internal developer experience and community. We want to have it be a team effort. But even with these hiring approaches, I know not every hire works out. And a lot of leaders who are earlier in their career or beginning to take these first steps as entering managers, maybe want to give a long rope to team members who come in and don't turn out to be a good fit.

14:29And I don't want to say it's easier to identify when things are working well, but it's certainly easier to run with it if I can say, oh, this person came in, we thought they were going to be a great collaborator. They are. This is awesome. That's something I know how to handle. But we all face this challenge of conflicts internally on the team. Maybe it's a skills gap that we didn't realize. and then in particular, these like cultural alignment issues. What are you doing when you face those? Yeah, that's a great question. And honestly, I was the guy in the early days that gave too long a rope, right?

15:01So I kind of learned the hard way a little bit of how we do it today. And it's not an exact science. You know, people are people. They're not an equation, right? So there's a little bit of a, there's a little bit of a kind of a unique application of what I'll describe. But basically, it comes down to the results. It's that high results. We're going to give you autonomy. We're going to give you a project. And we're going to expect you to deliver these results. If those results aren't met, we're going to give feedback that they weren't. And we're going to be direct with that feedback. Be like, hey, you did this great.

15:33But this part didn't work. This part didn't work. This part didn't work. And we need you to change those things. Here's another project. And when those things, if those things are not met or not addressed, then essentially that's the time for, okay, we really got to shorten the leash because this is trending in a real bad way for not only for us, but for you as the individual, no one wants to be in a job where they're not performing well. Yeah. Right. And so we, we really shorten that leash and we say, okay, for the next week, you're doing this very small project. We're going to give you this project.

16:08It's, it should be done in a week because we sort of know how our team functions. We know how our team should be delivering. And we essentially say, we need daily check-ins. We need daily check-ins on this week-long project and we need to see your progress. And if those individuals are able to come out of that, then we start giving them more leash back and more leash back. If they don't, we make the hard decision to have to cut ties. Really, and again, I go back to that point, like no one wants to be in a job where they're not doing well, they're not performing to expectations. And so it's a hard thing to do.

16:42it's it's the hardest thing i would say i've ever done in my career is to have to cut bait with someone and i haven't had to do it a lot but a handful of times i've had it's it's been hard you know because you want you want to hire people and you want them to succeed it's almost like your your kids right like you hire someone it's like your kids and when it doesn't work out it's it's a challenging conversation to be like hey this this isn't working we need to we need part ways you mentioned that you felt like earlier in your career you had maybe made some of these mistakes where you you kept things going too long hoping the problem would get fixed trying to fix it can you maybe talk us through an example of you know not using names but just when when you think that happened and what you would do differently today absolutely yeah i mean early hires i won't use names and time frames because we're a small team but we'll call it we'll say early hire i I definitely gave a longer leash to an individual on our team.

17:40And what happened, because of my delay in accepting the inevitable truth that this person wasn't just going to work out, we kept that person on probably six months longer than we should have. And that led to many weeks of long hours for the entire team, right? Because we were having to fix problems. We were having to check in on this person to make sure they were doing what they were supposed to do in sort of our, you know, as much as a startup can, architectural standards, right? Fixing issues, taking ownership of their part of the product. And I kept giving more and more chances, more and more chances, just thinking, okay, this is going to be the thing.

18:23They just need this one thing. They just need this one thing. And after that was all exhausted, it's like, okay, you know, we've, we've got to move on. My business partner actually was a great coach for me during that time frame. His name's Mike Kinder. Gave me some great coaching on people and how to hold people accountable, essentially. And I've carried that through today. But that was a hard lesson to learn. I definitely hear you on that. Because I think a lot of folks, when they first come in as a manager, struggle with that accountability piece. Because we don't want our direct reports to be frustrated with us.

18:58We want to be liked. We want to foster a positive culture. We want to encourage them. But it's really important that you actually also hold them accountable to those high standards. You say, look, we're a high-performing team. We're going to hold you accountable to these because it's what's right for the whole team. When you fail to hold those folks accountable, it impacts, to your point, all the other devs, all the other product managers who are dealing with this, all the downstream salespeople who are trying to sell the product. and it is also something where it is putting them in a position to not be happy either as you mentioned like we want to make sure we're having team members who feel good about the work they're doing who are also getting the feedback they need to improve and when we as leaders fail to bring accountability we are undermining that now to be clear i'm not saying like you need to shout at someone when something goes wrong like there's a way to do this there's a million and one trainings out there talking about how to be good about accountability, how to do it the right way, how to coach folks.

19:57And I highly encourage you to dive... People are listening to dive into those if they feel like it's an area of growth. But taking that action is super important. So I appreciate you sharing the story because I think it's hard for us sometimes to admit, here's something we had to fail at and then learn and grow and overcome. Yeah, that's one of... It's interesting. On CodeStory, I get to talk to engineering leaders galore and founders. And that's one of the most common things when I ask about a mistake is that I let someone stay on the team too long when they weren't a fit. And I hear that often.

20:30And I have done that myself. And it's so important. And you can deliver negative feedback sternly and directly without being a jerk, without yelling. You can just be like, hey, this isn't working. And I want it to work for you, but it's not. This is what I need from you. you know. Absolutely. Well said. And I think it probably has a little bit to do with the statement that I've seen Variable and yourself make about we hire developers, not programmers. You're looking for folks who have not only some built-in accountability, but this desire to be hired sheepers and be part of a team. That's right.

21:06No, that's exactly right. So the kind of premise behind that, there's an article and I'm going to botch the name. I know the guy's name is Eric, and I'm trying to remember the last name. I'll have to look that up. But in that article, it talks about developers versus programmers. And early on in the days of variable, I internalized this sort of definition for myself. And it kind of aligns with the idea of career changing or what the things that I said with career changing developers too, or career changing engineers, is that programmers, the way I view programmers is that they don't do anything but program.

21:43and they require a lot from the rest of the company to do their job. So they require requirements. They require specs. They require other people to test their code, X, Y, Z, right? In variable, really in a startup in general, but I can speak to my experience of variable, there's nowhere to hide. There's no basement, right? We're all in this together. Our engineering team interacts with our CEO, our market teams that are out there selling the product, our platform teams that are sort of going through the strategy of how we're going to move forward on a daily basis. We're all one big happy family, right?

22:25So there's nowhere to hide. So when I say developers, it's really this kind of intersection of programming and design and quality assurance and product ownership. And I think that sweet spot of all of that is really what the type of developer that I want to hire, the type of person I want to hire. And that's what I call a developer. It's someone who is taking ownership of what they're building, right? Is proud of what they're building. They want it to be the best that it can. They want it to work really well. They don't want it to be buggy, right? They want their code to be architecturally sound.

23:06And that's just because that's who they are. They participate in strategy. They participate, again, like I said, in testing. They interface with businesses. They get out and mix it up with customers. And our engineering team has gone out and worked different work opportunities on our platform just to feel what it's like to be someone on our platform. They've gone out to the businesses and really watched them use the product or see the environment that they have so that they can build better products. And so that's really the premise behind that. is not just someone that's just going to sling code or be on their computer compiling stuff.

23:42We're really creating things. And there's probably an element of creativity that I'm sort of alluding to and everything I'm saying too. Yeah, I think that's spot on. We talk to a lot of leaders on this show. I know you do on Code Story as well. And I think the best ones don't treat programming like it's something that can come off an assembly line. They treat it like it's a mix of an art and a science. because you need that creativity and you absolutely need these team dynamics we're talking about because an individual dev can solve a problem for a short term, but long term, you need a high-performing team.

24:18And I know that in your case, you employ a squad concept to help organize that. Can you explain the concept for the audience and how you're constructing them? Yeah, sure. So we started out sort of in a traditional manner when we first started Variable It was basically like a front-end team, a back-end team, and a mobile team, because that's the types of developers we needed to solve the problem or to build software we needed to solve the problem. Once we got to a point where our product was large enough, we really need to start thinking about, okay, we have multiple roadmaps coming into play. We have multiple, not conflicting, but fighting for resource type situations from roadmaps.

25:01And so we decided to go to the squad structure and we essentially have one engineering manager over a handful of, say a handful, our biggest squad is 10 to 11 individuals. And they are essentially the engineering team that owns a part of our product line. So for variable, we have our marketplaces, our businesses and operators, which are the workers, connect on work opportunities, bid on the work opportunities and complete and get paid. So that's one of our squads. It's essentially our marketplace product. Another one of our squads is our workforce management, which is kind of more of our hybrid, full-time marketplace integrated product that helps you to take in information in your system, calculate automatically what your labor needs are, and then figure out what your overage needs are essentially for the marketplace.

25:55And so these, essentially, we build it around our product lines. And the reason we do that is what I mentioned earlier with the platform getting big enough, but also because in the same vein of hiring developers over programmers, our squads are essentially subject matter experts for these product lines too. They're not just coders, right? They're not just slinging code. They know how it should work. They understand the requirements intimately to where they are building software to meet the needs of their users. And so that's a big part of the reason why we have broken into squads. We have other squads that are sort of backbone squads for our engineering teams, which are core platform and then core UI.

26:42Core platform is essentially our shared services team where they're building all the services that the other squads are consuming. More computer science heavy, more architecture heavy, a lot of orchestration, DevOps, things like that. And then core UI is more around the front ends and the standards around the front ends of for our design, for what sort of design frameworks we're using, how we're building the front end interfaces from mobile and from a front end standpoint. And that's where we sort of get our standards on both sides. But those squads are focused on those sorts of things. And my understanding is that you've experimented both with having product managers oversee squads and engineering managers oversee squads and have settled on engineering managers as the right choice.