#491 Scaling Engineering Teams for the AI Era: Insights from Mary Moore-Simmons

[00:00:00] 

Mehmet: Hello and welcome back to a new episode of the CTO Show in Mehmet today. I'm very pleased joining me, Mary Moore-Simmons with, uh, she's the VP of Engineering at KI ai. Mary, thank you very much for being here with me today. I really appreciate, uh, your time. [00:01:00] So, the way I love to do it when I have every guest, the audience know by now, I keep it.

To them to introduce a little bit, you know, about their journey, what brought you up to, you, know, what you're currently doing, and then we can start discussion from, from there. We're gonna talk of course about, uh, topics, mainly about being a VP of engineering. We're gonna talk about building teams, we're gonna talk about AI a little bit and whatever, you know, the discussion will, uh, let us talk about today.

So the floor is yours, Barry. 

Mary: Thank you so much. My, uh, it's great. Uh, thanks so much for having me on. Yeah. So, uh, you asked about a little bit about my journey. Um, I'm happy to start there, if that makes sense. 

Mehmet: Sure. 

Mary: Yeah. So I actually started out my career as a chemical engineer. That was, that was my, that's my like, fun fact, uh, as I started out actually as a chemical engineer, but.

I studied, uh, computer science in college as well, and, um, I made a move to software engineering after a few years. Uh, and so I worked, I, [00:02:00] I kind of like accidentally fell into startups. I got recruited by a startup without really knowing what a startup was. Uh, and then I just fell in love with startups. Uh, so, um, I've been.

Doing, I've been working at startups for over a decade now. Um, and, uh, yeah, started out actually in DevOps, which I still, still has a special place in my heart. Um, and then I moved over to, um, managing teams and then managing, uh, non DevOps teams, uh, more like, uh, you know, traditional software engineering backend teams, front end teams.

And then sort of like, I guess I'll say that I like continued to expand my scope in leadership. Um, I think one thing, one really formative experience for me was, was seeing how culture can change as companies grow and wanting to be able to help guide that so that in a startup [00:03:00] as companies grow, that you can maintain a really strong culture as you try to grow and scale.

So that was kind of what. What drove me into continuing to try to like expand my scope. Um, and yeah, I've been in engineering leadership for I think almost, uh, 10 years now. 

Mehmet: Great, Marianne, thank you for this, uh, introduction and yeah, like, you know, culture. We're gonna talk a little bit about it, but first, like, tell me a little bit more about, you know, your, your current role and you know, about, um, what you're doing at Keebo and what Keebo does.

Mary: Yeah, so I'm our head of engineering at Keebo. Um, we are a, uh, small but mighty company. We are a series a startup. Uh, and, uh, we do, um. Optimization. We do, we do currently we do optimization for data warehouses. So for Snowflake and Databricks, uh, we use, uh, machine learning, ai, uh, and AI to, um, automatically optimize snowflake [00:04:00] environments and Databricks environments.

And we do that through optimizing warehouses. Um, and then we also can help optimize, uh, where you're sending your queries. Um, and we're working on optimizing queries themselves. 

Mehmet: Fantastic. Now I want to stay there a little bit before, you know, jumping on other topics because you just mentioned AI and a bunch of other things and yeah, data engineering, and you said like you also like, you like DevOps also as well.

How are you seeing, you know. This intersection now. Um, I just had an, um, an episode the, the other day, and you were talking about how, you know, now there's kind of merge between let's say software engineering and data engineering, right? Mm-hmm. So from, from your perspective, and as a VP of engineering, and you've done this for a long time, um, so what's changing currently, Mary?

Like what, what are like some of the things that are, we are, we are heading towards, I would say. 

Mary: Yeah. What's what's interesting to [00:05:00] me and uh, is that I have found myself in every, uh, in, in almost every company that I work at describing systems as like all software does, is it takes data from one place and like does things to it and then puts it in a new place.

Um, and so actually what's interesting is I've always kind of seen software engineering as, as like there's data underpinning all of it. But what I think has changed is that. The size of data has increased. Data has become incredibly valuable, and we've realized what we can do with data, uh, in a way with, with machine learning, with ai, and even just with like, you know, data science and data analysis.

