The Surprising Truth About AI in Engineering

Full transcript

Servant leadership misunderstood

Welcome back to the podcast, guys. Today we are joined by Chris Dulajalek. Welcome to the podcast, Chris. So could you share a bit about your background and what you are currently doing in the day to day? Mhmm. And is there any mistake that you see engineering leaders make over and over again? Mhmm. Is there any specific is there any yes. Is there any specific approach that you use to keep the technical standards high without actually turning the organization into a process heavy organization? I'm not sure. Like, uh, you are cutting out a lot. I think it's due to the Wi Fi connection. I don't know how you are connected at your station, but do you think it will be maybe possible to okay. I'm here. Yeah. Because because you I feel like it's the same, actually. Like, when you were talking, I was hearing, like, every six words. So that you know? Do you sometimes Yeah. I know. Do you work sometimes, like, inside where you have, you know, Ethernet cable or something like that? Yeah. That would be amazing. I don't know where you are. Like, I thought you are in a park.

You are on the garden? Or oh. Oh, okay. Okay. Okay. Hello? Hello? Yes. I hear you. I don't I don't see you, but I hear you. Uh-huh. I I maybe. Not really. I see a blank screen. That's very interesting. Yeah. Like, I I can hear you much more clearly. It's just for some reason, I don't see you. Now I can see your logo, but it never switches into the camera when when you turn it on. Maybe perhaps if you could leave this channel and then join back. Do you still have the link? I couldn't I could okay. So let's let's try that. I think it might be because you switched networks, so there might be some kind of Okay. Yeah. Now it's now it's crisp. Sorry. For a while, it just wasn't opening up the link. Oh, no problem. No problem. Okay. Okay. So where I'm not sure where we where was the So we talked about we talked about the issue of engineering challenges versus product direction? We we don't probably need to do that again since I've heard every tenth word. So

Okay. So as I recall, you had asked me about, you know, how do I deal with the challenges after saying that sometimes building the best tech isn't the only way to go forward. And so my premise has always been that the most amount of time that engineering spends on anything is gaining context. If you wanna make a change, if you wanna add something new, you wanna fix a bug, first, you have to gain context. And so my idea is follow the product road map. When the request comes in, you have a backlog of fixes. When you open up the hood of that car and you're adding the fuel injection, change the oil and the air filter while you're there. That way, you don't have to gain context, but you're improving the code, and you're improving the code where it's actively changing. Right? And so that's how I try to marry both the combination of improving the technology and improving the functionality. How do you approach technical debt? When do you pay it down, or you ignore it?

AI isn't replacing engineering

No. Don't ignore it, but also don't just blindly pay it down. So for me, that is the thing is whenever something happens for technical debt, I always want us to enter a bug that not only says what is the issue, what needs to be cleaned up, but what area of the code is is needing the change. And then either when a bug shows up or a feature shows up in that area, that is the point in time to address the technical debt ideally. Of course, there are exceptions to that, like, if there's security issues or things like that. That's essentially like a security bug to me, then you have to change it. And then, again, if you're in the area fixing the security thing, if you can approve the code, then do that. I have sort of this saying, leave a trace. When you go to a park here, they always say, leave no trace. Take all your trash out. And for me, it's whenever you step in any code or any document, always leave it better. Well, that's great. What do you is there anything that you believed about leadership

that has changed over the time? Yes. In a way. So one of the big things, especially in Northern California where it's all, you know, kumbaya. We all love each other. It's touchy feely. There's this notion of servant leadership. Right? And I think servant leadership got taken a bit to an extreme, and most people that know me would not believe I would ever say that. But we had a engineering conference where a CTO got up and gave this talk, and she said, times are tough. Forget servant leadership. Engineers should just be happy if they have a job. Right? I was like, wow. Okay. That's an extreme. So I caught her as she was coming off the stage, and I said, I think I see servant leadership differently than you do. So she saw servant leadership as just do whatever the engineers want. If they want, you know, to do their own coding one day a week, let them do that. If they want chef food for the lunchtime, do that. If they need a gym access, give them that. And I said, no. That's being a servant. That's not being a leader.

To me, being a leader means you do things in service of your team, and that may be also challenging. Right? So instead of just always being nice to you, Mickey, the way to be kind would be to say, hey. You know, the way you wrote that code, you might wanna consider this. What do you think about this? Right? And so I challenge you, and I say not, hey. That was bad. That's not really the right thing to do. But I say, you know, in a kind way, I wanna help you grow. Or here's something you've never done before. Step into that. And so for me, servant leadership is this thing that somehow evolved into being nice, and we forgot the aspect of leadership, and it's about being kind. And so for me, that's a very big difference. You do wanna help your employees grow. If they're not motivated, then their engagement will be lower, especially in tough times. I think it's Mark Andreessen, or was it Horowitz wrote a book about the hard thing about hard times. And he said when you lay people off, you need to be thoughtful about how you treat them.

Leave no trace, leave better

