#492 Building Human-First Products in the Age of AI: Eric Müller on Security, Trust, and Leadership

[00:00:00] 

Mehmet Gonullu: Hello and welcome back to an episode of the CTO Show with Mehmet today. I'm very pleased. Joining me, Eric Müller. Eric is Product Engineering Associate Director at Work & co. Eric, thank you very much for making it here today. [00:01:00] It's an honor to have you as a guest on the show. The way I love to do it is I keep it to my guests to give us a little bit more about their journey, their background, and what they're currently up to.

So the floor is your setting. 

Eric: Oh, thank you. Uh, well, thank you for having me. Um, gosh, I don't know often think about my journey. Um. Uh, so basically how I got here, um, I was definitely very much into computers as a kid. Um, you know, gen X, uh, so kind of a, when I was a kid it definitely wasn't a thing that was kind of cool.

Most people didn't play around with computers, so started playing around, uh, with them. When my father, uh, brought home a, a pc, he kind of built it himself, uh, for my mom's. Uh. Schoolwork. Uh, so started playing around with that. Um, kind of floated around a little bit in college. Wasn't quite sure what I wanted to do, so I was kind of, um, jumping between architecture, photography and computer science.

Um, and I kind of feel like all [00:02:00] three of those, uh, really kind of played into my career. Um, started doing technology work at, uh, Wells Fargo Bank, uh, working on some kind of, um. Uh, proprietary systems, uh, company at the time called Culver was making some software that was basically only used by two banks, uh, Wells Fargo and Bank of America.

They were the biggest, uh, uh, users of that software. And so I was working on some of the, uh, uh, Keller Systems for Wells Fargo Bank. Uh, ended up getting into the web, um, right around that time. So this was in the early nineties. Started, uh, floating around, uh, did some contract work. Uh, ended up with, uh, Charles Schwab.

Then, uh, got into the agency world. Uh, worked at Razorfish for a while, uh, was doing architecture at that point. Um, the creativity, uh, you know, from my photography studies really helped as well working for that kind of front end focus company. Ended up at, um, Edelman for a little [00:03:00] bit. Uh, started getting deeper and deeper into, uh, computer security at that point.

Uh, then, uh, went to a company called Presence. Uh, I was there for about a decade. Uh, was the CISO there? Uh, pushed our, uh, SOC two initiatives, started working on, uh, security for our clients. Um, and then we were acquired by, uh, working Co about three years ago. Uh, and I, uh, continue doing the same thing, um, helping, uh, push forward some of our security initiatives here, and, uh, consulting for some of our clients, making sure that they're in a, a really good shape, security wise.

Mehmet Gonullu: Great. Um, you know, what an awesome journey, I would call it Eric, um, you know, across, uh, you know, multiple, uh, companies and, you know, great of, uh, you know, exposure, uh, for, for different technologies also as well. Um, so if I want to ask a little bit more about, you know, product engineering, right? So, so [00:04:00] today.

Also, I'm seeing a lot of shift, right? So, uh, AI is, is everywhere. And, uh, you know, whether you are, uh, or you know, big organization, maybe especially agency. Um, so there is a lot of, I would say, um, reliance now on ai. So how are you seeing this AI adoption, uh, with the current generative AI wave? Uh, 

Eric: it's, that's complex and, uh, I always have a, I think a.

A different approach. So I, I kind of feel the problem I'm having with the AI space right now is there's really kind of two main camps. So there's kind of the AI hype train, which is, you know, AI can do everything. Like, let's vibe, code, let's, you know, give everything to the AI system and cross our fingers, hope for the best and it will just be wonderful and we'll build our next unicorn with that.

And then I kind of feel like there's a group that's obviously the AI doomers [00:05:00] where, um. And not in the, when I say AI doomers, not in the sense of, you know, AI will become sensing and kill us all, but more in the sense of like, AI has no value in this, uh, field. What we do, you know, we don't need it. Um, I, I kind of feel like there's a middle ground kind of some nuance.

So I think, um. AI tools, uh, particularly generative AI for developers can be a very valuable and powerful tool to support a development team. Uh, I think it is not a replacement for developers. Uh, I think going down that path introduces some significant. Problems for the future, uh, for any product. Um, at the same time, I think ignoring that, you know, the AI tools, um, you know, is kind of problematic.

I think they are very powerful in helping, um, with some qa. I think they're great with writing boilerplate. I. Um, I think they can be, [00:06:00] uh, very useful and very simple, um, you know, coding, uh, situations so that they become an accelerator for development team as opposed to a replacement of a development team.

