Ship Software Faster with Experienced Engineers (Sponsored)

Finding skilled developers is hard → even for seasoned engineering leaders. Traditional hiring cycles can take months while critical features sit in the backlog.

Lemon.io removes the guesswork by rigorously vetting engineers and matching you with top talent in just 48 hours.

Need to scale your team quickly or find specialized talent that's hard to source locally? They match you with developers from Europe and Latin America who integrate seamlessly into your workflow → without the long hiring cycles or commitment of long-term contracts.

They don't just check résumés, but put developers through a rigorous multi-step vetting process that assesses technical skills, problem-solving abilities, and communication.

Start building faster with lemon.io

Let’s get back to this week’s thought!

Intro

Growing from an engineer to a lead role 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.

Lucky for us, we have Gábor Till with us today as a guest author. He grew from an engineer to Lead Engineer and then to Engineering Manager in his career in the engineering industry.

Gábor will be sharing 5 mindset shifts needed in order to grow from engineer to leader and most importantly become a leader that everyone appreciates.

Let’s go straight into it. Gábor, over to you!

I believed that if I was good at coding, architecture, and problem-solving, then leadership was the natural next step

I though that being a leader would be easy. I’d simply tell others how to solve these problems.

That was a huge mistake.

As engineers, we work with structured tasks. Our to-do lists are full of clear action points: develop a feature, fix a bug, review a pull request. Every task has requirements and acceptance criteria.

But when I became a manager, my to-do list changed. Suddenly, my work was no longer about writing code, it was about making sure the team worked efficiently, that people felt safe, and that collaboration was smooth.

My daily responsibilities shifted to helping others grow, resolving conflicts, setting expectations, and making decisions with incomplete information. The work became less about technical challenges and more about people.

I quickly realized that my technical skills, once my most valuable asset, were now the least useful tool in my new role.

Whatever kind of leader you want to be → team lead, engineering manager, staff engineer, or something else, you need to understand this:

Tech leadership is more about people than technology.

Being a great engineer won’t automatically make you a great leader. But in this article, I’ll show you what you can do to bridge the gap → the mindset shifts needed to thrive in the role!

Let’s go straight into the first one.

1. Foucus on enabling others first instead of you solving problems yourself

As engineers, we’re wired to solve problems. We analyse issues, break them down, and come up with solutions. You’re probably experienced enough to provide quick answers, but one of the worst things you can do is jump in and fix everything yourself.

This is a mistake many engineers-turned-managers make, and I was no exception. Early on, when junior engineers struggled, I would sit down with them, discuss the problem, and immediately rewrite their code. Problem solved, right?

Not really.

My role in these situations should have been to guide them through the process, asking the right questions and answering them in a way that helps them find a solution. In short, to help them develop problem-solving skills.

Instead of teaching them, I sidelined them. Even though I explained what I was doing, the team saw me as someone who would take over instead of guide them.

One of the biggest mistakes I made was when stress from an approaching deadline got to me. I reviewed a feature a junior had written and, in front of the whole team, said, "This code is crappy."

The room went silent.

I had crushed the morale of an engineer who was doing his best.

Shift in Mindset

As a leader, your job is to develop people, not just software. Instead of solving problems yourself, guide your team to find solutions.

Ask questions like:

• What have you tried so far?

• What options do you see?

The key is to encourage them to think critically instead of waiting for answers. Pair-programming, asking questions, and treating them as equals will build their confidence and skills over time.

2. Stop assuming everyone thinks like an engineer

As engineers, we rely on logic, data, and structured decision-making. But leadership isn’t just about engineering, it involves product managers, designers and business stakeholders, all of whom think differently.

Early in my career, I got frustrated when non-technical stakeholders didn’t understand why a feature took longer than expected. My default response was to explain it in technical details.

I talked about architectural constraints, API limitations, and database bottlenecks. To me, it made perfect sense. But to them? It was a cryptic language.

I still remember complaining to my engineering colleagues, saying, "These people have no idea what we’re doing!"

Looking back, I realize how immature that was. The product team didn’t need to understand the tech stack. They needed a simple, clear explanation of trade-offs and timelines.

Shift in Mindset

Learn to communicate based on your audience.

When talking to engineers, provide technical details. When you're talking to executives or product teams, focus on impact, trade-offs and timelines.

Another great technique is storytelling.

Instead of dumping data, frame it as a story:

"Remember the last time we rushed a feature and had to spend two sprints fixing it? If we take an extra sprint now, we can avoid that."

This makes technical decisions easier for non-engineers to understand.

3. Start measuring success the right way

This is one of the hardest habits to break.

As engineers, we measure success by what we personally accomplish:

• How many bugs we fix.

• How many features we ship.

• How many tasks we move to "Done."

But as a leader, success isn’t about your output, it’s about how well your team performs.

As an entry-level manager, I completely lost track of my own productivity. My to-do list was no longer structured, priorities changed daily, and worst of all, I had no clear way to measure my impact.

It was a nightmare.

It took quite some time to realize that my success was reflected in things like:

• How well the team collaborated.

• How confident engineers became over time.