Um, we've, uh, realized I think as a society, uh, how useful data is now that it's digitized and that's just continuing to grow. And so what, what's happening is it used to be that you could handle this. Like handle, you know, data underneath your applications without a whole lot of experience or expertise in data engineering, because the data [00:06:00] sets were fairly minimal, but now the data sets are massive and we're realizing all of the, uh, benefits that you can get by getting more and more data and doing things like training machine learning models on them.

And so the, the best practices around how to manage that data has had to like level up. Uh, and so because of that, uh, I'll say like even for myself, I am hiring, I think for three. People, three ics right now and a manager and for, so four people total and for those four roles, three of them I'm requiring data engineering experience and one of them I'm requiring, requiring machine learning experience.

So I think it's just like as your company starts to do more machine learning and care more about data, data engineering experience becomes just like absolutely critical. Um, even though these people are, most of the people I'm hiring are going to be writing features. On the product, it doesn't really [00:07:00] matter because they still like, I mean, it does not, it does matter, but they, they need that data engineering experience.

And, uh, the, the other, uh, feature building experience. 

Mehmet: Absolutely. Now from infrastructure perspective, because Mary, I think, and you know, maybe I don't want to make too much loaded questions today, um, from, from infrastructure perspective, uh, because also this is something that falls under you. Mm-hmm.

Correct me if I'm wrong. Um, yeah. What also AI is, is doing here. Like is it in, is it like, how is it helping you? I would ask it this way. 

Mary: Uh, are you talking about Well, I'll, I'll, are you talking about like ML ops and that sort of thing? Yes. Yeah. Okay, great. Yeah, so that's something that I get excited about because it's the intersection of like machine learning and my favorite thing, which is DevOps.

Uh, so ML ops is a, is a great, it's a, it's a big emerging area as you know. Uh, and it's because, um. [00:08:00] One, like we actually already know for non machine learning use cases. Well, I, I say we, but like a lot of people know this, I think. Um, but one thing I'm a, I'm personally a huge proponent of is I love having DevOps teams that are, that are very focused on engineering experience.

Uh, and, and I've loved that for a long time. And the reason is because my engineers are my, I'm, I mean like. Lot, like very, from a very business perspective, my engineers are my most expensive resource. Um, and, uh, they are the hardest to find. It's, I think it's very difficult to find good engineers. Uh, and so they're, they're hard to find good ones, and they're very expensive, and so I wanna keep them happy and I wanna keep them efficient.

Uh, and so that's what DevOps teams do to, to me if, if you like, orient them that way is like their entire focus is like, how do I keep these engineers happy and efficient? Um, and that's like very holistic. That includes like, how do I help them improve quality? How do I help them improve security? And then also how do I help them [00:09:00] move fast?

Um, like how do I make the annoying parts of their job easy so that they can do the fun things and like just move faster? And so I think this has been valuable forever. But now with the introduction of machine learning, it's like, okay, now, now we have these new set of people that we need to keep happy and efficient.

Um, and, and what they're doing is just slight is, is slightly, well I say slightly, it's different than what software engineers have done in the past. And I will say it depends on the person, but some of these machine learning folks actually don't have a background in software engineering. They have a background in mathematics.

Uh, and so they actually need even more help than maybe your average engineer would. To help them, like, move things through to production. Um, and they have even less context than maybe your average engineer would, uh, like backend engineer would on how to have like stable, reliable services in production that are repeatable, that are well monitored.

So they actually need even more help in support. Sometimes, sometimes they don't. Sometimes people just like they, they were a software engineer and now they're doing machine learning and they don't need quite as much help. But, um, [00:10:00] some of the folks more, more advanced in machine learning need a little bit more help in that area 'cause that's not their area of expertise.

Um, and so this is like this new emerging market that I think is really exciting. 

Mehmet: Really exciting. Now I gotta ask you a question, which is, I'm not sure if I asked before, and this is why, if I did, must be long time, uh, especially in the startup space. Mary. Um, people ask me, but I like to hear from the expert.

Um, they ask me always What's, what differentiates the role of VP of engineering from the role of the CTO? 

Mary: Ooh, I love this. Um, I'll, I'll tell you what I believe it to be for me. Um, so I, for, for me personally, I haven't coded in a while. Like, I, I think my last like, I mean, I haven't like seriously coded on any sort of like serious production project in a while.