Mehmet Gonullu: So Eric, where do you see then the, because you mentioned about, you know, I like the bold way you, you put this out, but where do you see the sweet spot? So where is. AI is too much of ai and whereas like keep doing the things the way we used to do is staying behind. How, how, how do you find this sweet spot?

Eric: So I, you know, I was listening to another podcast and someone put this really well, and I, I, I've always kind of maintained this even before ai. I think that you have to have your development team own the special sauce of your company. So I think that you, um, you know, think of like before we had AI tools, we would outsource some of our work to third party vendors.

Um, or we might take [00:07:00] some of our, uh, core functionality and outsource it to, uh, a platform. Right? Um, so maybe. Uh, think of AI tools in the same way. Um, you know, are you building some baseline marketing website, you know, to support your overall business? You could probably lean heavily into AI for that, but if there is something about your business that's core to your business, that's unique to your business, you need to have human eyes on that.

Even in that case, you can't have the, uh, support you, right? You know, there's gonna be a lot of boiler plate code at that point. So go ahead and leverage that. But the actual stuff that makes your business unique, that's core to your business, you wanna make sure that that stuff is solid, that you can, that you're putting your business behind that, that you're not gonna be worried about security risks, um, that you're not using code that's kind of throwaway.

Um, that's the stuff that you don't want AI doing. That's the stuff you want human beings doing. 

Mehmet Gonullu: You mentioned security, Eric, and this is actually [00:08:00] the, you know, the, the, the one of the topics that, uh, we wanted to, to discuss with you today. Mm-hmm. So, and you, you've done it, you know, you helped, uh, uh, teams, you know, get their digital security in a, you know, good shape.

I would say now. Coming also from similar background myself, and this is, I think the first thing they teach us, you know, when, when we start to learn about cybersecurity is so the more the security is tied, you know, the more you know things might look inconvenience. Now with this. Advancement, whether in AI or in the digital space in general, how are you finding, you know, this balance between keeping innovations, keeping, you know, the people want to, to, right, like, let's say, um, solve real problems fast, but at the same time.

We know, like doing things [00:09:00] fast sometimes can break things, but we don't want to break the, the security aspect of it. So what, what kind of balance have you seen working? Um, in, in, in, in that space In general or with 

Eric: ai? Or both? Both. Both. Uh, I, you know, um, AI is harder, I mean, to be honest, right. Um, I think, I think though the.

We still have the same general principles, right? So, um, I, I think you're kind of touching on something important, which is there's always this tension between, uh, perfect security and something that's usable for end users, right? Um, and every time you introduce some security into your process, either you know, for the front end where the users are interacting with it, or all the way back where the developers are actually writing the code, you're introducing friction.

And that's, um, you introduced enough friction into that process or into the application, um, you're going to start to make it harder for your [00:10:00] users to interact with your system. You're gonna make it harder for your developers to move forward. So I think there are some kind of core principles that you wanna stick to.

Um, you know, you wanna be very careful about, um, you know, sharing secrets, you know, putting stuff, you know, baking stuff into your systems that are, that are, um, you know. Like, uh, I don't know, like the classic is like, uh, SQL injection vulnerabilities, right? You wanna make sure that you're not doing things like that, those baseline things.

And you wanna be thinking about security from the beginning. Um, you know, you can't, uh, you can't go into an application, build it out. You know, you're three weeks from launch and you're finally doing your first security review. You're not gonna be able to launch, right? Because you're gonna find all sorts of security vulnerabilities and you're gonna have to go back.

It's gonna cost you a lot more money to fix them. Fix those items then, as opposed to when you started from the beginning, thinking about security. Um, I think security for AI is a little bit more challenging, right? [00:11:00] So I. If we think of everyone right now, when they think of ai, they're thinking of LLMs, generative, uh, right?

And so you have to start thinking from the beginning, what are the things that we're putting into our LLM? What are we training it on? Is this data that we think, um. Is, uh, you know, valid and recent. You know, is it, does it make sense for you to train your LLM on data for your company that, you know, the, the data's 10 years old, 15 years old, 20 years old?

How relevant is it? Um, when your system generates something, uh, you know, a response to a user? Is the response gonna be relevant because the training data is valid or in, are we, uh. Being thoughtful about, um, the kind of information that we're dumping into that LLM, you know, that, uh, is it in, um, potentially, um, proprietary or could it potentially reveal personal information or other secrets that we don't want in that, that generative space?

