In this instructional video, Gregor Ojstersek argues that engineers become valuable by independently identifying high‑impact improvements in their codebase or organization and then taking ownership of delivering them. He outlines three main benefits of doing so: accelerated learning, opportunities to lead projects (crucial for moving into lead roles), and a stronger reputation that leads to more opportunities and promotions. He then provides concrete strategies for finding impactful work: tackling recurring pain points that others avoid, actively listening to teammates and other engineering groups, engaging with non‑engineering functions (product, design, sales, compliance) to uncover hidden problems, and understanding broader business challenges to think like a product manager. Finally, he explains how to propose and own the solution, differentiating between quick fixes (just open a PR after brief feedback) and larger initiatives (prepare a written proposal with impact, risks, and approach, discuss it in a one‑on‑one with a manager or tech lead, and volunteer to lead implementation). The talk concludes with a call to share experiences in the comments and a promotion of his Engineering Leadership newsletter.
Chapters
Engineers who truly stand out from others are the ones who find impact independently and then take ownership to implement it as well. This can either be themselves, or even better, bring other team members and deliver the improvement together. Just waiting for tasks to be assigned to you is limiting your growth and also limits the value that you can provide to your team and the overall organization. In this video, we'll go over how you can propose an impactful improvement to the codebase and also own the implementation. So let's start with why you should propose an impactful improvement. As mentioned before, it will show everyone that you're not just here to focus on your own tasks, but you're here to make things better across the organization and also for your team as well. Let me share 3 more reasons why you should do that. The number 1 is that you learn a lot from it. Every time you work on something new, you learn something new as well, and you expand your, your learnings, you expand your horizon. This can either be a new framework, technology, or it can also be a new domain as well. For me personally, whenever I accepted a new project that outside of my comfort zone. I've learned really, really a lot from it. The second one is that you have an opportunity to lead a project. This is especially important for growing toward lead roles. If you wish to grow toward the lead role, you need to have a successful track record of finishing projects and experience leading them. And also the last one, your overall reputation will grow substantially. And with, with your reputation growing, you will receive automatically a lot more opportunities. Plus also the first impression is going to be a lot better. Because of that. And also, you know, with your reputation growing, you will have a lot more chances of being promoted because it shows that you are proactive, not afraid of taking responsibility, and, and also ownership as well. And you also have a successful track record of finishing projects. And that's also one of the main things that managers look for in engineers, that they are able to take not so clear requirements and deliver exactly the needed solution without supervision. That's exactly what I look for. I'm looking to promote engineers who I can rely on to be given a problem and and I just know that they will be able to solve it timely and with the right quality as well. And if you do this enough times, there are going to be unlimited amount of opportunities. Now let's talk about how to find impactful improvements. The first one is to solve problems that nobody wants to. This may seem counterintuitive, but a lot of times you might hear recurring issues inside your team or the organization. This may be some parts of the codebase is really hard to understand, lack of documentation on certain domains or certain parts, lack of tests, and maybe overall confidence in certain parts. When you hear such recurring issues, the best thing you can do is to, is to try to solve them. Your fellow engineers, your manager, and the whole organization will appreciate you for doing this. It also kind of like sets you apart from others because you're showing the courage to face a certain issue, and you also show grid to resolve it as well. The second one is listen to the problems and challenges that your team, other teams, and maybe the overall engineering organization is facing. Listening is going to be your number one asset. And, you know, look for problems and challenges and try to put yourself in, in the position of others, in the other people's shoes, and ask yourself, what can I do to help my team, the other teams, and also the whole engineering organization as well? The third one is talk with people outside the engineering organization, you know, product, design, sales, marketing, compliance, etc. Try to understand their problems. If you understand their problems, you can translate that into specific technical solutions and that can save countless hours for them and that can make their lives a lot easier. And last but not least, understand the business challenges and provide suggestions to resolve them. Make sure to ask as many business and product-oriented questions. That can be to either to your manager, product manager, other people, other business-oriented people. Always keep in mind that a good engineer thinks like a product manager. Now that you know how to find impactful improvements, let's focus on how to propose it. The way you should approach it depends on the scope of the improvement and also the impact behind it. For quick improvements, I highly suggest to, to just do it. You don't need to get a permission to make things better. If it's a quick refactoring, if it's a quick adjustment of a certain part of the code, just create a PR with the changes. If you're not sure about it, get some feedback from your team members first. If it takes more time, my suggestion is to either let your manager, tech lead, or your product manager know about it. The best time to do it is in a one-to-one meeting, and it's always great to have reasons for it, you know, somewhere written. That can either be a specific documentation. That's also what I recommend as well. Create a document where you clearly describe the impact, the risks, and also how you would approach solving it. This will help you a lot in actually being accepted. You want to make it as easy as possible for them to say yes. That should be your, your mindset. And when you propose it, make sure to also volunteer to lead the implementation. This is very important because you make it clear that you want to take ownership to resolve it. That's how you can, you can avoid any misunderstanding.. I'm here curious to hear about your thoughts on how to propose impactful improvements and own the implementation. Make sure to share them in the comments. To learn more, you can subscribe to my newsletter. It's called Engineering Leadership, where I share similar tips and advice on how to be a great engineering leader. There are more than 150,000 people already reading it, and I publish 2 new articles every week. Thank you for watching, and I'll see you on the next one.
