Engineer to Leader: 10 Insights to Get You Started
Tech 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
✅ Spot stuck work, burnout risks, and aging issues
✅ Cut cycle time without cutting corners
✅ Ship faster. With fewer surprises.
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.
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
Culture 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:
Define clear interfaces (how team members give feedback, escalate issues, and collaborate)
Establish consistent patterns (regular 1:1s, retrospectives, and decision-making frameworks)
Built-in error handling (blameless post-mortems, conflict resolution processes)
Create good abstractions (clear roles, ownership boundaries, and accountability measures)
Maintain good documentation (written team values, decisions, and shared expectations)
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 Impact
7. Tailor your communication to your audience → engineer ≠ exec ≠ customer
One 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:
For engineers: Lead with technical details, show your work, explain trade-offs and alternatives considered.
For executives: Start with business impact, use metrics they track (revenue, customer engagement, cost savings), keep technical details high-level, focus on outcomes and timelines.
For customers: Use their language, translate features into benefits they'll experience, avoid technical jargon entirely.
The key is to work backwards from what your audience cares about, not what you find interesting.
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 ambiguous
Engineers 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:
"Here's what we know, here's what we don't know, and here's when we expect to know more"
"The situation is evolving, and here's how we're adapting"
"We're choosing this path based on current information, and we'll adjust as we learn more"
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 Sprint
9. Focus on outcomes, not just systems and features
Engineers 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.
The lesson: always connect your work to outcomes that matter to the business.
Ask yourself:
How does this technical improvement translate to user value? (Will users notice faster load times, fewer bugs, or new capabilities?)
What business metrics will this move? (Revenue, user engagement, support ticket volume, time to market?)
How does this align with our strategic goals? (Are we prioritizing growth, retention, cost reduction?)
Start with these questions before you even begin working on your next task.
Articles:
10. Process is not the enemy → bad process is
Many 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.
The key insight is to view process as a tool → good process amplifies your team's capabilities; bad process creates friction and waste.
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:
Start with the problem you're trying to solve (Are we missing bugs? Taking too long to make decisions? Duplicating work?)
Keep it as simple as possible but no simpler (A 2-step code review vs. a 7-step approval chain)
Make it easy to follow and hard to misuse (Clear templates, automated checks, obvious next steps)
Iterate based on feedback (Monthly retrospectives: What's working? What's slowing us down?)
Document the "why" behind decisions (So people understand the intent, not just the rules)
Good process doesn't slow teams down, it removes friction and creates predictable outcomes.
More articles to learn from:
The Path Forward
The 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.
Start with the mindset shift. Everything else flows from how you think about your role and impact.
Second, focus on scaling yourself, you can't lead effectively if you're bottlenecked by your own capacity.
Master communication as a tool for driving results, not just sharing information.
Finally, expand your time beyond the immediate sprint to think strategically about outcomes and systems.
You don't need to master all ten insights at once. Pick the one insight that made you think “I needed to hear this” and commit to practicing it for the next 30 days.
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 words
Special 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 With
Check out my latest video. It’s a recording of the recent lightning lesson we did together with
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
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You 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.
 | A guest post by
|
This is such a brilliant and insightful piece. That tension between engineering output and leadership leverage is so real, and it’s easy to miss how much mental reprogramming is required when moving into management.
Designing your calendar like a product is an interesting idea. I’ve never heard it put that way, and it makes the abstract idea of “protecting your time” feel way more actionable. I started blocking out strategic review time on Fridays a few weeks ago. Tiny shift, but the compounding impact has been huge.
If I had one thought for making this even stronger next time, it would be that each of these insights could easily stand on its own as a standalone story post with a single, vivid takeaway. This piece is dense (in a good way), but from my experience as a newsletter ghostwriter, breaking it into a mini-series might give each idea more breathing room and make it easier for folks to act on one shift at a time, like you encouraged at the end.
Thank you so much for sharing 🙌