How AI Is Changing Engineering Leadership (2 Biggest Impacts)

Gregor Ojstersek explains how sensationalist AI hype from leaders like Zuckerberg and Amodei is driving premature adoption and tanking team morale: 51% of engineering leaders see AI as a net negative, and motivation dropped 38% in a year. Second, AI is collapsing job titles as managers, architects, and product engineers merge into one role.
Chapters
Okay, thanks a lot for the kind introduction. It's really great to be here in London with all of you guys. We have a really exciting topic we are going to be talking about today. It's something that a lot of people are wondering what's actually happening across our industry, how AI is impacting engineering leadership in general. And yeah, today I'm going to be sharing 2 main impactful things that are happening for engineering leadership because of AI. But before we get straight to the first impactful, impactful thing, let me share a little, a little bit more about myself. I have over 12 years of experience both as engineer and also engineering leader. I grew from engineer to senior software engineer to team lead and then to, uh, engineering manager, head of engineering, VP of engineering, and then CTO. And I currently work as a fractional CTO and advisor, and also as a coach and mentor. And also, most people know me from writing the Engineering Leadership newsletter, where I share 2 articles every week. And also, I teach a course. It's called Senior Engineer to Lead: Grow and Thrive in the Role. I helped over 200 students already to be able to get insights on what to do to be successful, to grow from senior engineer to lead position. And also, my overall goal is to help as many people as possible to become great engineering leaders. That is my number one goal. Okay, so let's start with our first, and in my opinion, most impactful thing that I'm seeing across the industry. And that is that, um, we don't see the slides. Okay, amazing. Sorry. Yeah, 51% of engineering leaders believe that AI is impacting the industry negatively. This is the first impactful thing that I am seeing. And of course, we're going to see also these slides soon. But, you know, when I first saw this data, I saw— I wanted to really check what's happening. What's actually— what is the cause that 51% of engineering leaders don't believe that AI is impacting the industry basically positively, but they believe it's impacting negatively? Thanks. Thanks a lot. And yeah, this is, by the way, from the Lead Devs report. They interviewed more than 600 engineering leaders across the industry. And yeah, when I first saw this data, I, I went straight into why actually that is the case. And we're gonna, we're gonna check it. We're gonna go through exactly why that is the case soon. Before we do, this is also a really important data as well, which tells us that engineering teams today are less motivated than they were 12 months ago. So you can see from the data, 38% are less motivated, only 14% are more motivated. So those two things go, go hand in hand together. Um, so yeah, 51% of engineering leaders believe AI is impacting the industry negatively, and a lot of engineering teams are less motivated today than they were 12 months ago. So the question, why is that? Why is that happening? What is actually the reason for that being the case? Yeah, so I dig through and I went and discussed with a lot of engineering leaders and engineers across the industry, and this is the finding that I came about. So it all starts with sensationalistic predictions regarding AI from non-public individuals. You guys have seen a lot of such takes across the social media, across different media sites. For example, I'm going to be sharing 3 main examples. The first one, Mark Zuckerberg saying that AI will be replacing mid-level engineers by the end of this year. It's, it's coming to the end of this year and mid-level engineers are still, still doing their work on a daily basis. And then the second one, we have Anthropic CEO Dario Moday mentioning that AI could spike unemployment to 10-20% in the next 1 to 5 years. And also he mentioned that AI could wipe out half of the entry-level white-collar jobs, which is very sensationalistic. And to be honest, it also kind of like scares a lot of people because of, you know, those statements. And also Amazon CEO Andy Jassy saying that AI will reduce its corporate workforce in the next few years. You know, whenever a company leader or a prominent figure in the industry says things like that, it inspires fear, it inspires It inspires fear of missing out. That is, that is what it inspires. Because those people are saying like, we have this new shiny AI tool and we are, we are, we are developing this new, new technology. And then a lot of company leaders across the industry are feeling like, okay, we need to adopt this new AI tool, we need to use this new technology as much as possible. And what they try to do. They try to enforce it inside their companies, or they try to enforce certain AI tools to be used for either certain reasons, productivity reasons, and so on. But they don't actually have the understanding, what is this actually going to contribute to success for the company, for the organization, and so on. So as you mentioned, company leaders are experiencing FOMO when it comes to AI. So first it starts with sensationalistic takes coming from prominent public figures. And then because of that, company leaders are experiencing fear of missing out. I'm going to be sharing two of the main examples. The first one is the memo from Shopify's CEO that has been sent out not so long ago. And basically what Shopify CEO mentioned is that, you know, they wanted to enforce AI across the whole company And 3 of the most important things from the memo. The first one, AI improves productivity up to 100x, which is quite interesting. The most I've been hearing is about 1 to 2x from many different engineering leaders and engineers across the industry. And the second one, including AI usage as a KPI for the performance review. That is also another one which is very interesting because, you know, You guys know if you try to— what you measure becomes a target, right? And if you measure just pure usage, AI usage, how many AI tokens does a particular person use, they might set up a cron job, they might set up a recurring task that is going to use as many AI tokens as possible, and they're going to be on top of the leaderboard, but they will not actually contribute to anything useful. That, you know, if you're tracking that, that's going to happen. And I'm sure that's happening across many different companies already. And also the third one, demonstrating that you can't do what is needed with AI before, you know, asking for more headcount. Again, this is similar to what Andy Jassy mentioned. You know, we're going to have less people in the upcoming years. When you're saying things like that, people automatically feel less motivated to do things, less motivated to contribute. Psychological safety is a really big thing in high-performing teams. That is very important. And if you're saying things like that, that is going to unfortunately negatively affect the psychological safety in teams. And now let's go to the second example. Second example is the memo from Fiverr CEO saying that AI is coming for your jobs. And yeah, you know, things like that are happening a lot more regularly than we might actually realize. They are a lot more common they are just not as public as these two examples. And I've heard many stories from engineering leaders, engineers, and also company leaders as well, asking me different questions. I saw as well, I see regularly, for example, like CEOs of startups or mid-sized companies trying to do wipe coding of a homepage of their personal company website. And also trying to do wipe coding of the first page of their application and then saying to engineers and engineering leaders, look how easy that is to develop. Because you can just do a quick prompt and it will actually do like 90% of the visual stuff that is needed to actually do a company website. But at the end of the day, those are just quick prototypes. They are not actually working things that are going to be scalable and maintainable in the long run. And a lot of company leaders don't understand that. And because of the fear of missing out, and then again, they try to enforce the usage You know, that's where the big impact comes on engineering leaders. So yeah, the first starts with sensationalistic takes, then it trickles down to company leaders fearing, feeling that they're going to be, you know, missing out on things. And then this trickles down to engineering leaders and teams operating within unrealistic expectations. As I mentioned, you know, when a CEO or another person part of a leadership team comes to you and say like, okay, we need to use AI for this, we need to use AI for this, this. Those are the unrealistic expectations that a lot of teams are, are facing these days. And that, that is the reason why many of the engineering leaders believe that AI is impacting the industry negatively and why engineering teams are feeling less motivated today than they are feeling 12 months ago. And I've also heard some of the interesting unrealistic expectations over the, over the industry as well, believing that AI is a plug-and-play solution, expecting AI to eliminate all of the manual underestimating the cost and complexity of building internal LLMs. A lot of company leaders believe that we can just build LLMs internally, foundational models, and that that's going to be, you know, as easy as just, okay, building a quick prototype. But we all know, like, building a foundational model is going to take a long time, it's going to take a lot of people, it's going to take a lot of knowledge. Instead, a lot of times the solution might be just calling a foundational model like GPT and get you know, do some computing there and then get results back. And also assuming AI will just magically understand the whole context of a specific domain. We all know, you know, if you don't share the context, you can't expect the, the best results. And the more context you share, the better the results are going to be. And also expecting AI to replace entire teams, assuming AI would just work without failures, thinking that there are no ethical, legal, and security risks. And also assuming AI will just exponentially increase the performance over time. It's going to just at least exponentially increase over the years and so on. Those are some of the most common unrealistic expectations I'm hearing. So to summarize, sensationalistic takes by non-public individuals, company leaders experiencing fear of missing out and enforcing AI usage and AI feature development, and then engineering leaders and engineers need to operate with unrealistic expectations. That is the main reason for a bit of a negative sentiment regarding AI for engineering leaders and also engineering teams. So the main question is what to do, what actually we should be doing as engineers and engineering leaders. And I'm also going to be sharing some of the, some of the tips for company leaders as well. So let's, let's get to that next. My advice for company leaders and engineering leaders. So the first one is it all starts with doing what's the best for the business. Don't try to believe— first is, this is for company leaders— don't let fear of missing out get to you, but always focus on setting the right set of goals and ensuring that, you know, your business is going to be successful. That, that is the most important thing. Don't try to just implement a new shiny tool because, you know, everyone else is using it, or you heard it somewhere, you heard it on social media, and so on. A lot of Big traps are set up because of it. And also, I've seen many cases where companies try to do full AI transformations all at once, and it backfires, unfortunately. I don't recommend doing that to most companies. We've seen example from Duolingo. Duolingo did a full AI transformation and completely changed their application and the way they operate in the business. And a lot of people didn't like that. A lot of users actually stopped using Duolingo because of it. So my recommendation, you know, It may work in some cases, but in most cases it will actually backfire. So starting small is the way to go when it comes to adopting AI and trying out different AI tools and so on. And also, this is very important thing to understand is there is no better productivity hack than a great culture. Great culture is always going to make everyone more productive than a shiny new AI tool or any other tool in general. This is very important to understand. Now let's go to engineers and engineering leaders. So yeah, the thing is, when you are managing expectations with the stakeholders, with the leadership team, first of all, you need to educate yourself. You need to ensure that you know what's out there and also, you know, what's possible and also what other companies, other organizations, other engineering leaders are using. And this event is a great, great way to know that more in detail. You know, you guys can talk with each other and see like, okay, this works this works well. Okay, this, this is working for us, and so on. You need to, you need to be informed. That is, that is crucial. And then the second thing is you need to be confident, because when you're dealing with managing expectations from company leaders that, that are feeling FOMO, they will try to persuade you in so many ways that you should do this, or you should do that, or we should adopt this new tool, or we should do that particular process, and so on. You need to be confident and you need to say no. You need to— the last thing you want to do is just say yes and then just completely, and just completely start implementing it, right? That is the, that is the worst thing you can do. And yeah, small experiments and then, you know, measure the impact of the productivity. That is my recommendation. Start somewhere where it's not as much big impact. Try a new process, try a new tool. And then if that works correctly, then you can move it to, to some other parts as well. And also, this is very important part for all the directors, VPs, and CTOs. You need to own the AI strategy. You should not be waiting to be looped in on the strategy. What happens a lot of times is that engineering leaders or engineers get put into the room where they are already discussing the implementation of certain AI tools. No, this is not the way to go. You need to be the one who is driving it. You need to be the one who is driving the AI strategy, who is saying, okay, this is the tools that we should be using because of this, this, this reasons, and those are the best possible things that we should use in order to increase business value as much as possible. By the way, this is from Migdad Jaffer. He's a product leader at OpenAI. We recently did a collaboration on, on my newsletter. And he mentioned, don't wait to be looped in on AI strategy. You should be owning the AI strategy as an engineering leader. You are the strategy. This is what he mentioned. And what he means by that is that engineering strategy equals to AI product strategy. When we're talking about AI strategy, the how, how part is very, very important. It's crucial to understand how we are going to build a certain thing with AI. Let's say AI feature or AI product, or even like adopting a new AI tool. It can be the difference between building something in 3 days or 300 days. As I mentioned, building our own foundational models or, or using already made models, right, for doing something. The only thing that my— and big— my big recommendation to engineering leaders is to also start owning the what, when, and the why when it comes to AI strategy. That means get better at product, get better at business understanding, because you already understand the how part. That is crucial. That is very, very, very important in AI era. Nobody— non-technical people will not be able to create, to make as accurate decisions as engineers and engineering leaders can do. And this is also a great picture from, from Migdad Jaffer. This is what he mentioned. This is the traditional product strategy that was before, and you can see the ownership is based on many different departments, including product management, design, finance, UX research, QA, and procurement, and so on. And now a lot of things are moving closer to engineering because the whole part is very crucial. A lot of other departments don't understand what it, what actually it takes to build stuff with AI. Experimentation is very crucial, is very important. And as I mentioned, you know, if you're building something with AI, you need to really understand how you're going to tackle that. So a lot of that is moving closer to engineering. The only thing that is important for all the engineering leaders, you guys already understand how to do, how to build things, how to do things. The only thing that is important is to also learn the business and the product skills in order to support the what, when, and why. Okay, that, that has been the first impactful thing that I'm seeing across the industry. Now we're going to be talking about the second one. And the second one is that engineering roles are getting closer and closer together. That, that's what I'm seeing talking with many engineers and also engineering leaders across the industry. And we can see already expectation from engineering managers to take on staff engineer roles if needed, staff engineer roles to take on manager hats if needed, and then also architects taking on staff engineer role or manager roles if needed. You know, those three roles are getting just closer and closer together, and I believe over time the titles are going to be just more blurred between them and, and So yeah, that is the first thing. And the second thing is the product and engineering is getting closer and closer together as well. The role of a product engineer is being more and more popular. We can see in a lot of— I can see already in a lot of startups, they actually— a good example is Lovable. Lovable don't hire product managers. They hire engineers who are product focused. They basically, if you check their careers page, they don't have a role open for a product manager. They have their engineers. Initiating requirements, initiating the, the, the features, proposing solutions, and then also owning the implementation. And that is going to be more and more common, I believe, in our industry, starting with smaller companies and then also moving to, to, uh, to bigger and larger companies. And why I believe that is the case: we've seen layoffs happening within multiple companies, and when there are less people in the company, then of course existing people are going to be more, you know, they're taking more additional responsibilities. And also we've seen Amazon's initiative to increase the ratio of individual contributors to managers by at least 15%. And as soon as Big Tech does something, then also like other companies are trying to mimic that, and we will see more companies trying to do that as time goes on. And also the tools for development are just getting better and better, and as tools are getting better, that's automatically going to shift the expectations to be bigger, to be larger. As I mentioned, the titles are going to be blurred as time goes on. And also, you know, being good at many things will not be a nice-to-have, but a must-have. That is my opinion. To help you with this, you know, what to do as an engineering manager, engineer, and architect. Let's go to that next. I've dissected what are really important skills to focus on focus on in the AI era. The first one is human-related skills. Those are people skills, leadership, teamwork, good communication, being a great person to work with, empathy, and overall emotional intelligence. Those are very important skill sets that, you know, AI can't do this stuff anytime soon, and those are just going to be more and more important, human-related skills. And then also the second one is being good at solving problems. It's not, you know, 10 years ago you can basically you can, you need to, you needed to know one programming language and one framework and you would be considered a great engineer. But today you need a lot more, right? You need to be a good problem solver, you need to be pragmatic, you need to be resourceful, you need to know how to utilize different tools, you need to have a good business understanding as well. And also you need to have a good and deep understanding of a relevant topic that you work with, that you work with. Fundamentals are going to be just, just more important as time, time goes on, especially when tools are getting better and better. Focusing on having good fundamentals are just going to be more crucial. And to help you with this, I prepared a list of resources that, you know, you can all check, and there are going to be a lot of helpful tips there to, to get better at all of these skills that I mentioned before. You can just scan this, this QR code, it will take you to the landing page, and all you need to do is— you guys will see also the template for, for an email. You guys just need to send me an email and I will grant you a complimentary one-month paid subscription to my Engineering Leadership newsletter because some of the articles that are on the resources are actually paid articles to the, to the Engineering Leadership newsletter. So yeah, that's it from me today. If there are any questions, I'm more than happy to answer.
Skills that you mentioned, for me those are not necessarily new, right? Interaction with people, good communication, But what I have seen is that engineers themselves, like, part of their craft is changing. Yeah, some people really loved hands-on coding. That is completely gone, which means they will be demotivated, or you might, as an engineering leader, need to motivate them in a different way. What have you seen with the people you've spoken to that actually works well for still inspiring people and motivating?
Yeah, it's, it's interesting, you know, the— we need to get to the roots of software engineering, right? Software engineering is not it's not just coding, it's actually solving problems.
Yeah.
And you need to do what it takes to solve the problem in the best way. Writing code is just one way to solve a problem. So a lot of people, I mean, me included, right? I started with programming because I really like to solve, to make things and build stuff and do stuff. And, you know, when you're writing code, it actually inspires you to have like a problem-solving mindset and so on. But you need to think in a way like what is going to be best for the team, what is going to be best for the organization, and do that. Writing code is just one part, and software engineers, you know, it's communication can solve a lot more problems than just writing code can do, right?
Yeah. Questions are coming in. Feel free to, if you see a question, also upvote, so we will handle the ones that are mostly upvoted. And let me see if the highlighting works. There we go. What can you say about actual impact of using AI coding agents on productivity of engineering teams?
Yeah, this is a really good question. I have a separate article on that. I don't know exact data that's happening that actually is giving the exact impact of using AI coding agents, but I know a lot of teams are using that. They're using different tools like Cursor or Cloud Code or something else. And, you know, it helps. It helps a lot. I've seen that across the industry from talking with many many people. Again, you know, as software engineers, it should not be something we should be avoiding it, but it should be definitely something that, you know, it makes us faster. It actually makes us type, type less. The thing is still with software engineering is just writing code and typing code has never been a bottleneck. The biggest bottleneck has always been communication and, you know, uh, how to start with bad requirements, building the wrong things, also bad management as well, uh, bad processes. Those has been the biggest bottleneck, right? Actual writing code hasn't, hasn't been that, you know, that thing that is going to slow you down.
Yeah.
Because oftentimes you need to go and you need to talk with that person, that person, this person, and, and so on. If it's a really untangled, if it's really tangled process, then you need to do this for, for quite a long time in order to understand really what's, what is needed. So yeah, definitely helps. Definitely I see a lot of good things about it, but I don't see like those drastic, drastic improvements.
Gotcha. As a tech leader, how do you evaluate your team's use of AI? How do you ensure they are using it properly?
Yeah, interesting, interesting question. You know, what I like to say is if an engineer opens a PR and you just know it's, you know, coded with, with AI, any kind of AI tools and they don't check actually, you know, they don't have accountability of what they are actually opening, right? Then they're using AI the wrong, the wrong way. The number one thing is that all the tech leads, team leads inside a team needs to ensure that the accountability is still on engineers, right? The wrong thing that you should say is, you know, because of AI outputted that. I've heard that a lot of times, like Cursor outputted that or GitHub Copilot outputted that because that's the reason why this function is built that way. But the thing is that just helps you to be more productive again with typing code, but the accountability is still on humans, so human engineers. So if you as a tech lead are seeing a lot of pull requests that are just badly AI-generated with, let's call it, AI slop. But then you will see that a lot of people are using it the wrong way.
Interesting. I'd like— the lack of ownership, I feel like, is going to get better as soon as we get better at reading and understanding code. Previously, we were doing a lot more writing, and now because of generation, you need to understand exactly what's being written in a different way.
We've been reviewing code. I mean, reviewing code is even— is we spend more time reviewing than actually writing, right?
Yeah.
And that has even increased. I mean, this has been the case before, but now it has even increased to a bigger level, especially working on a larger code base. You're doing a lot more understanding the parts than actually you spending time writing. That's exactly what the case is, that writing code hasn't been the bottleneck, right? And yeah, we need to get better and better at this. I mean, reviewing code is not something that is as fun. I don't know about you guys, but for me personally, I like to write code. It's a lot more fun because you're actually solving problems and you're doing stuff right as you're typing. But when you're reviewing, you need to understand so many parts and it can get sometimes overwhelming, especially if some particular parts are not written as well as well.
Yeah, but it is ever increasingly more important.
Yeah, it is. To review correctly.
What do you think are the motivation of AI leaders to make those unrealistic comments? The ones that create FOMO?
Yeah, good question.
The ones that you shared at the beginning.
Good question. I think we all know the answer to this question, which which is selling their products, which is they're building AI products and many, many people are incentivized to say things that are going to be aligned to increase the sales of their products. So automatically saying things like sensational takes like that is going to say, okay, Meta has a great, great AI or Anthropic is building a great AI and we need to use that. And unfortunately, a lot of people across the industry are believing that is the case. But we all know the reality is just, you know, they can be helpful in certain situations, but they're not going to be the end of all solution to everything.
Interesting. So you think the sensationalism is purely commercial?
Yeah, yeah, yeah, yeah.
Interesting. Let me just ask this one. Oh, all right. How do you let junior colleagues progress in their career if AI can solve most smaller problems? This is a take I've seen before.
Yeah. Juniors then Yeah, this is a good question that I have also seen this decrease in junior engineer roles. That was from a recent report from SignalFire. They mentioned that I think it was around 30% decrease in junior engineer roles in big tech. And yeah, it is alarming. It is alarming. And it's going to be interesting to see what's actually happening in the future of the industry. But my number one thing is build projects. Don't wait to get a job to actually get experience. Try to initiate any kind of side project, any kind of freelance project. And so on. Try to get experience yourself. You need to get experience to get a job, and you don't have experience as a junior engineer. That is like a catch-22 statement, and it's, uh, it's problematic because, um, many people, especially in the United States, they go to a college and they don't actually focus on getting real-world experience, and then they believe they will get a job at Big Tech, but it's not the reality like it was like 5 years ago, 10 years ago anymore. So right now is you need to get experience even without a job. Job. So for me personally, freelance work has been amazing for my career growth, and that is my biggest recommendation for junior engineers, is to try to build stuff, try to build projects, products, projects, try to show what, what you know, and try to be useful as much as possible.
Yeah, I feel like, I mean, this is a room full of engineering leaders. It's up to engineering leaders to inspire people to build things. They won't figure it out themselves. They're like, okay, there's so many people wanting these jobs, junior jobs are slowly disappearing. Yeah, while the senior jobs are actually peaking.
Yeah, yeah, yeah.
Very much hiring seniors, which is, yeah, quite a— it can be quite demotivating. But inspiring people and saying, what do you love with regards to a passion, and then building projects out of that, yeah, it shows that people have already started instead of starting when they get a job.
It is the best way. Also, if you're passionate about something, if you're passionate about sports or anything else, like, it's also going to be a lot more motivating for you to build, to build something. And as soon as you show that you can build build stuff, you know, your knowledge is not just theoretical or it's not just, okay, I did my bachelor's at that university. That's going to be a lot more tangible than just expecting to get a role that way.
Yeah, absolutely. Let's see. First of all, great talk. That's a good compliment.
Thank you.
I'm an iOS staff engineer turned engineering manager, but at enterprise level, leading a cross-functional team. It's not as easy to act as engineering manager and staff for backend. It's, it's a lot of responsibilities. Yes, frontend and mobile at the same time as well. How do you deal with title blur in this case?
Yeah, that's, that's a really good question. And, uh, you know, you need to pick your battles. You can't do everything. You can't be both the best engineer on the team and also the best manager at the same time. Um, and this is, this is something that that is going to be the case, and it's up to you to set boundaries. You need to set boundaries and you need to find people that you trust and delegate work inside your team. That is very important. You need to find people who you know that are good, that have potential. If they, if they are not inside a team right now, you need to get people with that potential inside a team that you can build and you can work with them to grow, to grow them, to take on bigger responsibilities. That means that you need to decide like, okay, Okay, obviously you won't be able to take out your managerial responsibilities because you're, you're an engineering manager, but then the best thing would be to find like people inside your team who can take on different domains and different responsibilities, like someone that is going to be more like a frontend tech lead and another person that is going to be more like an iOS tech lead, and also someone that is going to be more like a backend tech lead, because you can't be an expert in all of these different technologies, in iOS at the same time, in backend, in frontend. I've seen this also problematic in a lot of teams is they have one fixed tech lead and they have a full-stack application, but one person cannot be an expert in all of different technologies. So you want to find people inside your team that you can trust and they are experts in own specific domains.
Cool. Gregor, thank you so much. This was great. There's many questions, so if your question went unanswered, feel free to hit Gregor up in the lunch break and then we'll move on to our next segment. Thanks. Please give a hand for Gregor.
More from Gregor

How I Grew My Newsletter Engineering Leadership to 165k Subscribers in 3 Years