• How effectively they delivered projects, without me being the bottleneck.

Shift in Mindset

Instead of measuring personal output, track team progress:

• How often do team members help each other without your input?

• Do engineers feel supported in their career development?

• How smoothly do projects run without last-minute chaos?

One of the most effective things you can do is to learn to delegate effectively.

The Eisenhower Matrix is a fantastic tool to identify what you should delegate versus handle yourself. Delegation isn’t about offloading work, it’s about giving clear ownership, supporting the process, and ensuring people feel accountable for their tasks.

4. Adjust the way you are giving feedback

Engineers are used to direct, precise, and technical feedback in code reviews.

But when you are in a leadership position, giving feedback is a wholly different skill. A skill that directly affects team morale, growth, and performance.

I learned this the hard way through two major mistakes.

First, I was too soft. I was nervous because it was my first time giving critical feedback. In a 1:1 conversation, I tried to tell an engineer that his performance was below expectations, but I softened my words so much that he completely missed the point. He walked away thinking everything was fine. I had to schedule another meeting later, making the situation even more awkward than if I had just been clear from the start.

Years later, while I was on holiday, someone decided to step in and give feedback to my engineers in my absence, without my knowledge.

This person was too raw, pointing out inefficiencies in people’s work with zero gentleness. It didn’t just demotivate them at the moment, but months later, they were still frustrated by the way it was handled.

Feedback isn’t just about what you say, it’s about how, when, and where you say it.

Shift in Mindset

Good feedback is timely, specific, and constructive, while also being balanced with encouragement.

Here’s what I learned:

• Be timely → Don’t wait for performance reviews. Feedback is most effective when given as soon as possible after an event.

• Be specific → Avoid vague phrases like “You need to improve your communication.” Instead, say “In yesterday’s meeting, you interrupted others a few times. Let’s work on giving everyone space to share their thoughts.”

• Balance constructive and positive feedback → If you only highlight mistakes, people shut down. Acknowledge what’s working too.

• Encourage self-reflection → Instead of just telling people what to fix, ask: "How do you think that went?" This makes feedback feel more like a discussion than a criticism.

A great framework for structuring feedback is SBI (Situation-Behaviour-Impact):

1. Situation: Describe when and where the issue happened.

2. Behaviour: Explain what the person did—focusing on observable actions, not assumptions.

3. Impact: Describe how it affected the team, project, or company.

Example:

"In yesterday’s standup (situation), I noticed you interrupted others before they finished (behaviour). This made it harder for them to share their updates and slowed down the discussion (impact). Let’s try to allow everyone to finish before responding."

5. Focus on emotional intelligence and not just tech skills

As an engineer, I used to believe that technical skills were the ultimate measure of success. The better your coding ability, the more valuable you were.

But as a manager, I quickly realized that technical expertise means nothing if you don’t understand and manage emotions, both your own and your team’s.

At first, I focused too much on deadlines and deliverables, assuming that engineers, like machines, functioned in a logical way.

When one of the engineers suddenly became frustrated and disengaged, at first, I thought it was a motivation issue.

I was completely wrong.

Later, I found out that he was going through serious personal struggles and felt emotionally overwhelmed.

This was a wake-up call for me.

Shift in Mindset

Great leaders listen, observe, and create an environment of psychological safety. Emotional intelligence (EQ) isn’t just a “nice-to-have”, it’s a critical leadership skill.

Here’s how you can develop emotional intelligence:

• Practice active listening → Instead of jumping to solutions, ask: "How are you feeling about your workload?" or "Is anything blocking you?" Listen carefully before responding.

• Show empathy → If a team member is struggling, acknowledge their feelings instead of brushing them off. "I see you’ve been under a lot of pressure. How can we make things more manageable?"

• Recognize non-verbal cues → A sudden drop in engagement, withdrawn behaviour, or avoiding meetings could be signs of stress or burnout. Pay attention.

• Regulate your own emotions → A stressed-out manager creates a stressed-out team. Learn to manage your own frustration before addressing difficult situations.

• Create psychological safety → People should feel safe speaking up without fear of blame or judgment. If engineers fear your reaction, they won’t share concerns until it’s too late.

A highly skilled engineer with zero emotional intelligence can create a toxic work environment.

But a manager with high EQ can build a high-performing, engaged, and resilient team, even if they aren’t the most technically brilliant person in the room.

Last words

Special thanks to Gábor for sharing his insights and experience. Make sure to follow him on LinkedIn and also check out his newsletter Tech Lead Mastery, where he shares similar insights weekly.

We are not over yet!

Senior Engineer to Lead: Grow and thrive in the role

It’s getting close to the start of the March cohort of the course Senior Engineer to Lead: Grow and thrive in the role. We start on March 11!

In the course, we particularly focus on the development of much needed people / communication and leadership skills in order to grow from engineer to leader!

Use code ENGLEADERSHIP for limited-time offer of 25% off or use this link: Senior Engineer to Lead where the code is already applied. The code is valid for the next 3 days!

I want to enroll!

Looking forward to seeing some of you there.

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, 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!

Check the benefits of the paid plan

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.