Um, and. So for me that's just recognizing like, I just need to recognize that I'm no longer the [00:11:00] best person in the room to make technical decisions. Um, and when I am like spending my time on a team to figure out, I. How to make sure that team is like happy and thriving and growing and doing well. I end up, I've noticed that I tend to gravitate towards like people problems, organizational problems, process problems.

Um, I still really love the technical problems, but I'm rec, but I recognize that I haven't been close enough to that for long enough that I feel like. Comfy saying, yeah, I'm A CTO. Uh, whereas I think that CTOs tend to be more technical. I think that I've had CTOs that I've worked with that have zero reports.

Um, all they do is like, they're essentially like a principal engineer or distinguished engineer. Um, and so I think that CTOs, I think bring a much more technical lens to what they, what they want to do in the organization, whereas like, I'm acknowledging that. My, like [00:12:00] I want to empower engineers to make technical decisions and that I'm probably not the best person to make some of those technical decisions.

Like I can ask questions, I can help them with architecture design. I can dive in with them if needed, but I am like, have. So much on my plate that I don't think I have the time to dive in technically as much as I want. Whereas I think CTOs probably recognize like, actually my passion is technical and like, yeah, I'll lead people too, but like, that's what I wanna do.

Whereas I think my passion is leading people and I love technical problems, but like my, my, I think they, I tend to gravitate more towards leading people, so that might be a spicy answer as possible. Other people have different opinions, but that's, that's mine. 

Mehmet: No, no, that's, that's good. I, you know, I like.

Sometimes people, you know, ask me why you keep asking like kind of same questions to different guests. And I say, I have a philosophy because, you know, the more, for me at least, and I think maybe some of the audience, they, they love it also, the more like we collect different opinions. So probably someone would have, you know, kind of a [00:13:00] mix that makes sense more to them.

Right. So, so completely makes sense to me also as well Now. One thing, which you mentioned in your intro also, Mary, like you, you've worked like, um, almost 10 years you said for in, in, in startups now, uh, and you work like in places like GitHub, jet Cash and, and others. So. How do you balance really, you know, the velocity we, we know, like in startups we need, we need something we say like, bring think fast and fix them fast.

Mm-hmm. How do you manage this balance between, you know, this velocity needed and at the same time making sure that the team, you know, is, is sustainable and like in the environment is sustainable? What, what lessons you can share with us, um, in regard to this. 

Mary: I think that anyone who's told you that they figured it out is probably wrong.

Uh, but, but I'll tell you like how I try and, and I'll acknowledge that it's a, it's a [00:14:00] difficult balance that you are constantly like making micro adjustments all the time and you're also constantly making mistakes and having to, like, again, adjust because you've went too far in the wrong direction. Um, but I'll, I'll tell you sort of like high, high level philosophically.

Um. The, the thing I like to think about is how much effort do you spend building, like a solid, reliable product relies on how confident you are that that feature or that product is a market fit. Mm-hmm. So if you. Have a new feature that you're building and you're not as confident that it's the right thing.

You should be building it fast and sloppy, honestly. Like you should be building it fast and sloppy because you just wanna get it in front of a customer as soon as possible and get their feedback. And then if they like it, great, then you can go shore it up. Um, if you have a feature that has a ton of market validation, customers have been begging you [00:15:00] for it.

Uh, you, you like know that it's what they need. It's on an established product that's already getting revenue. That's probably the time to make sure that you're building it more reliably and scalably because you have more confidence that the customers are gonna like it, uh, and that, uh, and they're gonna immediately wanna use it and then it's gonna have to scale.

Uh, so I think that like, it depends on where, what phase you're in. If you're in a phase of like. And this is why startups are often like moving fast because they're, they're mostly in that phase of like, we don't really know exactly what the customers are gonna want. And so like, let's, let's try to, let's try to figure it out.

But then, so, but then, right. So, so step one, you do that, but then you're in a place where, okay, customers love this. Okay, now it's a hot mess and we need to go fix it. And so that's the place where it gets tricky because then you start to have trade offs of like, well, is it, is it. Stable enough for now, and I can go add more features.

Uh, and that is honestly like a day-to-day, week to week, month to month trade off conversation that you're having. [00:16:00] 

Mehmet: So if I understand that correctly, Mary is when we decide to put a feature, we think that customer would like it or would, would use it. We don't plan. It's full sprints and you know, sorry if you are not technical or even didn't do, uh, product development.

