Engineer to Leader: 10 Insights to Get You Started
Tech Director at Amazon is sharing his top leadership insights!
Intro
Growing 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 Halabieh
Omar 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 Everything
I 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.
This transition isn't just about learning new skills, it's about fundamentally rewiring how you think about success, impact, and your role in the organization.
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 Mindset
1. Leadership starts before your title changes
The 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 more
As 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:
What does success look like for the team?
Am I optimizing for having it my way or being effective?
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 others
When 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:
"Your job isn't to write software. It's to create the conditions where your team delivers outsized business impact."
That became my north star. I began measuring success through:
The quality of decisions my team made, especially the ones they made without me
The speed at which they moved from problem identification to solution delivery
The sense of accountability and support across the team → did people feel safe to fail and eager to help each other?
The personal growth of individuals → were they taking on challenges they couldn't handle six months ago?
Leadership is all about creating leverage and scaling impact: making the team greater than the sum of its individuals.
Scale Yourself
4. Your calendar is now a product → prioritize ruthlessly
Your 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:
Define your core "features" (the high-impact activities only you can do)
Eliminate or delegate everything else
Block time for deep work
Batch similar activities together
Set clear boundaries, share modes of engagement, and communicate them
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 indispensable
In 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:
From solving problems to building problem-solvers.
From being the escalation point to designing escalation paths.
From answering every question to asking better ones.
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 culture
 | A guest post by
|