Engineer to Leader: 10 Insights to Get You Started
- Gregor Ojstersek and Omar Halabieh from Engineering Leadership <gregorojstersek@substack.com>
- Hidden Recipient <hidden@emailshot.io>
Hey, Gregor here 👋 This is a free edition of the Engineering Leadership newsletter. Every week, I share 2 articles → Wednesday’s paid edition and Sunday’s free edition, with a goal to make you a great engineering leader! Consider upgrading your account for the full experience here. Engineer to Leader: 10 Insights to Get You StartedTech Director at Amazon is sharing his top leadership insights!
This newsletter is sponsored by DevStats. Shipping late? DevStats shows you why. Still pretending your delivery issues are a mystery? They’re not. You’re just not looking in the right place. DevStats gives engineering leaders brutal clarity on where delivery breaks down, so you can fix the process instead of pointing fingers. ✅ Track DORA and flow metrics like a grown-up More AI tools won’t fix your delivery. More Clarity will. Thanks to DevStats for sponsoring this newsletter. Let’s get back to this week’s thought. IntroGrowing from an engineer to a leader requires a mindset shift. You become a multiplier for the team and helping others around you becomes one of the main priorities. You are not judged by your individual contribution anymore. The overall success of the team and projects is what becomes important. I still remember my first time becoming a Team Lead -> I made many mistakes. If I could turn back time, I would avoid many of them now that I know what I know. Lucky for us, we have Omar Halabieh, with us today, who is sharing 10 insights on how to adjust your mindset and think like a leader. P.S. One of the reasons I started this newsletter it’s exactly this. To help at least some people to avoid some of the mistakes I made in a first-time in a lead role! Introducing Omar HalabiehOmar Halabieh is a Tech Director at Amazon with over 20 years of experience in the engineering industry. He is also the author of the book Leadership in 60 seconds. One of the resources I highly recommend to become a better leader. I have known Omar for close to 3 years now and this is our 3rd collaboration newsletter article! You can find the first 2 here: The Transition That Changes EverythingI still remember the moment I realized I was failing as a new engineering manager. My best engineer had just quit, my team was behind on every milestone, I was receiving escalations from stakeholders every hour, and I was working 80-hour weeks trying to code my way out of management problems. Sounds familiar? Making the leap from engineer to leader is one of the most challenging career transitions you'll face. I know because I've been there (twice) and have mentored dozens of individuals through this transition. Unfortunately, I've also watched brilliant engineers → people who could architect complex systems in their sleep, completely flame out in leadership roles within six months. The very traits that made you an exceptional engineer, diving deep into technical details, thriving in clarity, working independently, can become leadership liabilities. Leadership, however, requires navigating ambiguity, influencing others without authority, and delivering outcomes through others.
The good news? The analytical thinking and problem-solving abilities that made you a great engineer are valuable leadership assets when applied correctly. Here are the 10 essential insights from my 20+ years of tech leadership experience that will accelerate your journey from engineer to leader: Upgrade Your Mindset1. Leadership starts before your title changesThe biggest mistake I see engineers make is waiting to be promoted before they start leading. But titles follow behavior, not the other way around. Some of the best leaders I’ve worked with never had “manager” in their title. They led through influence, without authority. They stepped up in moments of ambiguity. They mentored others and initiated difficult conversations others avoided. They drove clarity without being asked. They became the person others sought out for advice. Before I was officially a manager, I identified a gap in our procurement system integration with our third-party software provider. The vendor engagement wasn’t part of my official scope, but these issues were impacting the user experience. So I took initiative. I began working directly with the provider’s engineering team, building relationships, identifying edge cases, and co-developing test scenarios to improve reliability. Over time, I became the go-to liaison between the two teams. Not because I had authority, but because I earned trust and showed results. As a result, I reduced integration issues by 70% and cut resolution time from weeks to days. Leadership isn't a role. It's a mindset. And it starts now. Start by identifying one problem your team faces that no one owns, then own it. More articles to learn from: 2. Being right matters. Being effective matters moreAs engineers, we’re trained to seek precision. We value correctness, down to the nth decimal point. But I've seen more projects fail because leaders insisted on being right than because they chose the wrong technical solution. I once spent hours debating the “right” architecture path with a peer. Technically, I had the stronger case. But I bulldozed the conversation and lost trust in the process. We moved forward, but with fractured alignment. Half the team quietly disagreed, implementation was half-hearted, and that project missed its deadline by six months before being quietly shelved. That failure taught me that technical correctness means nothing if your team won't execute with conviction. Now, I ask myself two questions in every disagreement:
Sometimes, effectiveness means putting our ego aside, being willing to be proven wrong, and favoring progress over perfection. It means meeting people where they are. It means listening more than speaking. More articles to learn from: 3. Your success is now measured through othersWhen I was an engineer, my impact was obvious: I could point to the API I built, the bug I resolved, the performance improvement % I delivered. Feedback was immediate and concrete. As a leader, that clarity evaporated. My calendar filled with meetings. My code check-ins went quiet. I found myself staying late just to feel productive, desperately trying to squeeze in “real work” between meetings. I started asking: What did I even accomplish this week? Then a mentor reframed it for me:
That became my north star. I began measuring success through:
Leadership is all about creating leverage and scaling impact: making the team greater than the sum of its individuals. Scale Yourself4. Your calendar is now a product → prioritize ruthlesslyYour calendar is now your most important product design challenge. Every meeting, every commitment, every "quick chat" is competing for your scarcest resource: time (and energy). Get this wrong, and you'll become a bottleneck disguised as a leader. I learned this the hard way when I found myself in 40+ hours of meetings per week → back-to-back calls from 9 AM to 6 PM, eating lunch during standup, and staying until 8 PM just to get through my actual work. I had no time for building deeper relationships or thinking ahead about our strategy. Treat your calendar like you would any other product:
For example, I block my early morning hours (highest energy for me) for deep work. On the personal front, I have my gym time blocked to maintain both physical and mental wellness. Every Friday, I spend 30 minutes looking through the following week's schedule and ruthlessly applying these filters to revise it. Remember: saying yes to everything means saying no to the things that matter most. More articles to learn from: 5. Don't be the hero → be valuable, not indispensableIn my first year as a manager, I made myself the team's safety net. Blocked on a decision? I’d resolve it. Deadline slipping? I’d step in. Production issue? I was on-call, unofficially. I was responding to Slack at 10 PM, joining calls during vacation, and was secretly proud that nothing moved without me. It felt good, I felt important, needed, irreplaceable, until I burned out. Then I realized: if the team can't function without me, I'm not leading. I'm hoarding. So I shifted:
Now, when someone comes to me with an issue, I start with: “What do you think we should do?” That single question has transformed how my team operates. Decision-making speed increased, team confidence grew, and I finally had time for strategic thinking. The ultimate measure of your success? Your team becomes more valuable because of your presence, but they don't need you to function. More articles to learn from: 6. The best code you'll write as a leader is team cultureCulture isn't about ping pong tables and free pizza, it's the operating system of how your team works together. Think about culture like you would think about code architecture. You need to:
I've seen teams with brilliant individual contributors, 10x engineers who could solve any technical problem, fail because they were operating in a toxic culture with backstabbing, knowledge hoarding, and blame games. And I've seen teams with average skill levels achieve extraordinary results because they had exceptional culture → psychological safety, shared ownership, and genuine support for each other's growth. Culture is built through a thousand small decisions: how you handle mistakes, how you celebrate wins, how you resolve conflicts, and how you communicate. Every interaction is either strengthening or weakening your cultural foundation. Remember, as a leader, your actions speak louder than your words. Early in my leadership journey, I worked through illness, thinking I was showing dedication. But without meaning to, I sent the message to my team that health comes second to work and sure enough, I started seeing them do the same thing. More articles to learn from: Communicate to Drive Impact7. Tailor your communication to your audience → engineer ≠ exec ≠ customerOne of the most common mistakes new leaders make is using the same communication style for everyone. The technical deep-dive that excites your engineering team will lose an executive audience, and the high-level strategy that resonates with leadership will leave your engineers wanting details. I learned this lesson during a quarterly business review where I spent 15 minutes explaining the technical details of our caching solution to the Product leader. I was excited about the 30% performance improvement and the clean architecture we'd achieved. Her eyes glazed over, and she interrupted to ask, "Will this make the app faster for users?" I had completely missed the mark. That review ended with her questioning whether our team understood business priorities → a perception that took months to repair. Develop different communication modes:
If you are unsure, do your research about the audience before you craft your communication. More articles to learn from: 8. Clarity over certainty → be clear, even when the path is ambiguousEngineers are trained to seek precision and certainty. In leadership, you'll need to make decisions and communicate direction with incomplete information. The temptation is to avoid communication until you have all the answers, but this creates a vacuum that fills with anxiety and speculation. I used to avoid discussing uncertain situations with my team, for instance during market downturns, thinking I was protecting them from stress. I stayed quiet in team meetings, deflected questions about budget cuts, and tried to act like everything was normal. What I was actually doing was creating more stress through lack of information. They saw me in more closed-door meetings, noticed the sudden change in my tone, and knew something was happening. Their imaginations filled in the gaps with worst-case scenarios. Instead, practice transparent uncertainty:
When I started being transparent about what I didn't know, my team became more resilient, more collaborative in problem-solving, and more engaged during difficult times. Think Beyond the Sprint9. Focus on outcomes, not just systems and featuresEngineers naturally focus on building things. We measure success in lines of code, performance benchmarks, and system uptime. Leaders need to focus on achieving outcomes → business results, user retention, customer satisfaction. The shift from "What are we building?" to "What are we achieving?" is key. I spent three months optimizing our deployment pipeline for our integration gateway, reducing deployment time from 45 minutes to 5 minutes. I worked nights and weekends, refactored our entire CI/CD process, and was genuinely excited to present this major efficiency gain. When I presented it to leadership, their response was lukewarm. One executive even asked, "That's nice, but how many more customers can we onboard now?" Why? Because I didn't tie faster deployments directly to user value or business outcomes, faster feature delivery, reduced time to market, or improved developer productivity that could be measured in shipped features.
Ask yourself:
Start with these questions before you even begin working on your next task. Articles: 10. Process is not the enemy → bad process isMany of us have an allergic reaction to process, viewing it as bureaucratic overhead that slows down progress. This mindset becomes a liability in leadership, where your job is to create systems that help teams work effectively at scale and deliver consistently.
I used to resist implementing any formal processes, believing they would stifle creativity and slow us down. What I learned was that without intentional process, we developed implicit processes that were often worse → inconsistent, undocumented, and prone to breaking under pressure. This was particularly amplified as the team size scaled across multiple locations. Design process like you would design code:
Good process doesn't slow teams down, it removes friction and creates predictable outcomes. More articles to learn from: The Path ForwardThe transition from engineer to leader is challenging because it requires not just new skills, but a fundamental shift in how you define success and create value. The technical skills that got you here are still valuable, but they're no longer sufficient.
Leadership is a journey, not a destination, but every journey starts with a single, deliberate step. Your journey from engineer to leader starts now. Don't just read these insights, choose one and act on it today. Which insight will you focus on first? Last wordsSpecial thanks to Omar for sharing his insights on this very important topic with us! Make sure to check him out on LinkedIn, where he shares regular posts on Leadership Development and Career Growth. We are not over yet! Become an Engineering Leader Everyone Wants to Work WithCheck out my latest video. It’s a recording of the recent lightning lesson we did together with David Weiss in collaboration with Maven. We shared a lot of personal experiences and 6 key traits that make you an enginering leader everyone wants to work with. New video every Sunday. Subscribe to not miss it here: Liked this article? Make sure to 💙 click the like button. Feedback or addition? Make sure to 💬 comment. Know someone that would find this helpful? Make sure to 🔁 share this post. Whenever you are ready, here is how I can help you further
Get in touchYou can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads. If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com. This newsletter is funded by paid subscriptions from readers like yourself. If you aren’t already, consider becoming a paid subscriber to receive the full experience! You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc. Invite your friends and earn rewardsIf you enjoy Engineering Leadership, share it with your friends and earn rewards when they subscribe. |
Similar newsletters
There are other similar shared emails that you might be interested in: