Nick Humrich: Unlocking Team Productivity - Balancing Metrics and Culture

This transcription is AI-generated and may contain errors or inaccuracies.

Matt

My name is Matt and I will be talking with Nick Humrich about AI's role in software development and how AI impacts coding speed, team productivity and potential risks. Hey Nick, I'm really happy to have you here. And without any further ado, I really like to jump into the questions. During our recent talk, we were talking a lot about the developer experience and the productivity. For me, I'm always interested about, you know, how do you measure the developer experience, how do you measure the productivity, how do you like, what are the best practices that works for you to help you out to increase those? Maybe you could elaborate on those.

Nick Humrich

Yeah, so I think the first, the first place I reach for is the DORA metrics, which are the four metrics listed out in the Accelerate book. They're definitely not the end all, be all, but they give you a really good baseline.

Are you deploying frequently? Do you have a lot of errors? Can you recover those errors fast? And what's your overall lead time? And those are good things to look at that I think give you a really good idea of at least if you're in the ballpark or not. But then also you definitely need qualitative things as well. So I love sending out surveys, trying to get a rough gauge on where do developers feel, where is the friction?

It really boils down to we as humans hate friction and developers love to be productive and so they will naturally tell you what is slightly slowing them down right as you ask them those types of things. And so I really love, I really love sending out surveys, getting qualitative metrics, kind of figuring out where is the team, what are they getting stuck on and those types of things.

Matt

Was there anything that you have tried out and it didn't work for you or for your team?

Nick Humrich

I think the one problem that I've ran into is focusing on only one or two things and I think it does work for a short period of time, but if you just focus on one or two things, then everything starts to almost overcorrect for those two things only. I think it can work as long as you pivot at the right point to introducing more things like refocus on something else once it's in the ballpark, rather than getting overly fixated on one thing. I know one time I was on a team and we overly fixated on number of deploys per developer per day and it, it got to the point where developers were intentionally breaking up their commits into pieces that were probably way too small, which was weird. It was weird to be on that side of the spectrum. But it was almost like, oh, I'll write the function and then I'll do another commit that calls the function and then I'll do another commit that adds the types to the function.

And it's just. Yeah. So over committing to one particular thing without focusing on the whole, I feel like is where the most pains might come from.

Matt

Well, it, it's like don't hate the player, hate the game. It's like when he set the the one to achieve. Everybody will fight the system to kind of find a way, right?

Nick Humrich

Absolutely. People will do what they're, what they feel they're measured to do. And there's no way around that.

Matt

And currently you're working at Landio and by the head, you had the experience with various organizations and I'm wondering always about the company's culture, organization culture, and the way that the companies are doing the products. So in your case, like, what do you think it's unique about working at Lendio, compared previous organizations?

Nick Humrich

I think for me the biggest thing about working at Lendio that's different is how different the financial aspect of the company is. Meaning we operate a lot like a SaaS company who provides software. And we are in a lot of ways a SaaS company that provides software. But we do not get paid in a normal monthly recurring revenue. Instead we get paid as loans are given out. And so it changes the financial targets to no longer be about just recurring revenue streams, but also about daily or weekly amounts of loans going through our system, which is a very different dynamic. It adds a whole nother level of balancing the short term with the long term.

And that's a pretty unique culture for me at least because I've historically mostly been at SaaS companies where long term revenue is almost the only goal. And now we have a lot of focuses on monthly or weekly targets because our financial just comes differently. And it's, it's kind of crazy to think that that small of a difference, which is how you collect money, dramatically changes the culture.

Matt

I really like to talk about the trends and the question that I wanted to ask you from like the engineering perspective. I read the article, I think recently there is this fight between the monolith and microservices. The microservices, they were so popular for quite a while and so trendy, but now the people are saying like hey, monolith, it's not so bad. So I'm just wondering like what is your take on those?

Nick Humrich

I think the, the quick version is different things work for different organizations at different Stages and the long version is I feel like our industry in general has a problem of over committing to trendy things that probably don't work. And I'm actually going to share, I'm not going to talk about microservices or monoliths for a second. I'll get back to it. But I'm actually going to flip the narrative on single page applications and front end frameworks and and we can watch the industry as everything was server rendered, move to client side, everything with single page applications. And now we're moving back to server side and people are saying, well, server side is better. Well, if it was better, then why did we ever move to client side in the first place? And really the answer is there are certain types of applications that work better as single page client applications and other sites that work better as server applications.