So what I mean, like you put the kind, let's, let's make it simple to the audience, like kind of the roadmap of that feature. So we don't need to. Put the whole thing at the beginning. We just make only the main, let's say, use case that we gonna solve with this feature. And then as I understood from you, we plan how we can enhance it, where we want to go with it.

Did I get that correctly? Yeah. Yeah. 

Mary: Scope it down as small as possible at first, and then figure out what you need to do and like, do you need to change the feature? Exactly. Do you need to enhance it? Do you need to stabilize it? Because it was absolutely on the money and the customer loved it and now everybody wants it.

Uh, you sort of like figure it out as you go. The, the hard trade off is that it's always that question of do [00:17:00] I spend my time shoring up the existing features or do I go get more revenue by, by adding new features? And that's the trade off because it, it can be a little bit harder to track what revenue or efficiency you're losing by not shoring up your existing features.

That can be a little bit harder to measure a little bit and, and like. To be honest, customers kind of have like a little point where you can kind of annoy them a little bit, but not like a lot. And so you're, you're kind of playing this game where you're like, how much can I actually bother my customers without them being really upset so that I can go get new revenue right now?

Mehmet: Right. And I think in this, um. To put it in this way, like if, if we are talking about startups, so probably we're also talking about early adopters who are kind of, you know, they would understand that, you know, some, you know, not non stable things will, will come out and there'll be some problems down the road.

So I think this is also important to [00:18:00] choose, you know, the early customers who are gonna try this feature. Like we need, we used to call them, you know, as, as field people, like, uh, friendly customers who, who would like, you know, they will understand, yeah, we're trying to, to see if this is works, do you need it?

And then get back to engineering and see how we can enhance this. So a hundred percent on that. Now, within this, um. As a leader yourself, Mary, I'm sure you know between the field team. And the engineering team, and usually there are a bunch of people in between, but sometimes there will be this, I would say, fire that's coming.

Hey, things are not working. So how do you manage to protect your team from, from all this? It's, it's like cows. I know I've, I've seen it before myself. Mm-hmm. Uh, because I was the one who's complain. But anyway, of course with times I start to understand. But as, as a, you know, [00:19:00] leader. How do you protect your team from, from, you know, all this, I would say crisis, uh, effects that, that might also affect them also as well.

Mary: Mm-hmm. I think that the key things that I like to do are, I like to set clear expectations with, uh, the entire organization of what is a crisis and what is not a crisis. So I like to set clear expectations of, okay. If a customer's upset about this, that's a big problem. That's an outage. We're gonna work 24 7 until we fix it.

If they're upset about, so like if the service is down, you know, if like the UI is not loading, if there's like data's completely wrong and it's like billing data, right? That that's like, that's a big deal. But if there's a bug, there's a workaround. That's not as big a deal. We don't need to react as quickly.

So I think one of the things that I like to do is, is set expectations with the rest of the organization of what is urgent and what is less urgent. And that way we can all be aligned on that. I. Once you do that, then I tend to set [00:20:00] up a system so that the engineers can be a little bit buffered from the urgent things.

Right now what I do is I do a rotation of, like, we have a, we have an on-call engineer that handles like urgent bugs and pages, and that rotates through the team. And so then the rest of the team can really focus on their work and not be constantly getting bugged, uh, or bothered. Um, so that's, that's, that's.

Some of the things that I like to do. Um, and that's, that's me sort of like zooming in on like outages and bugs and those kinds of fires. But, uh, there's also like strategic fires and again, that's just. One thing I just like to bring to a conversation is I like to bring reality to the leadership team because they'll be saying, like, they'll say, Hey, I really want this.

And I'm like, I, that's a super great idea and I think it's super important. Which of these four things do you wanna not do so that you can get this done? Uh, and so I'd just like to bring like a very like. I'm not strongly, I mean, I, I can bring my opinion if needed, but I like to almost be a neutral party in these sometimes because it's like, Hey, this is a business decision and [00:21:00] you can't have everything, so what thing do you want?

Um, and those are like the sort of two techniques that I find most useful. 

Mehmet: Absolutely makes sense to me. Now, when it comes to hiring Mary, what, of course the technical stuff should be there, but from like what special traits you look into, uh, when you hire, uh, your team members, like of course, other than, as I said, the, their technical knowledge.