So we gotta be. [00:12:00] Careful about that. Um, are we looking at the results properly from an LLM? And this is particularly important with developers, right? Um, is that code that's being generated, is it secure? Um, you know, uh, a big thing that people are talking about right now is, um, I love the term slot, uh, slop jacking.

So you know where your LLM. Um, decides that it's going to generate a package, uh, links to a package, or include a package that does not exist. Right? Um, and, uh, so if someone knows that, you know, there, there's been some studies that show that, you know, the LLM will generate a invalid package. Someone goes, goes ahead, goes out to uh, MPM.

Creates that package. Uh, so that next time, uh, the LLM calls for it, the package exists, it pulls down the code, and now you have a vulnerability, you know, in your environment. Um, so, you know, looking, looking for things like that's really important and I think that [00:13:00] people trust LLMs too much because of that.

What is generated, they trust too much. Um, and we need to. You know, have humans look at that stuff. We need to validate the work. Uh, we need to do some static analysis, dynamic analysis, making sure the code is good, and then kind of go from, go into production from there. 

Mehmet Gonullu: Right? So about trusting LLMs, I think we've been trusting also search engine results for years.

So, uh, it's, I think, you know, let's say my humble opinion, like we like to kind of take shortcuts sometimes and. You know, myself included, I did this mistake at the beginning and everything like. Chad, GPT was throwing at me. I was like taking it. And then, you know, I start to figure out, no, hold on one second.

Like, and there's some stuff which is, you know, not right here and this, and then we start to see, uh, there is the retrieval, augmented, uh, you know, the rag, uh, you know, for regenerative AI and all this. So this is a very [00:14:00] valid point. But from business perspective, Eric, and you know, you, you've, you've been also a, a, a CISO yourself now from.

Non-technical, uh, leadership perspective. How are you seeing, you know, the board are able to grasp, you know, all this together, you know, between the push for innovation and, you know, keeping I. Of course, data privacy, data security, data availability, which is like, you know, the, the, the main course of, of, uh, uh, safeguarding any organization.

So, and the reason I'm asking you this, because when I interviewed a lot of CISOs, like years ago, and still I talked to some of them, so the challenge was there explaining to business. But what I'm hearing now is that there's. Like double, I would say challenge because from one point they need also to make the awareness about what you just [00:15:00] mentioned.

So in a nutshell, what I want to hear from you is. And maybe this is advice for fellow people also as well who are in the same, uh, position. What have you seen working, talking to non-technical, uh, folks about, you know, the digital security, especially with, you know, the rise of LLMs and Gen ai? Oh, I'm, 

Eric: uh, I'm very unique in that, um, when I talk to people, they're already very interested.

Um, and so it's, it's an easier sell, right? Um. You know, I think, I guess the advice I would give to other folks, uh, and what I've seen kind of work for me, even in the times where people, obviously they're approaching me, you know, I'm a consultant, they wanna hear from me. So that's a, that's a great starting point, right?

And then I'm very thoughtful about the things that I talk about. You can't. You have to kind of start with the assumption that, uh, your client is interested in the security. [00:16:00] Um, and so approaching them and trying to avoid getting heavily into technical language, right? So if you make the conversation too technical, eyes glaze over and you lose them.

Um, and so I start thinking about how can we make this real, right? Um, and so one of the things I used to do, uh, when I was working with, uh, smaller clients. Uh, and they would ask me, you know, Hey, uh, we want to, you know, we're looking at a security initiative, or we're trying to build something out, and I, I might see a, a problem that I wanna kind of, um, you know, help them through.

Um, and they would sort of start to push back, you know, Hey, maybe we don't have the time for this. We don't have the money for this. Um, I would start to, uh, look at the scenario, kind of some. A little threat modeling, if you will, and think about if this scenario came to fruition, how would it impact their business?

Right. I would try to make it real and I would try to look at, you know, uh, a realistic scenario. I wouldn't, um, you know, [00:17:00] worry about, um, you know, try to come up with some pie in the sky thing that they would kind of roll their eyes at. I would try to think about, hey, you know, um, if people hijack, um, I don't know, uh.

Here's a really bad example, but very simple. Hey, you know, I know it's easier for you to, uh, keep that secret. You know, your AWS key inside of GitHub, right? Or you think your GitHub account is all nice and private, but if for whatever reason that gets out into the public, um, your AWS account's gonna be compromised, uh, they'll be able to get at your databases.