Treat them humanely because the people that remain will look at that. And how much they are engaged versus looking for another job depends on how you treat the people you let go. Mhmm. And so I do believe there is a lot for leadership to be in support of your engineers, but it's not to be their service. So it's really giving feedback that can help the person be better than just, you know, saying that Yes. He is bad or he did this thing wrong. Exactly. When it comes to AI tools inside of engineering, are there any that you are using actively? Yeah. So mostly cursor lately, but I've also used other LLMs to write code. I had a little side project where I was using ChatGPT and Gemini that can generate Kotlin code for Android Studio. And but across all of them, it's basically very similar to if you use an LLM to generate text. The AIs are all very narrowly focused on the current context. And so if you have it create this beautiful piece of code or this beautiful document, and now you need to add something,

it gets so recency biased on the latest thing that it actually can destroy what was there before. So for me, you know, AI isn't replacing engineering. It's supporting engineering. And instead of removing the need for the engineers to be rigorous in systems design, I feel it actually increases the needs for engineers to be rigorous in systems design to keep AI with its agents, with its guardrails from not creating too much damage. I recently saw output of a study that said AI has created now in just one year enough tech debt that will create will be ten years of work for humans to clean up again. Right? So it's not a panacea that will solve all problems by any means, but if used in the right way, it can be very helpful. Chris, if you could design some kind of ideal operating model for a modern engineering organization, Are there any key elements that you would insist on? Operating model. Interesting. So there's organizational stuff. I think transparency is important. The engineers need to understand the customer and the product. There's the technology. Depending on what you're building, there's lots of different choices.

But a lot of things may scale more quickly than you want to, so using the cloud instead of your own infrastructure, I think, is very important. And then in terms of AI, I think it needs to be brought in thoughtfully so that the engineers are trained in how to take advantage of it, but not to make false assumptions that will lead to bad outcomes in the long run. Is that kinda what you're asking about? Covers it. What do you think of agentic AI? I think it's good. I think it's moving in the right direction. But, again, I think the danger is people assume that it's gonna solve all the problems. There's still a lot of issues. One of the things that I've noticed with AI, and I have this notion that AI has a human fingerprint. If you think about who programmed the AI and what the data was trained on, it's all human stuff. And when you interact with AI and you look more closely, it's actually trying to please you. And so sometimes it will rush to give you an answer instead of thoroughly thinking about it. Right?

And so even with AgenTic AI, I've seen issues there where you really need to be careful about how you set up the relationship and the guardrails to use it effectively. Are there any tips that you could give out to people that may be using cursor? So for me, it's really think about what does good engineering look like. Right? So I had another engine a different engineer write a whole bunch of code, and then I used Cursor. I said, hey. Let's do a code review on this. And it gave me a code review back, and then I said, no. You're being much too surface level. You're basically doing happy path testing. Does everything work the way it's supposed to under ideal conditions? I want you to look for how does it deal with network glitches, air conditions, timeouts, bad data coming in as though somebody was trying to be destructive. Jeff Bezos says, when you write software, you should assume that even if your own colleagues are gonna call the API, that they're gonna do so maliciously and attack it. Right? So then I told Cursor,

these are all the things that I want you to look for. You know? Error recovery, destructive testing, security issues, and the code review it came back with was much larger. It was huge. Right? But it was pretty harsh. And then I said, okay. Now reword that in a way that's kind. So go back and make it all, hey, engineer. I see what you're trying to do. That's a good area, but you may be overlooking this. So it kept all of the suggestions for corrections there, but it framed it as sort of educational. Mhmm. Right? And when I then offered that to the engineers, and I actually showed some of some of them all three instances, the surface level one where they said, yeah. That's silly. We know all of that. The deep one, they're like, wow. That's harsh. Right? I feel like an idiot. And then the kind one is like, wow. I learned a lot. Right? And it's all cursor, and I'm asking it to to review. But because I'm applying my understanding of systems engineering, but also how people work, I can change what it provides to the engineers. Mhmm.

You so you've written a lot of code. Right? What Yeah. Makes gold good or exceptional in your opinion? What makes gold exceptional? Well, for me, it's a lot in the systems design. Right? And thinking about where is this thing gonna go long term. I always like to have this time versus elevation. You need to think precisely what you're doing in a two week horizon. That's like the 10 foot elevation. But a year from now, you want the 16,000 foot elevation. You know where you're going. And if you don't know that, then you may be building this in a way that you're gonna have to keep rewriting it. Right? And so it's a combination of knowing exactly what you're doing in the current sprint, but also what it's solving for, and then thinking about how can you write it generically. And then for me, a very important aspect is really think about how you're testing. Right? If you can do destructive testing in such a way that if somebody else makes a change to your code, let's say you've moved on to something else, that the test will catch it,

then you won't get that call because they made a change to your code and the site went down overnight. Mhmm. Right? Well, great. Chris, could you give any advice to other people that may be listening? So for me, one of the main things, and it came a little bit out of Agile, is to try to do small increments and changes, and then you can see if that worked. Ideally, you have a hypothesis. If I change x, this will happen. You test that, and then you look back and you say, what did I learn? Did this work? Did it not? And then you apply that. And so as you go through the cycle, you get better and better and better. The other thing is this way you can change where the greatest need is at the moment. There's a notion of critical constraint. You need to fix the critical constraint, but even a tiny fix may move that constraint to a different place. So for me, there's a lot of value in these tight loops of know what you're doing, have a hypothesis, look back on what went well and what didn't, and then reassess.

K. What's the next thing, and how do I apply these learnings? Great. I will leave links so people can check you out on LinkedIn, and thank you for joining, Chris. Thanks, Mickey. Great talking to you.