Mary: Mm-hmm. Yeah. Hiring. I, I love that you asked this. 'cause hiring is one of the most important things that I think I do, uh, as a. As a leader at a startup, because you're usually hiring if you're at a startup. Uh, and it's the most important thing that you can do because you want to build a strong team with strong culture.

Uh, I will say that what I'm gonna tell you is my personal preference. I think it's, my personal preference is based on my leadership style that I like to have. Uh, and my leadership style that I like to have is I like to have like a, a very transparent, high autonomy team. [00:22:00] Uh, and so in order to do that, I need people who are, uh, have a growth mindset.

Who love learning, who want to learn new things, who love learning new technologies, uh, and love feedback and want to take feedback and want to continuously improve. Um, and then the other thing I need is like people who are able to look at like big, scary problems and just say, okay, you know what? This is big and scary.

I'm not a hundred percent sure if we can get it done. But I'm just gonna make a plan and I'm gonna start at step one and we'll, like, we'll adjust as we go. Um, like people who don't get too shell-shocked when there's like a big problem in front of them, they just like chip away at it. Um, and I think like there's a piece of that that I, that I is maybe in those two things, but I, I'll just mention it separately, which is like, people who like improving things, like people who feel empowered and wanna improve things.

Um, I love just like. Giving my team all the context, direction, and information that they need to make decisions and be like, here's [00:23:00] what I see as the biggest problems. What do you see as the biggest problems? What, what is affecting you? And then working with them and to come up with a plan for how they can improve that and make their lives better and improve the like biggest problem in the organization and make customer's lives better.

So those are like the big things I look for, but I always wanna caveat that's because of my leadership style. There are different leadership styles that are looking for different things. 

Mehmet: Yeah, absolutely makes sense. Um, talking about still leadership style, so I know you championed for authentic and transparent leadership.

Mm-hmm. So how does this look in practice like, especially I. When it comes, of course, you know, like I always tell people leadership, it's not about, you know, titles or like, um, you know, it's not like something that you can describe in day-to-day, uh, things. It's like about decisions also as well. So how that looks like to you, uh, and authentic and transparent leadership.

Mary: Mm-hmm. I think that the thing that a leader [00:24:00] needs to be authentic and transparent and have that work is. I don't know a better way to say this, so I'm just gonna, it's gonna sound a little mushy, but like, have like true love for your team. Like you have to, like, love your team. You have to, uh, really care about them.

You have to care about their growth. Uh, you have to, um, like want the best for them. Um, and you have to be humble and know that like you don't always know best. You are not always the right decision maker. And, uh, your job is to empower these people and get out of their way. Uh, and I think that like, if you don't have that, then authenticity and transparency does not go well with an engineering team.

Uh, and so like the, this, again, it sounds like mushy, but it's like the key ingredient is love. It's like you gotta love your team, you gotta care for your team. And, and also you gotta be humble and understand, like you're just there to, to empower them. And that's, and that's what your role is. 

Mehmet: Cool. Now let me ask you about culture.

[00:25:00] Mary. You know, I'm liking the flow and you know, I'm trying to, to connect the things mm-hmm. Culture and um. It's something I tend to always ask about it, whether VP of engineering like yourself, C-T-O-C-E-O-C-M-O, everyone. Everyone on the leadership team. Mm-hmm. I like to ask them about culture and what I'm interested in.

'cause there is kind of a myth or I would say, I don't know, this is a riddle I'm trying to solve here. Does culture scale. Uh, different opinions I had so far and, you know, I'm doing the podcast for the past two years and a half and I have mixed opinions. What's your opinion? Does it scale? Can we keep the culture, you know, when you said just now, for example, you know, um, you know, the, the love for the team and you know the way which is authentic.

I can, I can see this, I can feel it, but how we can scale and is it scalable? 

Mary: That's a great question. I. I have seen it [00:26:00] scale. Mm-hmm. But I've only, I've only. I've only seen it scale to a certain point. Mm-hmm. And so it's possible that I like to believe that anything is possible and I like to believe that it can scale.