Um, all of that information in there is gonna be public and your business is gone. Right. That's not a hard scenario to think through. Right. And so I think being able to provide a realistic scenario, a cost that uh, they can understand, and then finally give them a solution, Hey, you know, pulling that secret out of GitHub and putting it into, I.

Uh, secrets Manager in AWS [00:18:00] Sure. That might add, you know, an extra 15 minutes, you know, just to, I know that's, this is an extreme example, but might add an extra 15 minutes, but that 15 minutes of time and the additional work that you might have to do every time you rotate that secret, um, is going to save you potentially millions of dollars, potentially save your business.

You know, that's the trade off. Give them the trade off, help them understand the, the downside, help them understand the the positive. Help them understand what the effort looks like, and it's easier to get them on board with it. 

Mehmet Gonullu: Makes completely sense. This is great, great, great, uh, advice I would say, Eric.

Um, now just I want to shift a little bit gears and, you know, talk about, uh, you know, collaboration a little bit and mm-hmm. Like, you've worked on both sides, like inside agencies and with global brands. Um, what do you think. Is something truly proactive for a client [00:19:00] engineering collaboration? 

Eric: Uh, I have, I have two kind of cliches that I always have.

So one of them is, um, we really need to understand their business and that's kind of straightforward. Um, and I think that's important because, um. I've had engineering teams where folks feel like we have to get the engineering absolutely perfect. And I say to my team, you know, you need to understand that.

Like, um, sure, we want in, in the abstract. It would be great if, you know, uh, everything was, you know, abstracted out and, and uh, you know, we had all this great code and, and um, you know. I went through all these reviews and it's just absolutely perfect. But the client is trying to deliver something. They're trying to get something out to the door to make money.

Um, and so we may have to take on some technical debt. And [00:20:00] one time, a long time ago, someone said to me, um, technical debt is no different than any other business debt you take on debt wisely to move the business forward. Right. And so we may have to make some trade-offs in the work that we're doing to keep moving the business forward.

And that's really important to do because then the client feels like they're being heard. Uh, and this is not just, you know, me coming at it as an agency person, but when I was working in inside of companies, uh, that was important because you want your business partner. To understand that you know their business, that you hear them, that you know that it is important to get this stuff out the door, to keep the board happy, to keep generating revenue so that everyone keeps getting paid.

So it may, when you do that kind of a thing, it makes compromise in the future easier. You do a little bit of trade off, uh, at this moment and later on when you kind of come back to 'em and say, we need to make a hard call for security reasons, or, [00:21:00] um, you know, other technology reasons you're, it's easier to have the conversation with a client.

The other thing, and I think this is really, really important for people to remember, is the client is right and we are here to make them writer. Okay? And what I mean by that is, um. A quick anecdote. When I first started being a consultant, I remember I went into a meeting with, uh, with my client and the guy was a jerk.

Like, there's no other way to describe it. He's this head of engineer, or not the head of engineering, but he was leading engineering on the team that I was interfacing with, and the business partner was there and the guy just immediately jumped down my throat and I have no idea to this day why, uh. I immediately went on the attack pack, right?

I felt attacked, so I went ahead and attacked and it just, the whole thing ended badly. Um, you know, his manager called my manager and I had a long conversation from my manager and I had to go back to the [00:22:00] client side and we apologized to each other, uh, and we were able to move forward. But that tension existed for the rest of the engagement.

And what I learned at that point was one, um. He had a, he had his reasons. Whether or not I thought they were right didn't matter. He had his reasons for the position he was taking, and I needed to acknowledge that. And the next time something like that came up, I absolutely did that. It was with a different client, but I absolutely said, oh, I totally hear you.

That totally makes sense. And it totally took away that anger. I was no longer. This ad adversary, I was a partner by doing that. And then we could have a conversation and I would acknowledge what he was talking about, and then I would help him see a different approach. Right? I helped that second client see the different approach.

And so, um, [00:23:00] it was in, in many ways, it became his idea. Right. And my ego didn't matter at that point. I didn't care if he took, uh, you know, if it was his idea. I wanted him to be successful. That was the most important thing to me, and I've had that, that same uh, attitude with all of my clients. I. Listen to what they're saying, they are right in their mind, and that's really, really important.

You have to absolutely acknowledge that and then work with them at that point and have it be collaborative. Have that back and forth. Have a friendly conversation. Make the idea that you have in your head their idea so that they embrace it, they own it, and they can champion it. Uh, you know, going forward 

Mehmet Gonullu: this made a lot of sense because, you know, not only from a consultant point of view, I mean.