And as this new technology that allowed client side applications to be better arose, all the people who adopted that technology, they touted about how amazing it was because it was for them, they were doing the right thing, they were using the right technology. And then everyone else kind of jumps on and says, well if this is great, let's try it out, right? Without thinking does it work for me? And I think microservices and monoliths are very similar of you have these amazing aspects of microservices to allow autonomy and team culture and individuality upon teams that organizations, as they scale, as they grow, they realize this is the only way to scale my organization. And then you have these smaller teams who don't understand why microservices are being used. And so they throw it in. And without understanding the deeper why, you architect it wrong because you're not making the right choices, you're not splitting it up in the right places.

And that just hurts when you do it wrong. And it's going to hurt you also because you don't know what you're trying to achieve. And microservices are probably the worst like technical thing you can possibly do because it just introduces latency and barriers to your code. But microservices are not a technical concern, they're an organizational concern. And so people who go to them without thinking about it holistically, organizationally, we'll say why did we ever do this? This was dumb. Let's go back to monoliths.

And monoliths are great. Like technically they are far faster, they're easier to comprehend, they deploy like you have to write less tooling. But it has organizational problems later on as you scale. And so if you haven't gotten there, you're going to think it's great.

Matt

Speaking of the trends, the AI thing so recently when we talk you were pretty contrarian. You had a contrarian view on the AI. There's a lot of talks I feel within like a high level C level leadership, like the AI, it's the future and like we don't need so many people and so on. I'm quite skeptic about it, but now that I only hear such a narration. But when I talk with like technical leaders, they have a bit more pessimistic view than the C level of the organization. But like what are your thoughts here?

Nick Humrich

Yeah, I think the AI is being considered incorrectly. What I mean by that is a lot of people are looking at AI as if it's a replacement for people and I think it's more of an augmentation for people. The biggest thing that I want to mention is there was actually a study done by the company DX that does developer experience tooling and they actually found that companies that used AI for programming actually found it made productivity worse, not better. And what's interesting here is that individual productivity is absolutely higher with AI, but individual productivity is not what companies care about. They come care about overall productivity. And we did earlier talk about Dora being like kind of the metrics that help you determine how productive your team is. And one of them is lead time and like time to recover.

And the interesting thing about AI is because AI can write code so fast, fast it actually makes commits larger and harder to understand. So you're more likely to have errors when you deploy and it's going to take you longer to figure out what caused the problem in production. So it's actually potentially hurting overall throughput. Even though individual like coding tasks are faster, it's hurting the tail end of deploying safely because it's harder for us to understand. And the more AI has been used to do things, the more we've found problems with it. There's recently been trends of companies trying to go all in on AI programming, not hiring any developers and they build these big companies, they get these large valuations and and now that they have a real user base, they find they have a ton of security vulnerabilities, design like insecure design like they can't just patch them, they have to rewrite everything to fix these types of vulnerabilities. So I think where AI is going to replace developers is specifically the developers who are task based and not product based.

What I mean by that is if you are a developer who gets a ticket. You do exactly what's on the ticket and then you commit. And that is your life cycle. You don't care about the product. You're not involved in the product. You're not involved in the creating the tickets or the user stories or the design. You will probably be replaced by AI because that's how AI is being used. But still. Probably. I'm still skeptical.

Like you said, these technical leaders are skeptical. And I think it's because once you understand enough about the technical, you can see how much the AI is missing, how much it's not doing.

Matt

And looking ahead to 2025, 2026, are there any tools or any trends that you are following and you're excited about?

Nick Humrich

Yeah. In terms of AI? Yeah. Yeah, I, I would say Claude just released code, which is really interesting. This whole, this whole series of like agentic AI programming is kind of a bigger shift. So we have cursor and then Jetbrains is really seen Juni and then Claude has code. And they're definitely better than the previous iteration of LLMs.

It can grab more context, it can do more things. Yeah, but again, the, the interesting thing here is as programming becomes cheaper, it actually makes programmers more important, not less important. It allows us to do more with our tools. Like I was saying earlier about augmentation, as developers learn to augment themselves with these AI tools, they will actually become more important and more useful because they can do more with less, essentially. And similar to energy prices have been going down over time.

They've never gone well. They temporarily go up, but over time they always go down. And as the world, we just use more and more energy. And power plants are even more important, even though energy is cheaper and easier to produce. So as Claude and Juni and all these agentic programs come out, I think that's a huge opportunity for developers to make a larger impact if they learn to adopt these tools for themselves.

Matt

And what is like, speaking of like the microeconomics and economics, I'm just always wondering, like, what is the view in the US like when you talk with your friends, with other leaders in tech, are you guys more positive about 2025, 2026 or pessimistic? Because last two years they were pretty, pretty tough, I think, you know, there were a lot of layoffs. And I'm just wondering, like, how do you see these? Do you hear any, you know, gossips or opinions?