I wanna, I wanna acknowledge that I've only seen it scale beyond to like, maybe a couple thousand people. Um, and, and I haven't seen it scale beyond that, but I believe it's possible. Uh, and the times that I've seen this scale really well is when I had a CEO that was like truly. Bought in to caring about people and caring about culture.

And that was like core to who they were. And they're, they like embodied the culture that they were looking for in the organization and held people accountable to it. Uh, and so I think that, like, I think, I like to believe it's possible and I think that the recipe is like your CEO has to live it, embody it, and like expect it from everybody in the organization.

Mehmet: Continuing on this, [00:27:00] how much do you think is the mindset of, again, it's the CEO you mentioned the CEO, and always we say the CEO drives this. Mm-hmm. So how much do you think, you know, this mindset shift from, you know, being that humble, small startup, you know, in, in the journey of becoming an iconic company or, you know, like.

The big scale up now plays a role in this. And have you seen it, like, okay, it's nice to see like you've seen good examples, but have like what, what about like the other side of the table about people just jumping out of this, you know, we call usually startups, rocketships, right? So mm-hmm. Uh, what, what can go wrong if, if I want to be more, uh, straightforward in my question?

What, what can go wrong? 

Mary: Yeah. Yeah. I love that. So things that can go wrong. Um. One little like secret that, that maybe some people would disagree with me on is, uh, as a leader you don't really get brownie points for making your people happy. Uh, you don't really get brownie points for like, for, [00:28:00] uh, for keeping the culture you have to care about it.

Your, your CEO or the, or like is, is gonna hold you accountable to results. That's the most important thing they're gonna hold you accountable to. They less likely, almost never keep you. And this is probably, again, a spicy take. Keep you accountable to like, is your team happy? Is your three team thriving?

Uh, is the culture good on your team unless it impacts the metrics. And so, uh, that's one thing is like, that's, that's like sort of the. Reason I want to give for why it's hard to care about it because you, 'cause a lot of leaders aren't, aren't like, you know, holding you accountable to that. Um, they're holding you accountable to, you know, results and metrics.

And as long as the culture is like just good enough that the metrics don't go south, then, then it's fine. Uh, so I think the things that can go wrong are people get busy and they stop worrying about it, or they stop thinking about it because they're really focused on the metrics. Um, I think that, uh. It can be hard when.

Money goes bad. Like [00:29:00] if the revenue's down, if the company's not doing well. It's easy to have really strong culture when like you're swimming in money and like everything's a party and like, you know, we, we have all the space in the world. Um, but it's hard to, uh, stick to good culture. When I. Things are hard.

Money's tight. People start pointing fingers. Um, and so like that can be a, a difficult thing to work through if you're not really sticking to it. Um, the other things that can go wrong are, um, bad hires. Like I think that, uh. Especially on the leadership team level. Like I, I noticed as a leader that the higher up somebody is in my organization, the longer it it, the longer it takes me to tell if they're a good performer.

So like an individual engineer, I can usually tell within a month or two. Um, a manager, it usually takes. Like, you know, three months to six months, a director can take as much as like six to 12 months. So I can only imagine that like as a CEO, if you're managing a leadership team, it can take a while to understand how effective your people are.[00:30:00] 

And so if you make bad hires. Uh, and don't notice quickly enough that they're impacting the culture of the organization. You can have mass exoduses od I, uh, before, before you know it. Uh, and I think that's, that's important. I think it's like holding, like when, when people aren't holding leaders accountable for culture, when they're not noticing, um, that there's a bad hire made.

Uh, I think those are some, some big mistakes. Um. I think that a lot of leaders, when companies scale, they think, oh, I need to bring in like mature leaders who have done this before. Like, I'm gonna bring someone from Microsoft, I'm gonna bring someone from whatever. Uh, and sometimes they do it too soon. Uh, and it can also destroy the culture because that person is operating in a very different environment where that cultural like thing is, it's not the same.

Uh, and I think that's another thing that people need to pay attention to, is they go, they like hire for like [00:31:00] experience instead of culture sometimes. And I, I, I wish they would pay a little bit more attention to, to both. 

Mehmet: Absolutely. Um, I'm not sure if I've read it somewhere in a book or an article that, yeah.

So to your point, sometime they are called bad hires. Sometime they are called, um. Hiring in, in, in the wrong timing, as you mentioned. Like, you, you, you, right? Mm-hmm. So, so it's, it's like one of the main reasons why culture actually start to, to, to have issues. And funny enough, it happens on all levels within the company, whether like engineering, sales, marketing, like any department you go, you can go to and.