In in, in my opinion, when you try to. Position anything in front of clients, you are, you're a consultant. Sometimes people, they like to use the cliche, trusted advisor, right? So, so I, I did like sales roles [00:24:00] also as well. And one thing which I learned, uh, the hard way, similar to you also Eric, is, you know, like, especially if you, for you, it's different 'cause you're designing something for them or helping them to, to achieve something.

So for me, I'm going to convince them. To choose something other than what they have chosen years ago. And what I figured out, like if you go and you start to hit on what they have, so the people like to do the status quo versus like the future state. And what I learned, like if you start by attacking what they have today, they would be defensive.

And I think this is a human nature and. Taking this empathic approach that you just described, Eric. It's, it's, it, I think it works, you know, across, you know, whether you are a consultant, you're, you're in sales, uh, for, for a tech company or like just an, an advisor, it works pretty, pretty well. Uh, and, and good to, to, to, to see it from you.

Also hear from you as well. Now, one thing just. During this, you, because you mentioned about, you know, the depth, uh, that that happens and you know, [00:25:00] the challenges. Uh, so of course this is additional time of course, because you're gonna try to take it from them, show them, no, this is not the way it's gonna work.

This is the way in between, right? So. How much that takes energy and effort from you internally with your team first, and then how do you communicate this? I mean, like I. Because I'm sure like there will be some engineers that, you know, report to you and they say, Hey, Eric, like, like, we know it will not work.

So how you'll manage this kind of, okay guys, right? Like we, we gonna do it. So, so how, how you, you, you, you take this and spread it within the team also as well. So to make the team also think the same way as you do. Well, 

Eric: I think it starts from the beginning of any engagement, any projects that you're doing.

And, you know, I, I've been very lucky to be both, uh, on the client side and on the consulting side of my [00:26:00] career. Um, and so I think this plays in both places, right? Um, so you have to trust your development team. It starts there. Uh, if you don't trust your development team, you gotta look back and figure out why.

Um, and I, I feel like generally if there's an issue of trust within your development team, you should probably go look in AM Mirror. I. Okay, start there. Um, you know, there, you as the engineering manager, you probably did something, um, and not necessarily, uh, maliciously. Um, but you probably did something that, uh, kind of eroded that trust.

So figure out how to repair that trust. Um, and the best way to maintain your trust after you've, you know, you started with it, is to always keep your team engaged. Always keep them in the loop. Um, so I don't go to clients, uh, and have conversations with them and then show up an hour later in front of the engineering team and say, surprise.

Uh, you [00:27:00] know, I generally have a conversation, uh, with the engineering team from the beginning saying, you know, these are the ground rules. We're here to deliver something for the client. Um, we're gonna do our best to deliver the best product possible for the client. Um, whether that, you know, if you're in a company and the client is an internal client, or if you're from outside of the company and you are a consultant, we make it very clear we're gonna deliver the best possible product.

And then I say to the team, you know, that means sometimes. Because a client has a need to get out the door. They have a, a timeline, they have a budget, um, they have key requirements that have to be met. We may have to make those compromises, and I'm looking at you all to help me figure out what is the right solution for the client.

Right? Notice it's not me saying, look, this is what we're doing. It's me. Hey team, let's talk together, figure out how to solve this problem for the client, and then let's move forward. If you have the team engaged, they've bought [00:28:00] in on it and it's much easier to move forward because they own it as well.

That's the key. I. 

Mehmet Gonullu: Right. Uh, Eric, this is like what I'm, I'm, and I know like you're a big advocate of, you know, this empathic uh, um, leadership. Right? So I, I believe like one part also that you have to do sometime is to like, of course, the trust that you just mentioned and also psychologically also giving the safety for, for the team.

So, um, let me ask you what. What can go wrong? Like, where do you see mistakes happens? You know, when it comes to having this psychological safety, um, I learned, 

Eric: um, I, this is really, really important. Probably the most important thing is listening. Um, uh, again, someone, um. Yeah, different mentor, but someone I really respected said, you know, , he has one mouth and two ears.

Uh, and he [00:29:00] uses, um, you know, those in that same proportion. Right. And I, two kind of examples of this one is, um, you know, I don't really code anymore. I'll, I'll do a little bit of, uh, DevOps stuff obviously, but, but I, I really don't code. Um, but I used to, I understand these, um, at a high level, you know, I understand engineering problems and so I've had plenty of developers walk up to me and they say they've had a problem.

