With great power comes great responsibility. Now that you've been promoted to a people manager, how do you build a healthy and successful engineering team?
Extending our series on the career journey of engineering leader, co-host Conor Bronsdon is joined by Noah Labhart, co-founder & CTO at Veryable, and host of the popular podcast Code Story.
Conor and Noah shift the series' focus to the intricacies of building effective engineering teams. Beyond team building, the episode delves into the subtleties of offering and accepting feedback, the importance of hiring developers vs. programmers, and fostering an environment where each individual can flourish.
If you haven’t listened to the first two episodes of our leadership series featuring NuBank's Thiago Ghisi, you can find them on Dev Interrupted's new website.
Episode Highlights:
- (3:00) Hiring "career-changing" engineers
- (10:30) Fostering healthy team dynamics
- (15:00) How to know when to let someone go
- (21:00) "We hire developers, not programmers"
- (24:30) Squad based teams
- (31:00) Squad best practices
- (40:30) Giving & receiving constructive feedback
- (45:30) Noah's best advice for engineering leaders
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Hey everybody. We are back on Dev Interrupted. This is your cohost, Conor Bronsdon. And today I'm delighted to be joined by a fellow podcaster, Noah Labhart, co founder and CTO at Veryable. Noah, welcome to the show.
Noah Labhart: Thanks for having me. Super stoked to be here.
Conor Bronsdon: you might also know Noah as. The host of the podcast, CodeStory, which features loads of amazing tech leaders, such as our very own Dan Lines, 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 CodeStory, definitely check it out. I really enjoy your podcast and your email newsletter is great as well.
Noah Labhart: I appreciate that very much. It's a it's a labor of love as I'm sure but get to talk to some amazing leaders.
Conor Bronsdon: We're very glad you were able to join us on the show.
And it's something we resonate with because that's our favorite thing as well. It's talking to these incredible leaders and learning from them and challenging them on, on, 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.
You 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?
Noah Labhart: Yeah, sure. I think it's important to define what a career changing engineer is. And, in general, generally speaking, it's someone who, perhaps worked in a non tech or non programming environment prior to getting into a tech job, right?
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 Veryable 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 create a name for themselves. And then two, they have a perspective on the environment, from a user standpoint, right? They see the world not just from, the coding IDE, right? And then the. Command line, right? They see the world as the end users because they used to be one, right?
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 helps them create a well rounded product.
Conor Bronsdon: 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?
Noah Labhart: Sure. Great question.
So usually the most optimal way we try to set this sort of situation up right with career changing engineers is to have some senior talent on the team alongside them, right? And that doesn't mean that, 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. So I mentioned that, 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 to the water to drink important. In the early days of Veryable, that was me.
It was me and then a handful of essentially career changing engineers, and what was cool about But the early days of Veryable was that, we were figuring it all out together, and I was able to provide 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 learn as they go, but also a space for them to build something to put their name on.
And I think that is something that's critical, to give a person that type of opportunity that's career changing. They, again, like I said earlier, they just eat it up.
Conor Bronsdon: 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?
Noah Labhart: So 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 percent to 75 percent of actually 25 percent computer science. And then 75 percent career changing.
And that's not a hard, fast rule, but just 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 thrown everything, right?
We definitely believe in, throwing our individuals into the water and watching them swim, with, coaching from the side of the lake, right? But with the appropriate coaching and 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 that sort of thing.
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, 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. Again, 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 succession, this sort of, I don't like the word hierarchy, but ladder of succession where everybody's pouring into the next generation and it works out really well.
Conor Bronsdon: I would think 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, you've given an opportunity to stick around and continue to grow the organization and deliver the benefits of being, fully ramped and more senior.
Noah Labhart: Absolutely. 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. Yeah. From July and earlier, February, January, February timeframe of 2017. They're still working with us today. Some of my lead engineers and some of my senior management that were in those roles and they grew into the roles that they are in today.
Conor Bronsdon: 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, because 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
Noah Labhart: It's a great question. So there's two things in our interview process, especially, specifically for the senior side of things. One is the, the technical capabilities, right? We want to see that you're a senior, right? We want to see that you can do the things that you can architect a good solution that you can, that you know what you're doing, right?
The other part is we bring whiteboard session and it, Everybody's got their coding challenge. Everybody's got their like, 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. And they asked me, 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, how well they adapt to the change, but it's important to be able to solve the problem and be adaptive, but less about that and more of like... How do they work with the team? How do they ask questions to the team? How do they respect the other team members that are bringing questions to them or seem 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 Veryable engineer. Because that's a key part of our team dynamic.
Conor Bronsdon: What strategies are you employing after you bring in these folks that you think are good fit to continue to foster a culture of collaboration and communication that you clearly value on your engineering teams?
Noah Labhart: Yeah, absolutely. There's a couple of things that we do. One of them, one of them feels maybe a little bit less fostering, but more of a stamp in the ground.
It's 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, it could be, something small, but your name's going to be essentially in the, you're gonna have a commit with your name on it.
And so we do that. Past that, we give people, high autonomy here at Veryable. 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. 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. I'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.
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. Immediately. It's Hey, something's not working. 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 fold there.
Conor Bronsdon: 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 are beginning to, take these first steps of 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. And, it's, 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?
Noah Labhart: Yeah, that's a great question. And honestly, I was the guy in the early days that gave too long the rope, right? So I learned the hard way a little bit how we do it today. And it's not an exact science, 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. Like 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, but 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. And so we really shorten that leash and say, okay, for the next week, you're doing this very small project. We're going to give you this project. It's, it should be done in a week. Cause we 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 leashback, and more leashback. If they don't, we make the hard decision to have to cut ties.
Really, and again, I go back to that point no one wants to be in a job where they're not doing well, they're not performing to expectations. And it's a hard thing to do. 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 been hard, cause you want to hire people and you want them to succeed.
It's almost like you're kids, right? Like you hire someone, it's like your kids. And, when it doesn't work out it's a challenging conversation to be like, Hey this isn't working. We need to part ways.
Conor Bronsdon: You mentioned that you felt like earlier in your career, you had maybe made some of these mistakes where 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, not using names, but just when you think that happened and what you would do differently today?
Noah Labhart: Absolutely. Yeah. Early hires, I won't use names and timeframes cause we're a small team. But we'll call it, we'll say early hire. I definitely gave a longer leash, to an individual on our team and 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.
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 our, 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, they just need this one thing, they just need this one thing.
And after that was all exhausted, it's okay, we've got to move on. My, my business partner actually was a great coach for me during that timeframe. His name's Mike Kinder, gave me some great coaching on people and how to hold people accountable essentially. And I've carried that to through today, but that was a hard lesson to learn.
Conor Bronsdon: 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. We want... We 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 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 you need to shout at someone when something goes wrong. There's a way to do this. There's a million and one trainings out there talking about like, how to be good about accountability, how to do it the right way, how to, you know, coach folks. And I highly encourage you, 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 those stories. 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.
Noah Labhart: 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, 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, and 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.
Conor Bronsdon: Absolutely. Said, and I think it probably has a little bit to do with the statement that I've seen Veryable and yourself make about we hired developers, not programmers.
You're looking for folks who have not only some built in accountability, but this desire to be high achievers, and be part of a team.
Noah Labhart: That's right. No, that's exactly right. So the kind of premise behind that, there's a, an article and I'm going to botch the name. I know that the guy's name is Eric and I'm trying to remember the last name.
I'll have to, I'll have to look that up. But then that article talks about developers versus programmers. And early on in the days of Veryable, I internalized this sort of definition for myself. And it aligns with the idea of career changing or what the things that I said with career changing developers too, but.
Or Career Changing Engineers is that programmers, the way I view programmers is that they don't do anything but program. And they require a lot from the rest of the company to do their job. They require requirements, they require specs, they require other people to test their code. X, Y, Z, right?
In Veryable, really in a startup in general, but I can speak to my experience in Veryable, there's nowhere to hide. There's no basement. 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 going through the strategy of how we're going to move forward on a daily basis.
We're all one, one big happy family, right? so there's nowhere to hide. When I say developers, it's really this kind of... intersection of programming and design 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. Is someone who is Taking ownership of what they're building 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, and 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 we have 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, right?
We're really creating things. We're, and there, there's probably a, an element of creativity that I'm alluding to and everything I'm saying too.
Conor Bronsdon: Yeah, I think that's spot on. We talk to a lot of leaders on this show and I know you do on CodeStory as well. And I think the best ones don't treat programming like it's.
Something that could come off of 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.
And 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?
Noah Labhart: Yeah, sure. So we started out in a traditional manner when we first started Veryable, and 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 the 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, fighting for resource, type situations, from roadmaps. And so we decided to go to the squad structure and we essentially have one engineering manager over a handful of, I'll 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. So for Veryable, we have, our marketplaces to 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 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, And 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 backbone squads for our engineering teams, which are, core platform and then core ui. Core 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 a mobile and from a front end standpoint. And that's where we get our standards on both sides.
But those squads are focused on those sorts of things.
Conor Bronsdon: And my understanding is that you've experimented both with having product managers, overseas squads, and, engineering managers, overseas squads, and have settled on engineering managers as the right choice. Can you talk a bit about that decision and why you came to it?
Noah Labhart: It's a learning lesson for me, and I will boldly say it was a failed experiment, by me. I decided to add in a product management team, into the mix of our organization. Hired some great product managers. They were very smart people.
But what happened was that it ended up just being, someone getting in the middle of our strategy team and our engineering team. And creating additional work, creating additional, metrics to, to drive the process where we already had those things in place, in a different group, right?
The, what ended up happening was... Product management essentially would take a roadmap, put together a roadmap and then just dictate to the engineering team, as if they were a programming team, right? As if they were programmers, they, they weren't developers, right? They weren't owners and they weren't accountable to the success of the product.
That created a layer of bureaucracy that backfired. The engineering teams were unhappy because they felt like they didn't have buy in the whole roadmap process. What we call our platform team which is our strategy they essentially were doing product management, or at least strategy as far as their roadmap.
Without having to put together, KPIs and things of that nature. The stuff we'd already come to, which is... The value we were being, we were creating. And so it just interjected this sort of middle point that created more bureaucracy and more work. And so I had to make the hard decision.
to eliminate the product organization. And obviously that was hard for our team. It was hard for my ego, but it was ultimately the right decision. It's hard for those individuals too. We tried to do it in a way that was very, helpful for them to land on their feet. But since we have done that, our team has gone back to thriving.
it was the right decision.
Conor Bronsdon: That's a really interesting example and I think it speaks to the differences across engineering organizations. You very clearly have constructed your team with this growth mindset in mind, this, close to the bare metal of the product and what the customer is experiencing.
Very intentionally trying to set folks up to take this more architect approach as you put it. And that works great in your org. And, maybe another org would say, no, our product team is crucial for us because, we need help guiding this thing, or we just have so many stakeholders we need to manage.
So it's great to hear this example because, I think it's. Yeah, it's a failed experiment. And I know I'm that sounds like it hurt you and it was a challenging thing for those individuals, obviously But it's a really it really speaks to the customization needs to happen within each org we talked a lot about frameworks and approaches and I'm gonna ask you in a second about your approach to Operating squads and how you'd recommend others do it but I think if you take anything away from this interview with Noah is which is like These are concepts that you need to apply to your team and your team has a unique operating cadence and a unique approach and unique individuals that's not one size fits all.
That said, I do want to ask you about your approach for squads. If I, if you were going to give advice to another leader who said, Hey, maybe I want, I'm going to try the experiment of squads. what best practices would you share?
Noah Labhart: That's a great question. We do have a unique set up here at Veryable that, like I said, the product management team didn't work out, but the squad idea did what has really worked with it.
Has been this sort of idea that we're creating mini startups within our startup. Like the squads are almost their own sort of engines within the Veryable ecosystem where they have their own roadmaps or delivered by a platform team where they have say into Okay, hey, this is gonna take this long, or hey, this is a bad idea, and this is why, this architecturally doesn't fit in what we're doing.
So it's a collaborative, co ownership with our platform team. I would say that is a significant thing if someone is considering going to squads, is the ownership aspect. From the engineers, if you've hired people who are strategic thinkers and not just programmers, then they don't need to be.
told what to do. You almost need to ask them what should be done and listen to what they're saying. So I would say that's really important. The other part is, you have to have engineering managers who are able to manage people outside of their traditional craft. So a good example, Pooja Kalaskar was one of our, earliest hires.
She was our first Android engineer, and now she's one of our senior engineering managers and has been long standing pillar of the company. She is traditionally a mobile engineer coming from the Android world. Now she is leading designers, she has led front end, back end engineers. She's led Data Engineer.
She's done it all because she has grown into the ability to deliver on our roadmap and on our results that we're looking for rather than delivering from a team who are like minded or like skilled individuals, right? So I'd say that's another really important idea behind the squad structure, at least for us, is that the engineering manager has to be able to.
Think outside their traditional craft. I've done a lot of web development in the past, but when we started Veryable, I was actually an iOS engineer, a mobile engineer. I started my own agency called TouchTap. We were building mobile solutions, and primarily I was doing iOS development, so being able to step into this and lead back end engineers, front a Product standpoint, lead developers is super critical.
And that's what we tried to recreate with the squads. Essentially like here's Veryable in the early days. Here's a little startup family. That's what we're going to recreate here for this product line, because you're in it together, you're making decisions together, you're feeding off each other, you're creating team cohesion and squad cohesion, and that just delivers great results.
Conor Bronsdon: This brings up a really interesting point. You've scaled Veryable from just a couple of folks, just yourself and your co founder to now multiple platform teams, multiple squads. And this is something where I think a lot of leaders who are either going off to found their own company or simply advancing through their career, start to run into challenges is okay.
I'm juggling multiple projects and teams simultaneously. How do I manage these multiple teams? How do I prioritize manage my time? To ensure each team feels supported and heard or simply make sure I'm prioritizing the right way. What would be the advice you would give to leaders who are taking those first steps into becoming a leader of a team of teams?
Noah Labhart: That's a great question and it's hard. We'll just affirm that and everyone who's thinking about doing it or a part of it is hard. Leading a team of leaders, essentially, managing a team of managers who are managing the other teams sets you further apart from the end product, right? I think for us, what has worked is that going back to that original conversation around career changing engineers and growing people into the next generation of leaders.
When, in the early days, when it was just a few of us, I was identifying, key characteristics in people, either architectural leadership or people leadership. And starting to feed them opportunities for them to not only prove themselves that they could do these sorts of things, but also have them get excited about those sorts of things.
So growing these leaders, creating these opportunities for folks, and then slowly, but surely, Handing things off and letting them go. And that's incredibly difficult as a founder, right? Because it's your baby, right? It's your thing. You started this from the very beginning. It's very difficult to let it go.
But the more that you can do that, when you identify the right people and you. You train, grow, whatever words you want to put there, them into type of leader you need in your organization. You have to let them run and you have to trust them. So that's step one is grow the people and then give them the things, right?
The second is to be present for those individuals, Create goals for those individuals. Create, around results, yes, but also as the people, right? What do you want for yourself in this, Do you want to just be a manager? Great, awesome. Let's grow a bunch of cool management, skills in you, right?
Let's put you in scenarios where you have to think differently, where you have to, Think about these people as people, not as engineering a solution, right? And being present to coach through tough situations is really important. I'd say that's the second thing. You have to become a coach.
You really can't ever become a dictator, but in the early days you're this is how we're doing things. But you have to, for sure, stop being that sort of dictator and this is how you're doing things, to how do you think things should be done? You have to become a coach. You have to ask the right questions to get people into the right spot for the organization so they can run.
So that's the second thing is to become a really good coach. Some of the conversations I have with my engineering managers nowadays are some of the most challenging and fun conversations I have had in our business to date. Because I'm watching them experience things that I experienced firsthand and seeing them seeing the light bulb come on.
Oh, that's how I can lead this person. That's how I can influence this person or that's how I can inspire this person to create something to get excited about what they're doing. Yes, go do that. And then just support them along the process. But it's hard. It takes a lot of work. It takes a lot of People time takes a lot of conversation, a lot of coaching, but it's worth it.
Conor Bronsdon: Totally agree. And we've touched on feedback a couple times in this conversation, and I think it's worth noting how important of a skill it is not only to give positive and constructive and also critical feedback, but also to receive it.
And as a leader, I think, I see most incredible leaders I know Seek feedback. Desperately. They require it. They are always asking, Hey, how can I do better? How can I improve? And they're not afraid of being told you screwed this thing up. They see it as a learning opportunity.
Noah Labhart: That's right. Yeah. And it's interesting. I had a great example early on my career from a CIO at Alcon. His name is Matt von Wellstein. He called me into his office after he had given an announcement.
To all of the IT, organization at Alcon. And he was, we were talking about some stuff and he asked me, he said, what did you think about that presentation? Is there any feedback you have from anything? I'm, I'd been out of college for a few years. I was a individual contributor. I don't think I was even a senior at that time.
I was an individual contributor. And here's the CIO asking what did you think of this? somehow the Lord had blessed me with some courage at that point to give him the honest feedback. And I said, yeah, it was good. I feel like we understand what was going on, but I feel like when you said this, it felt a little disingenuous.
And, I think probably, I don't remember exactly, but I'm sure at that point, I was like that might be my career here. That might be it, but you know what he did? He goes, huh that's good feedback. Tell me more about that. And so he started asking more questions about it. And we had a great conversation.
And so when I look back at the way he responded to that, he was not like, how dare you? Or, I'm the CIO. You don't talk to me like that. He was really honestly interested in what I had observed. And I take that with me to this day, because I want to know if I'm giving off a vibe or if I'm doing something that is indirectly harming one of my teammates, one of my employees, or something in our products.
I want to know because I want to change it.
Conor Bronsdon: That's an incredible example. And it leads me to ask, how do you go about setting that same level of trust and desire for feedback within your organization?
Noah Labhart: I think there's a few things that pop to mind for that. One is to treat people like people.
To ask for feedback and genuinely want it. And act on that feedback. Whether it's something that, the acting on the feedback can be. That's a great idea. We're going to go do that. Or I see your point. I'm going to go change this thing. And actually acting on the feedback could be also just responding to be like, I see your point.
Here's why we're doing it this way though. And explaining why providing context. Exactly. Giving good points of that. But really, it just boils down to treating people like people and giving them the opportunity to talk and listening. And I think, So many of the successes at Veryable, I think, hinge on that.
That just people are people and they have ideas and you hire people to come do great things. And people who are going to do great things are going to have ideas and are going to have feedback, so you should listen to them.
Conor Bronsdon: What about when you have to give constructive feedback? How do you frame that or approach that with your team members?
Noah Labhart: That's a great question. I think this is critical. What 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,,,
Conor Bronsdon: That’s the best advice I was ever given with my wife is to treat all problems this way. It's us against the problem.
Noah Labhart: 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. 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 and we've agreed or you're, you've agreed and you've signed off on you want to get here.
And me as your, yes, manager, but also your boss your, mentor, your friend here, I want you to succeed. And I really think that this part here is not working. It's not right. And it has to be direct and it has to be clear. Also like it can't be beat around the bush and be like, but you're doing these things well, and this is good too.
Those should are, those should be implicit, or already said, actually is a better way to say it. Not just implicit, cause that's not saying the positive feedback. You should already be saying those things, but when you're having the hard conversation, it should be very clear what the problem is and what the actions are.
And you should approach it as if you're on the same team.
Conor Bronsdon: How do you level set for that with the right expectations and role definition so that people see that you're sharing that problem or that they have ownership of these problems that we're trying to solve and that maybe you're giving them constructive feedback on?
Noah Labhart: Really, it comes down to conversationally expecting I expect you to deliver X, your job is to deliver it.
X and X could be, this feature, right? We'll call it feature X, right? I'm not going to tell you how to deliver feature X, right? But I need you to deliver feature X in a way that is, sustainable for the future, hits our deadlines to the most part, we all have fluctuations and deadlines and things of that nature, but provides ultimate value to what we're trying to do as a business.
And if you hire the right people in the beginning, which is not always, it's not an exact science, it's a very hard thing to do, but if the right people are going to take that and they're going to treat it like their own personal goal, and they're going to, They're going to try to hit it. So in, in saying like, how do we manage those expectations?
One is that, right? This is the joint shared goal. The other thing though is regular conversation, right? I don't give someone a project or one of my engineering managers an objective. And then say, I'll see you in six months when you deliver that. I expect them, and I expect myself, to stay connected.
And, we do this, in really good ways some way, and then, in other ways, areas that we can improve. But this was our plan. This is how we are tracking to that plan. these are the things that are working. These are the things that are not working. These are the blockers we have, or we need your help, Noah.
And I expect them to communicate that on a regular basis. And I expect. them to hold me accountable to removing those blockers, to clarifying expectations where they may seem unclear, and then for us to be in lockstep throughout that process until we deliver. So regular communication, autonomous project assignment.
But in designing those sort of projects, there's also understanding of where people are and the whole bumpers on the bowling alley thing that I mentioned earlier, where giving someone the the ability to succeed.
Conor Bronsdon: Noah, I've really enjoyed this conversation. I appreciate you bringing not only examples of your successes, but your mistakes and how you've learned from them.
And I can see how you've leveraged both all the incredible conversations you're having on CodeStory to learn from other leaders and also learning from your own experiences and your challenges as a founder and engineering leader. Before we go, is there one piece of advice that you could tell an engineering leader about how to set up a great team
Noah Labhart: That's a great question. I think the biggest thing I would say is to treat people like people, treat your engineers, your engineering managers to grow a team. You treat them like you value them. And not like you value them, just actually value them, actually care about their wellbeing. To illustrate that a little bit, is the example I have around career planning.
I tell all my engineers and engineering managers, if you want to go be an astronaut at NASA, great. Let me tell you what I can give you here that will get you to the point where you're going to be an astronaut at NASA. I can give you this skill, I can give you this opportunity, this thing. Because I care about your well being.
I care about the fact that you want to be an astronaut at NASA. Not, I don't want to try to keep you here at Veryable for 27 years and have you be miserable, right? But I'm getting this one thing out of you, right? So I think caring about people as people and what they want goes a really long way in creating a win situation for a team.
Conor Bronsdon: Well said. Noah, thanks so much for joining us. It's been an absolute pleasure. I want to make sure our audience has an opportunity to follow your work and stay in touch with you. What's the best place for them to find you? And how can they learn more about what you're up to with both Codestory and Veryable?
Noah Labhart: Sure, I appreciate it. Really enjoyed the conversation. As far as Codestory, you can check us out at codestory.co that's the main website. You can also check out the podcast on any podcast catcher out there. For me personally, you can check me out on LinkedIn. That's my most active and only social network, actually.
And then as far as if you want to learn about me a little bit more personally, I have a personal website, noahlabhart.com. Points you to all these places that I've already mentioned.
Conor Bronsdon: Perfect. Noah, thank you so much for coming on the show and sharing your insights. And if you're a listener who also wants to get engineering insights, just like what Noah shared with us, make sure you're signed up for our Dev Interrupted Substack for weekly insights on Tuesdays from all the best engineering leadership content across the internet and our Thursday deep dives.
I'm going to try to get Noah to write one for us sometime because I think it'd be fantastic. And if you found this episode valuable, share with your network. and thanks for listening, everyone. We'll see you next week. Thanks, Conor.