I tend to tell people, you know, and it's funny that we repeat us, not us as you and me. I mean, I see this repeated a lot of times and I tell people, look, if someone is successful at company X in whatever role, engineering, sales, marketing, you, [00:32:00] you just name it. So this person, he or she were successful in my opinion, because they were the right fit at the right time there.

Now, when you bring someone, uh. I would talk about sales because like, you know, this is where my recent roles were. If you bring like the most brilliant sales rep from X company and you bring him to a startup early, they would not succeed necessarily. And the reason is because the playbooks there are very different from a playbook in a startup.

And they can, they would not survive. I've seen it. In front of my eyes multiple times. I've seen like people also coming from VPE level in different departments and they start to struggle in the startup, and I tell people, look. It's not just the character or the person, it's a mix of person, location and time.

It's like a three dimension. This is my own philosophy on this. And you cannot, like if, if you, you cannot replicate, you cannot [00:33:00] copy something and you need to train that person on the culture first and then they might be fit. So, um, the. Too much resonated with me. I would say this, Mary. Now let me ask you this.

Um, part of, you know, being a leader is to prepare successors, right? Mm-hmm. So how do you help someone who might be brilliant in, in whatever, whatever they do on the technology side, but you feel like they need little bit push to become leaders. You see that there is a potential, but they are missing something.

How do you coach them? How do you or mentor them? 

Mary: Yeah, so the, the first key ingredient here is they have to want to be like a, a leader, either a technical leader or a people leader, whatever they want to do. That has to be the first thing they have to want to, uh, I am a big proponent of, I don't like to push people into roles that they're not interested in.

So like, step one is like, if they don't wanna be a [00:34:00] manager, don't try to push them into it if they don't wanna be a technical leader. Don't try to push them into it unless you absolutely need that for the organization. And then it's like a, then it's actually kind of maybe a performance conversation. But if they wanna do it, that's great.

Uh, what, so then the next step is, okay, how do you coach them? So if they want to do it, then you, what I like to do is I actually, every organization, almost every organization I go to, I end up rolling out like career ladders and job descriptions. And so it's very clear descriptions of. Here's the expectations of what you need to do to be a really strong performer in this particular role.

And I just write it down and I, we go through the list together. We talk about what's going well, what they need to work on, and then we stack rank like, here's the things that you should work on in a way that's like not. Hopefully not overwhelming. So you, because you stack rank them, uh, and we talk about what are we gonna work on first.

Um, and so for each one I just like to come up with a specific, uh, place of like, here's a place that you can work on this skill. So like, if, um. They, if one of the [00:35:00] skills they need to work on is having more cross team impact of technical leadership, then it's like, great, I'm gonna, I'm gonna be on the lookout for some sort of like feature build that requires multiple teams and I'm gonna have you lead that.

And then I. That. So it'll give you practice. And while you're doing that, I'm going to be meeting with you regularly. I'm gonna be checking in on how it's doing. I'm gonna be getting feedback from the team on how it's going. I'm gonna be asking you to get feedback from the team on how it's going. Um, and so I sort of like, help create a path, give them the opportunity, and then make sure that I'm like supporting them through it.

Um, and that, that generally has been, has been pretty effective. I think that the, the places where it can go awry are either if, like I don't actually have enough. Time to support them. Well, and that means I need to be hiring more managers, um, or, uh, or like, or directors or whatever. Um, or, um, if they, it turns out they don't like it.

Mm-hmm. And that's fine too. Mm-hmm. Like, then you can say, okay, well you don't like doing this thing. Like, let's find you a new [00:36:00] path that, that works better. 

Mehmet: Alley Books, resources, you can point, you know, maybe people who are interested. 

Mary: Ooh, there's a, there's a book called The Manager's Path, I think. Okay. Um, let me just make sure, yes.

The manager's path that is, uh, particularly, this is a, it's a specific book around, uh, tech, uh, tech leaders. So if you're like a technical leader, so that's something that I've found to be really useful. Um, but there's. Ooh, books. I, I would actually, I sometimes find blog posts more useful than books. I, I, I wish I could remember the blog post, but there was a blog post that, that came out recently or that my friend me sent me recently that was about like, unlocking the secret for like, how do you make your boss happy?