They start talking about the problem and I just sort of sit there and listen and. Then they get to the solution on their own. I may ask a few questions, Hey, have you thought about doing this? Have you thought about doing that? But what I discovered is that by just sitting there and listening, the developer is able to work through the problem on their own.

And you know, I may pull in another person. I may not, but, but the key there is listening, right? Let them talk through the problem. Don't try to figure out the problem for them. Let them talk through it. If they want some help, they'll ask you explicitly. So that's the first thing. [00:30:00] The second thing I learned is, let's ignoring a, an engineering problem.

Let's talk about people problem, right? Obviously, um, there may be challenges, uh, two members of your team may not be getting along together. Um, there may be an issue with a client. Um, maybe there's something going on in the, in your engineer's personal life or they're feeling challenged within the, the job.

Um. I learned that oftentimes the best thing you can do when a developer or a QA person, a product person, anyone on your team approaches you, is to do nothing, right? I think early on in my career, and I think a lot of, uh, managers will do this, they have someone approach them. And they talk about an issue that they're having, and the manager's immediate response, and I've done this myself early on, your immediate response is, I gotta go do something now.

I have to take an action. And that's oftentimes the worst thing you can do. [00:31:00] The person's not coming to you because they want you to take an action. They're coming to you because they trust you and they want to, you know, share their feelings, their frustration, the, they just want to get it out. And once they get it off, they're fine.

Right. You know, it's like, I can't understand why this person keeps rejecting my pr I, it makes no sense. It's really making me angry. And they rent and then they get it off their chest and they take a deep breath and go, okay, yeah, maybe I can see the problem. And then they move on. If you take an action there, you've polluted that relationship, right?

You've made things difficult. But the fact that you just listen and let the person write, that's, that's probably the best thing you can do 99% of the time. 

Mehmet Gonullu: Right. Let me ask you, Eric, as a follow up on this, how hard to do this in a hybrid, uh, work model world, especially after COVID, like, you know, [00:32:00] maybe 10 years ago or before COVID, let's say, uh, people were in the office so they can simply knock on your door.

You know, just get it out to you and then go in an online format, whether it's on a team, slack, zoom, whatever. Can it be done the same way in your opinion? 

Eric: I. No, no. Obviously it can't. Right? Because, um, you know, when we were all in the office together, a person would just be walking past you in front. That would be enough to trigger they want to talk to you.

Um, so, um, obviously it's a different situation in the online world. I think it puts more, the online world puts more pressure on the leader. Mm-hmm. So one, you as a leader have to have time with your team on a regular basis in a one-on-one situation. Now some folks will say it should be weekly, it should be monthly, biweekly, whatever.

Um, I don't think there's a hard and fast rule there. I. Some [00:33:00] folks, if you wanna meet with them on a weekly basis, they're gonna hate that. They're absolutely gonna be annoyed that you wanna take a half an hour out of their week and chit chat. So you as a leader, need to figure out what is the right rhythm for every person on your team.

For some folks it might be weekly, some folks it might be monthly. Mm-hmm. I, I think monthly is probably too long. But you know, if, if you have a high performer, um, and they're doing well and you feel connected with them once a month, great. Uh. So establish that rhythm with your team and, uh, make sure it's consistent that you hold onto that time and you keep doing that.

Uh, and then pay attention to your team if they still wanna keep doing that. The next thing is you need to attend your daily standups with your whole team. You need to listen to that. The one thing I don't believe in is a virtual standup. Uh, you, and by that I mean like everyone types in Slack, what they're doing and then they kind of move on.

You need the call, you don't need the faces. Right. Turn off the camera. I hate, you know, when, [00:34:00] uh, managers and system cameras be on. Um, don't do that. If someone wants the camera off, let the camera be off. Mm-hmm. But you wanna hear their voice. You want to pay attention to the standup, and as the engineering leader, you should be really listening.

Don't just, you know, kind of start off into the distance. Actually listen, hey, what did they work on yesterday? What are the problems they have today? And keep track of that. And they keep having the same problem a couple days in a row. That might be a moment for you to say, Hey, uh, you know, let's, uh, check in together.

Um, after the call, I just wanna have a few questions for you to see how you're doing, right. Uh, have that conversation. Um, the other thing you can do is if you have a team that's highly engaged and working, they're going to be, uh, in Slack communicating with each other. Make sure you are in those Slack channels.