Nick Humrich

Yeah, I don't know if I want to speak on behalf of the entire US but I feel like it's pretty, it feels Pretty pessimistic. I feel like as more people there's a lot of fear, uncertainty and doubt around AI and what that's going to mean. And in theory that could be good for the economy. But what people actually care about is their jobs, getting paid, having living, being able to afford life. And it is not clear how AI actually helps the everyday person, only how it helps companies. And for that reason I think there's a lot of pessimism around being employable and what it's going to look like regardless of whether or not the economy is good. The economy for me might not be good and that feels like the overall sentiment.

Also housing, housing has been crazy and it's not in a great spot right now in the US for a lot of, well, mainly for interest rate reasons, but also because the whole Covid remote situation caused this massive change in how on where like the homes are located in pricing and it's kind of just raised prices everywhere. And so all these things together is just. I feel like it's overly pessimistic in the US right now or maybe it's just unsure. Just like we don't know what's going to happen but it doesn't feel positive.

Matt

The same, the same in Europe. But I, I would say like yesterday I had a really interesting conversation with one consultant from the product management area and like from, from tech and he's in San Francisco for I would say like 15 years maybe. And he mentioned that with the AI for the first time he's seeing like this new kind of gold rush, like the positive emotions and there's a lot of startups growing around the ecosystem. So he have, he hasn't seen that for many, many years. Like maybe not many years, but you know, at least five, six years. So maybe this will spread out. But yeah, let's get back to the, to the engineering a bit.

I'm always like the examples of the controversial engineering decisions and like the decision making. So maybe can you share an example of a controversial engineering decision you have been a part of? And you know, how have you handled the pushback? Like what was the outcome of it?

Nick Humrich

One controversial decision was at a place we decided to get rid of the pull request and the code review. It feels pretty industry standard right now to review code and have pull requests and it feels safer to have that process. And it's really interesting to watch people kind of fight what they're used to even if it makes them like have less friction. Right. I was talking earlier about how I tried to remove friction and that Was one of the ways we tried to do it is if code reviews are becoming a friction point, let's just get rid of them altogether and people can just ship code. And we tried to listen to everyone's concerns. And I think the best way to fight pushback is just listen to everybody, make time for everybody to make their voices heard, but also understand the problem deeply yourself.

Like, why are we making this change? What are we doing? Another one was I was an early adopter of the trunk based development or master based development kind of workflow back when Git flow was more industry adopted as the the standard way of working. And there was a lot of people who thought it was too problematic, would introduce too many problems. And in a lot of ways with that one, really the only way to address the concerns is you just need to try it. Like I'm not going to convince you that this is better because on paper it actually doesn't sound better. It doesn't sound as safe.

It doesn't sound like it's going to decrease work. It sounds like it will increase work because you look at the edge cases and they look not great, not ideal. But I had to encourage them, just try it for a month. We'll have this conversation again in one month from now, after you've tried it out. Let's talk about the problems you had, see if we can address those. And mostly for that one, it was mostly resolved. There was a couple people who didn't like it, but the rest of the the organization thought it was a good decision.

So we moved on. And so I think a lot of that pushback is listening to concerns but also giving room for people to try new things. Because we as humans in general, we just don't like new things. It feels painful. And it also makes you question a leader when they go against status quo a lot. Because status quo is usually there for a good reason. And if you don't understand those reasons, it can be hard.

It can be hard to follow someone who's trying to mix everything up.

Matt

At the last but not least, I'm just always wondering if you could give me some recommendation or Our Listener is a recommendation. Any books or blogs that you really like to read or have been really influential in the past on the way how you approach the engineering.

Nick Humrich

Yeah, I would say there's a couple books I would recommend. The first is Peopleware. It's a really old book from the 80s and it is still incredibly relevant. It's crazy how relevant that book still is. And then Accelerate, which I mentioned before is a really good one to know about and think about. I also really like Drive, which is nothing about engineering, but very much about people in general and what motivates them. And I think it's so important as we talk about engineering and how to make engineers more effective.

It was a lot about motivation. Who is the human and how do we unlock that human to be better?

Because they want to be better. Right. And so those are probably the top three books that I that I would recommend.

Matt

Nick, thank you so much for the whole talk. The people were. I haven't heard this book about this book, so I'll definitely check it out. And thanks for all the learnings and lessons that you shared with us today.

Nick Humrich

Thank you. You bet.

Matt

Thanks for having me follow Matt and Leshek on LinkedIn.

‍