Uh, and it's like, and it's like, do things that make their life easier. Uh, make sure that your impact is visible. Uh, and make sure you're working on things that the company cares about. And it's like, I love the blog posts that are like, [00:37:00] demystifying how to like, get promoted, uh, or like, make your boss happy.

I kind of love those. So like I, uh, manager's path is good, but then blog posts are really good. And then I have some, like other things, if you're specifically a people manager, I can always, uh, recommend that I have a list of, but generally I think that's where I'd go. 

Mehmet: Cool. Now. Kind of a cliche question as we are almost coming to an end.

Mm-hmm. Um. Can trans in, in, in engineering, you know, in general, Mary, like what, what's the most, uh, technologies that are getting you excited? AI for sure. But other than this, 

Mary: yeah. Um, let me see. What is getting me most excited? I think the technologies that get me most excited, and maybe it's just my background, are new technologies that are allowing people to.

Uh, develop and deploy faster. And so like, yes, AI tools, so like code generation tools are a great example. [00:38:00] I'm really excited about them. Uh, they could be better. I. They're getting better. They could be better and they're getting better. Uh, and so I'm excited about that because it just reduces engineering toil.

Um, you know, why write a bunch of tests that are super boring or formulaic when something can do that for you? Yeah. So like, I, I love that. Uh, so I, I know you said other than ai, but like AI code generation tools, I'm excited about 'cause it reduces engineering toil. Um. I'm, I'm, I'm still excited about like, uh, Kubernetes and like space lift and, and like, and deployment strategies.

Uh, so like I'm, I'm still excited about that sort of thing and I think it's just because I still get really excited about how do we reduce engineering toil and help them do, uh, what they need to do. Um. Maybe I'm kind of boring. Like all the things I get excited about are like, you know, Kafka and like things that have been around for a while.

Mehmet: No, no, not, not at all. Not at all. Yeah. But to your point, like it's more the automation stuff. Mm-hmm. Like, uh, by the way, maybe people who are technically will [00:39:00] understand, I mean even these ai uh, co-generation tools, so they have a lot of automations in the background, like where. Imagine they, they, they will create the instance for you.

It's a Kubernetes instance, by the way, and then you have the database and you have everything and everything's happening in the background. Don't need to write single line of, as we used to call it. I mean, maybe you still call it Marie, I don't know the infrastructure as they call. Mm-hmm. Like you just put it in a terraform and then you just put it and you send it anyway.

Mm-hmm. So I don't want to to go too much technical, but yeah, it's, it's very exciting. Um, final thing where people can. You know, learn more about you and, uh, maybe get in touch. 

Mary: Yeah. So, um, you can find me on LinkedIn, Mary Moore, Simmons. I, there's very few of us. Uh, maybe none but me. So the, that's, that's I guess the benefit of having a really long name.

You can find me on LinkedIn. Um, uh, my GitHub handle is MMS, the Pizza Thief. So if you wanna find me on GitHub, that's where I'm at. Um, I think those are the two [00:40:00] places. 

Mehmet: Cool. Uh, so for the audience, you don't need to. Search a lot. I'll make the life easy. I'll make everything in the, I'll put everything in the show notes if you're listening on your favorite podcasting app, or if you are watching this on YouTube, you'll find it in the description.

Uh, Mary, I really enjoyed the discussion. I, we tried not to be too much technical. We tried also not to be, uh, I would say talking only about leadership, so I think. And hopefully, uh, we had a engaging discussion. Thanks for you. Of course. And, um, this is usually how I'll end my episodes. This is for the audience.

If you just discover this podcast, thank you for passing by. I hope you enjoyed it. If you did, so please give me a favor, subscribe and share it with your friends and colleagues. And if you are one of the people who keeps coming again and again, I can't thank you enough because you know this. Past two, three months are phenomenal for the podcast.

We are on the top 200, uh, apple Podcast charts in six countries at the same time. So this is something I didn't see in the past two and a half years. This [00:41:00] cannot happen without two factors. First, my guest, you, Mary, we are one of them now. And of course, the audience. I really appreciate all your support, and as I say, always stay tuned for any new episode very soon.

Thank you. Bye-bye. 

Mary: Thank you.