Mm-hmm. Um, and discourage people from having conversations about the project in one-on-one. Uh, kind of conversations in dms. Make those conversations happen inside of Slack. In a [00:35:00] shared space where everyone can see it. One, um, it discourages, um, you know, people from kind of complaining about each other, right?

Uh, you wanna kind of avoid that kind of backbiting that can happen, particularly when you're working with a client. Um, but more importantly, you make it easier for people to overhear, if you will, that two team members are having a problem and they can jump in. And contribute. So you're encouraging everyone to, to see what's kind of going on, um, and to contribute when appropriate.

Um, and the final thing around that is if you're going to encourage people to be in Slack, then you need to encourage people to control slack. So I turn off that stupid knock, knock, uh, I turn off alerts unless I, unless a message goes to me either as a DM or an at channel, right? And I encourage people to do the same thing.

Slack is, uh, you know, the company. Wants you to engage with their [00:36:00] product all day long. And so they make it as annoying as possible, right? And so you as a manager, uh, need to go to your team and help them configure Slack so that it is a tool and not a distraction. I. 

Mehmet Gonullu: Right. Yeah. Uh, I think it's not only engineering teams.

I think everyone complains sometime about Slack, like whether in sales organizations or like, uh, product teams, engineering teams. Yeah. It's, it's a form of, of distraction. And the thing is, I, I used to do, you know, this mistake myself, so. If you give a favor once on Slack, you're gonna do it all the time. So, yeah.

So yeah. So it's, it's, it's good to to, to set the boundaries from, from beginning. Now, Eric, one, one part, which I'm sure you know, you, you have this, uh, uh, ambition to. Train fellow leaders, right? So to have the same mentality and you know, we need more people like yourself or [00:37:00] honestly Eric, like, because we, sometime we hear horrible stories from, from the field.

So how do you spot someone that's, in your opinion, uh, in engineering team, to be coachable, to become a leader? What's some of the traits you look for? Um, you 

Eric: know, I look for, this is tough, right? Um.

I mean, I know what I look for. So I look for folks who step up, um, who are happy to pair up with, uh, other developers to help them solve problems. Um, you know, they often volunteer, Hey, I see you're having that problem. Uh, do you wanna pair up? And then they'll pair up very quickly. Um, I, uh. I listen to the way they talk to other people.

So, you know, do they have more of an empathetic approach or, um, you know, are they kind of mean to people when they're kind of, uh, providing them, um, suggestions, if you will. I look at, um, you know, kind the things that they [00:38:00] put in their, uh, PR reviews. You know, are they, uh, providing examples? Um, are they, uh, looking for areas of growth, um, you know, for that code base as opposed to like nitpicking?

Um, you know, um, I. I look for people who are even keeled and calm. I definitely can have kind of a high affect, I can get very energetic. Um, and, uh, so I, I look for folks who, um, uh, can go into a situation, uh, and maybe are a little bit. You know, can be very calm and direct and kind of help folks take a step back and, and see what the problem is.

Um, all that stuff happens publicly. Uh, these are things that, you know, you don't necessarily pick up in a one-on-one. And I think, again, as, as an engineering leader, if you're paying attention, you're gonna see that. And then the last little thing I will check with folks, um, you know, if, to see if they're interested in kind of getting into more of a [00:39:00] leadership role beyond being a lead developer.

Um, not everyone wants to do that. If someone is happy at the level they're at and they don't wanna advance anymore, I. I think that's great. I help them get better at that level. I don't force people to get promoted or become leaders. Um, you know, doing that ends up with really bad leaders. You end up with folks who are not happy in that role, um, and they may self sabotage and you don't wanna set the folks up for failure that way.

I. 

Mehmet Gonullu: Yeah, I heard a lot of, uh, stories, uh, about people who didn't want, but they were forced to and they, they, they, they confessed. I, you know, they, I was a bad manager. They, they told me this, like I was, I wasn't a good leader. Mm-hmm. Um, so, but for the folks who are really interested, any resources, any books, maybe Eric, you, you advise them to, to go and, uh, check out?

Eric: Oh gosh. You know, I am, uh, I don't read a lot of books on, on, uh, leadership, uh, for good or ill, um, I have found the [00:40:00] best way, uh, for me to have learned. So, so I, I would say the approach that I took was to find mentors. Mm-hmm. Every step of the, along the way in my career, I have found someone who I have learned something important from them.

Um, and you can tell who's gonna be a good mentor. Um, are they empathetic? Do they talk to you? Is their door open? Um, do they give you advice when you ask for it? Do they listen when, uh, you don't want advice? Um. And that mentor, um, you know, may leave where you're at. And I think it's important for you as, as you grow, you know, keep in touch with that mentor.

