Why Engineers Must Become Multipliers in the AI-Era

Gregor Ojstersek argues that modern engineers must become multipliers: they amplify their team by improving processes, mentoring, and raising quality rather than just writing code. AI tools make individual output faster, but the real leverage comes from human skills, problem-solving, and resourcefulness across tech stacks.
Chapters
If you compare skills that make you a good engineer now versus 10 years ago, those skills are quite different. 10 years ago, you could get a job as engineer just by knowing HTML, CSS, JavaScript, and one additional JS framework. But now tools for development have gotten quite better, and the desired skills for engineers have moved just from pure knowing programming languages and frameworks to problem-solving abilities and people skills. It's less about the tasks, but how big of an impact you can create. And engineers who can create the biggest impact have the multiplier mindset. If you don't know me yet, my name is Gregor Ojstersek and I am the founder of Engineering Leadership Newsletter. And in this video, I'll be sharing why engineers must become multipliers in the AI era. Now let's get straight into today's topic. Okay, so let's first talk about why actually the way we build software these days has fundamentally changed. And we mentioned a bit about this before, that, you know, building software 10 years ago versus now is totally different. But, you know, tools are much better right now, and we can see being, you know, coding and building software being accessible to to other people, not only engineers as well, like, you know, tools like Lovable, Replit, and so on. They offer a chance to people to just, you know, create software via prompting. But the problem is that, you know, if you are building software that way, it's hard to build software that is maintainable, that is scalable, that is going to be, you know, good in security and so on. And that's where AI-assisted engineering is the way to go. And AI-assisted engineering means that, um, you are building software by using and utilizing all of different tools, but at the same time you still keep in mind the core great engineering fundamentals as a first priority. So you use AI when it makes sense, not everywhere, but you use it to actually make you more productive and better. And, um, yeah, so that's in my opinion one of the best ways to, to build software these days is AI-assisted engineering. Pure web coding is just for, uh, you know, building quick prototypes or potentially building internal tools that are not less— that are not so critical and are more presentational as well. And also important to mention is that engineers are less expected to just work on pure requirements these days. Engineers are getting a lot closer also to the why, to the what, and the when, not only the how. That is something that we're going to talk about next. This is something that Migda Jaffer, OpenAI's product lead, has mentioned. And we can see this happening already in a lot of startups and smaller to mid-sized companies. And a good example is for, for example, Lovable is that, that good example is one of the fastest growing startups in Europe, they don't hire product managers. They— their engineers are owning the full lifecycle, right? They provide the ideas and they provide the initiatives on what things to build, why to build, and also when to build them. And then they also own, you know, the how part as well. Obviously as engineers. So I see this happening a lot more and more across the industry in many different companies, and it makes a lot of sense, especially when we're going to talk about later in this video about, you know, many companies deciding to flatten the orgs, organizations, and, you know, unfortunately doing a bit of layoffs to middle managers. But with that expectation comes that, you know, more and more engineers are taking additional responsibilities. And that means, you know, being more self-managed and taking initiatives themselves. So yeah, you can see how big of a difference it is between, you know, being a great engineer 10 years ago, you needed to only know and understand one programming languages and one framework. For example, if you knew React or knew, you knew Angular 10 years ago, you could get a job really, really quickly. But right now that is already expected, right? That is something that, you know, people that hire engineers already think that, hey, this is what you should know and this is additionally what you should be good at. So yeah, right now it has changed drastically on what does it mean to be a great engineer. As we mentioned before, as tools have become better and better, What really becomes important are the human-related skills and being good at problem solving. And as I mentioned, you know, this is already expected, you know, having good engineering fundamentals and understanding the technologies that, that you work with. But ultimately where you want to be is being an engineering multiplier. And this is what is actually, let's call it, the 10x engineer in the AI era is the one that is an engineering multiplier. So let's talk about what does actually this mean next. Being an engineering multiplier means that you are making others around you better. You amplify the productivity and effectiveness of everyone around you, not just, you know, focusing on your own output, but also elevating the entire team. So ultimately, you focus on finding impact yourself, making everyone around you better, finishing the project that are going to be, you know, provide value to the business, to the organization, to the team, to the customers as well, and so on. You're not just focusing on your own tasks and, you know, on having clear definition of what is expected to be done, but you are actually the one who is looking proactively to find impactful work and filling in those missing pieces. Those are exactly the skills that are going to be more and more important as time, time goes on, as tools are getting better and better. Things that you can do without, you know, being, being, for example, being managed, right? You need to be told what, what is important and what not. You know already, you, you, you proactively find out the problems and, and focus on them. And, you know, at the same time, you're sharing, you're sharing your knowledge or you're, you're mentoring and you're mentoring others around you. You're helping others to be more efficient, more effective, and so on. That's what actually being an engineering multiplier means. And engineering multiplier is actually the combination of words engineering, obviously engineering, and then force multiplier. And force multiplier means exactly that is, you know, making, let's say, 5, 10 people around you better. So it's kind of a good combination of engineering and also being a force multiplier. Okay. So yeah, let's, let's talk about how this looks like in practice. So let's go to the first one, which is, you know, improving team efficiency. That may be you write a certain documentation, you write a certain guideline, you write a certain style guide, you provide certain— you find certain tools that make everyone around you better. You provide workflows, you provide improvements for suggestions to make the full process, the whole process better. You actively challenge requirements for certain projects and provide simpler solutions. You find ways to to improve the whole team and the project that, that, you know, the whole team is working on. The second thing, you know, you share knowledge, you don't keep knowledge to yourself because the problem is with doing that you become a bottleneck, but you actively look to help others around you by ensuring that whatever you're learning, you're also sharing. And also a good thing about this is that you also learn yourself a lot more when you're sharing knowledge than actually keeping knowledge to yourself. So it's a win-win activity. You learn something, you share it, you actually know it a lot better. You also raise the quality bar. That is very important. Like, for example, you're always looking for tools to improve the code quality. You're looking to, you know, to make good peer reviews. You are looking to, you know, to do technical mentorship of the people that you work with. You're always looking to improve you know, the way things are getting built, improve the quality of the, of the code that is actually being, being deployed to production, looking for tools and looking for ways to improve that, and so on. Also, you enable better decisions, you know, focus on building the right things, and then the— focus on building the right things first and then building the things right. That is very important. You make sure that, you know, whatever is getting built is going to be helpful to the customers, the users, is going to solve their problems. And we mentioned also, you know, you mentor and empower others, you make everyone around you better, and so on. You are onboarding new engineers, you make sure that onboarding documentation is, is, is done correctly. And so you're not just, you know, focusing on pure tasks that are assigned to you, but you look for proactively making things around you better. Those are the skills that are going to be more and more important as, as time goes on. And let's put this into actual, you know, kind of actual real, real-time scenario. And obviously you've probably seen this, this meme before around social media. And this is a meme where like there's, there's high expectations of, you know, of a certain job, job description. And those kind of things are becoming more and more common in our industry. And I've seen this in different companies, try to look for, you know, a lot of different skill set. But the reality is that the companies don't really need all of this. You know, you need to be an expert in all of these technologies in order to do well in the position. That's where, you know, a lot of companies are getting it wrong. Instead, they're actually looking for engineering multipliers. They don't need an expert with all of this this skill set. Even if, if it's written like that, that's not actually what, what they need, and it's not even realistic. It's impossible to be an expert in all of these technologies. So what actually, uh, this looks like in practice, like if you are— they're actually looking for engineering multipliers and not every— not someone that is expert in all of these technologies. So for example, you're an expert in Python and you can apply your knowledge in understanding, you know, Python as a programming language in also like being productive in Java and PHP if you need it. And you can do that by using AI and also understanding, you know, good programming fundamentals because, you know, and you work with Python for a long time, so you have a good understanding of programming fundamentals. And the same thing you can do with, you know, Angular. Like, for example, if you're good in React, you can learn Angular if needed by being resourceful. That means you can go and check tutorials, you can, you can ask, you know, other people who are experts in Angular Angular. You can, um, you, you can— there's so many different resources available that for you to learn Angular. Similar with, you know, uh, with learning MongoDB. If you're an expert in— sorry, if you, if you work with PostgreSQL and Redis before, then you can also learn MongoDB because, uh, you know, it's, it's quite similar mentality with PostgreSQL but just, just a bit different concept with with documents and not tables, right? But, you know, because you understand how databases work in general, you're going to be able to grasp how MongoDB works as well. Obviously, you're not going to be an expert, but the thing is that you can consult with experts on particular topics when you need it. And that's where, you know, being resourceful is very important. That's where engineering multipliers are doing, you know, That's what engineering multipliers are actually doing. You know, they look for people in their network, inside a company, inside an organization, and they look for experts in particular people and they work with them to, to learn and help them in particular projects and so on. Similar with, you know, AWS S3, if you know that already, you can, you can get, you know, you can learn more detailed specifics on AWS as well. You can do that by asking questions to others or you can also check tutorials and so on. And, uh, yeah, similar with that, with every other, other thing, uh, you know, Unix system administration. If you, if you worked with Windows sysadmin before, you can, you can then, um, you understand some of the concepts behind it. Similar with Git, CI, and TDD. Obviously those three things are not that really connected. Obviously Git is something that you probably work with a lot of times before. CI/CD is something that obviously a good you know, it— every, every good project needs to have a CI/CD pipeline. And then TDD, you know, even if you haven't been working with TDD at the moment, uh, if you've been doing some, some testing, integration testing, unit testing, you, you can quickly grasp the concept of TDD as well. And similar with Docker and Kubernetes, if you understand Docker, you will even more easily be able to learn Kubernetes. So the key here is that, you know, You are, you are not a person who knows everything but is able to learn if it's needed. That is the key thing. And that is, that is what actually engineering multiplier means. So this is the full formula, right? With good human-related skills, with good people skills like leadership team or good communication, being a great person to work with, empathy and over-emotion intelligence, intelligence, and also being good at solving problems, being pragmatic, being resourceful, utilizing AI tools. Business understanding, deep— having a deep understanding of a relevant topic. With those skills, you can learn or get everything you need and to provide impact. You can make an impact in any project. So always, always keep this in mind. Have the right tool belt, tool belt, to develop the right tool belt of skills that you can learn or get any specific information as you need. That is the biggest leverage in the, in these times. It's not about how much things are you knowing right now, but how fast you can get what you need when you need it. Always keep this in mind. So yeah, and also the last but not least, uh, least thing is obviously you, you've, you've heard about, uh, the trend about flattening the orgs, especially in big tech like Amazon, Microsoft, and potentially some other companies, um, they are doing layoffs. A lot of, you know, the middle management is unfortunately being affected by some of these layoffs, and companies are looking to have a bit more reports reporting to one manager, right? Maybe like some time ago there was like 5, 6 reports to one manager, but now it has grouped, for example, to 8 to 10 reports. And what this means is that automatically when a manager has more people that are reporting to them, it means that more engineers are expected to be self-managed and self-starters, self-initiative, self-initiative to do and find impact, right? That is exactly what we have been talking about today. And, you know, being proactive, being a person that is proactive, looking to find impactful things to work on This is what is the most— this is what is becoming the more and more expected thing in current times and is going to be in the future as well. So yeah, I hope this was, this was helpful. If you want to learn more, you can subscribe to my newsletter. It's called Engineering Leadership. There are more than 170,000 people already reading it, and I publish 2 new articles every week. So yeah, that's it for today, and I'll see you on the next one.
More from Gregor

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