Um, you know, meet, meet with them for lunch. I. On a regular basis. Um, talk about where you're at. Uh, you know, it doesn't have to be a formal mentoring relationship. It can be very informal, but I have found the people, um, that I learned from, you know, and that I'm still learning from, you know, [00:41:00] over the course of 20 years.

Um, I can meet up with them over lunch. I could talk to 'em about a situation I have going on. They'll gimme some advice. It's always sound. Uh, and that helps me grow. Uh, and, and I think that's the most important thing you can do. I know there are a lot of books out there, I wish I could recommend some, but I'm a big fan of, of talking to other leaders that you respect, uh, and keeping them in your life and continuing to learn from them, uh, for the rest of your life.

Mehmet Gonullu: Make completely sense. It doesn't have necessarily always to be a book. Like mentors are resources, by the way. Like you, you, you can learn from, from, from an open book. I would call it like, uh, live. And as you, you watch them, you listen to what they say. Um, you know, I can say myself, you know, majority of the things I learned was from people that I used to, to, to consider as my idols and, uh, you know, follow them and listen to what they say and how they do things.

And thinking like, how, if they are not [00:42:00] available, you know, the one hack that works for me is to pause for a second and say, Hey, like if, let's say, if Eric was with me now, what he would say, like, I would just imagine that, you know, you were with me and. What you would advise me to do, and you know, this is just like a couple of seconds or maybe one minute pause.

It gives, you know, this clarity, uh, usually on, on what you should do next. Um, Eric, like, um, if, if I want you to leave the audience with kind of final, uh, word of wisdom or anything that you would like to share, so what you would tell, and of course a traditional question where people can know more about you and get in touch.

Eric: Um, so from a word of wisdom, I, I'm building off of something you said. You know, I remember one of my mentors said something to me I think is really, really important, which is, uh, trust yourself. You know, you got to where you are today for a reason. [00:43:00] You know, you are, uh, you're smart, you're competent, you know what you're doing.

People have trusted you to put you in the role you are today. You know, as a lead developer, an engineering manager, director of technology, CTO, whatever. And, and Billy on what you said, I think taking, um, taking that moment. And trusting your inner voice and moving forward, uh, is often the best thing you can do.

Don't get caught up worrying about an an issue, you know, going back and forth, causing yourself stress, staying up until three o'clock in the morning trying to solve it. I've often found, you know, meditating for a few minutes, taking the deep breath, making the decision, owning it, and moving on. Trust your inner voice.

99% of the time. It's right. Um, and then as far as the best way to find me, uh, you know, look for me on LinkedIn. Um, so, uh, my profile's relatively up to date. Um, uh, I could definitely be reached there. Um, and then, uh, I [00:44:00] do have some social medias, but those are for now more purposes. So definitely no problem, uh, on, um, 

Mehmet Gonullu: on LinkedIn.

No problem at all. Uh, Eric, really, I enjoyed the conversation, like, um. You know, your knowledge and your experience speaks to about itself. Indeed. Uh, I learned a lot from you. You know, um, and I, I'm a little bit biased because one of the main reasons where, which pushed me to start this podcast is to get inspiring leaders like yourself, to share from their experience, you know, to, to.

You know, because now imagine someone listen to this, he's listening to you or she's listening to you, and you are kind of indirectly a mentor. So this is why really I appreciate all what you, uh, shared with us today. All the insights also. Um, and of course I know how busy it can be. So you took this time to, uh, dedicate to, to me today.

So thank you again. And this is for the audience. This is [00:45:00] how I usually end my podcast episodes. So if you just discovered. This podcast by luck. Thank you for passing by and I hope you enjoyed If you did, so give me a favor, subscribe, share with your friends and colleagues. We are available on all the platforms, apple Podcast, Spotify, and YouTube videos, of course.

And if you are one of the people who keep coming again and again, thank you very much for your loyalty. I can't thank enough all my. Audience, and of course all my guests, including you, Eric, because this year is special. Um, the podcast is doing very well. We are getting in the top 200, uh, apple Podcast charts across multiple countries for the first time since I started and, uh, half years ago.

So this is big for me. Maybe it's a small thing, but for me this is big because that means people are listening. And getting benefit out of it, which makes me happy. This is the main cause of the podcast. So thank you very much and as I promised you every time, [00:46:00] we will be in a new episode very soon. Thank you.

Bye-bye.