How to Take Care of Your People as an Engineering Leader
Engineering Leader is People Leader
Lately, I’ve been focused in running the 30-day series Better Engineering Leader. In these daily messages, I share insights distilled from two years of writing for Practical Engineering Management, creating a focused six-week journey for engineering leaders. We’re already halfway through!
If you haven’t signed up yet, here are the course details:
Be a Better Engineering Leader Ahead of 2025 – for information on joining via Substack or LinkedIn.
In this article, I’ll continue our series of lightweight overviews of engineering leader responsibilities. In the previous article, "You Build It, You Run It—Things You Own as an Engineering Leader," we focused on software delivery and discovery practices.
Today, let’s shift perspective to an equally essential aspect of our work: how we support and lead our people.
Here, you can find a PDF cheat sheet summarizing this article.
Being a Leader
At its core, leadership recognizes that each individual brings unique skills and experiences. If we only focus on assigning tasks and scheduling their work, we usually don't fully leverage their potential.
Early in my journey as an engineering leader, I’d say things like, "Here’s a well-prepared module—it follows our architectural patterns, has good tests, and aligns with how I envision the rest of the application."
It served nicely when working with juniors or new hires. Such an approach sped up the onboarding process and taught less experienced people. But once the senior engineer came to me stating that some of these things didn't make any sense, I was far from inviting them to the discussion. Only my perspective mattered - my solutions had already solved many past problems, and I protected them no matter what. We did things my way or no way.
If I were to approach it differently today, I would:
Don’t kill the discussion before it even starts.
Clearly explain the problem I solved and what I’m hoping to avoid in the future.
Ask about any issues my approach might bring to the table.
Define essential requirements like quality standards and SLOs.
Collaborate with the team to discuss alternatives.
Being a leader means recognizing that each team member brings a different perspective, and sometimes, they may know things you don’t.
Empowering your team requires providing them with full context about the problems at hand, including strategic goals and limitations. And once you set boundaries, give them the freedom and decisiveness to unleash their potential.
For more on this, explore:
Anti-patterns of leadership touch not only purely technical aspects. They can also occur when a product manager comes to you and says their way is the only valid way to build a product or when a UX designer expects you to implement a custom UI component that will take long weeks, even though there are existing solutions that will take hours to adopt.
Maybe they are right, and their requirements will give the product you build a strong competitive advantage. But more often, they should have invited you to discuss the best solution to meet their expectations…
Being a Manager
Much of the Practical Engineering Management content focuses on leadership and empowerment. In my work as a leader, I want my team to make informed decisions, maximize their potential, partner effectively with product and business teams, and hold strong opinions about the technology they build.
But not everyone is equipped for this. Some people lack experience, internal motivation, or a broader view. Occasionally, they don’t even know what they don’t know. Others prefer straightforward instructions to do their 9-5 job with peace of mind.
Empowerment doesn’t equal “do whatever you want.” I sometimes see leaders avoid decision-making under the guise of team autonomy, which can lead to endless debates. Or the illusion of high performance, where people are convinced that they constantly make good decisions because no one questions that.
Change is non-existent in such teams, and everyone sticks to the good old way of working, even though the landscape of challenges evolves.
Tell Them When You Want Them To Stop
As a leader, invite debates; as a manager, know when to end them. Opportunity windows for product development don't last forever, and you often need to make decisions with incomplete information.
I’ve seen teams bogged down by engineers repeatedly presenting edge cases that delayed progress for months, only for data to later show these cases affected less than 1% of customers.
Were those engineers right? Partly, yes—they wanted to cover all technical aspects. But for the business, it was harmful—months of delay could be easily handled by a few tickets on the Support Center. The engineering leader didn't take responsibility for such a decision and chose to passively observe the never-ending debate.
Tell Them What You Want Them To Do
In my work, I tend to bring a lot of context to the problems I'm trying to solve. For example, when working on stability & quality improvements, I tend to bring rich dashboards with crash rates, number of bugs, etc. I act like empowering leader, no? Show them the problem and let them solve it.
Too often, this is just a naive assumption. Whenever something has any signs of optionality, this will indeed be seen this way. There will always be other, more important things unless you change priorities.
You hold the power. Don't hesitate to tell them very clearly what you want them to do. For example:
"I want you to tackle one existing bug per week,"
"I expect you to fix a critical incident within 30-60 minutes since it was reported,", or
"Before the next meeting, I want you to prepare the list of the slowest endpoints in our API".
Some leaders worry that direct expectations will push engineers away. However, setting clear expectations is your duty and doesn’t equate to micromanagement.
For more insights, see Intro to Expectations Management
Establishing a Clear Path
A start-up you work in began as a PHP backend written by your CTO. However, the company hired another person who must rush with the implementation, so they built a few services in Node. Fast forward 2 years later, company is 10x bigger, a new CTO is moving everything to Java, so it's easier to hire engineers. The smartest guy in the organization seems to be bored, so they bring Scala to the table. In the meantime, the team who maintains your old PHP services don't want to learn Java - they feel comfortable adding more modules in their language.
Here, again, we come back to leadership and autonomy. I experienced the situation from above multiple times. Senior leadership either didn't care about the tech stack or didn't want to lose the smartest guy, so they let them use a new fancy framework just to keep them engaged.
As an engineering manager, you must say “no” when technical decisions deviate from the strategy. Most of your problems can be solved by almost any of the modern languages or frameworks on the market. But any doesn't mean all.
Only with alignment can you optimize for scalability and quality. Build a long-term strategy, and ensure your team’s decisions contribute to it.
For more, check Engineering Strategy Framework
Being a Mentor
The illusion of high performance comes when your teammates think there is nothing else they can learn, and you don't challenge that.
In today's world, as engineering leaders we must balance between setting growth opportunities vs adding new responsibilities people are not paid for (read more How to Manage Gen-Z). Even though I'm against making significant promotions without changing the compensation, I also don't like the approach where people just keep doing what they do for an extended time and expect extra incentives.
As engineering leaders, we must push our people out of their comfort zones. In reality, no one—neither your CTO nor the HR department—knows your teammates better than you. This means it's your primary responsibility to deliver the feedback and growth hints that will make your people more successful.
There are multiple possibilities of doing so:
Teach them to embrace feedback. Constructive feedback is not punishment but an opportunity to grow (read: Mastering the Feedback).
Use training budgets and encourage knowledge-sharing. Set up Engineering Guild meetings, pair programming sessions, thorough code reviews, and demos.
Offer new responsibilities. Moving from a regular to a senior engineer means evolving in approach, not just speed. Let your team members lead projects, speak internally, attend product discovery sessions, or interview candidates. They’ll gain new skills and appreciate the effort required to become a senior.
Your ultimate job as a mentor is to show them what else they don't know and then find opportunity to learn this skill.
Being a Career Coach
Finally, here’s some advice your boss might not love: focus on helping your team grow into the best professionals, even if it means they might outgrow your organization.
While you may not control promotions or raises, helping your team achieve them reflects well on you as a leader.
Help them map their path using the career ladder within your organization, identifying gaps they can work on. (Expectation Management - Compensation, Performance Review, Career Ladder)
Encourage them to build a future CV. Though it may feel counterintuitive, openly discussing future roles benefits everyone. Help them write a blog post, contribute to open-source projects, or share their expertise at meetups. Sharing knowledge publicly has one immense value - people will learn about the subject diligently before they present it. And this is precisely what you need - qualified experts.
What if They Leave?
Sometimes, there is simply no more room for growth within your organization, or budget constraints prevent you from giving them any more raises. I have experienced such situations multiple times in my entire career as an engineering leader, and I felt really bad about it.
Then the day came, and they got a much better salary and position elsewhere. While it was always sad to say goodbye and face the truth of the unfairness of compensation, there was something else.
Seeing your people become seniors, principals, or strong engineering leaders and having their salaries multiplied will be satisfying in the deepest part of your heart because, in some way, you contributed to their success.
And I genuinely wish you experience many such moments of pride!
Let your community grow also outside of your organization. You never know how it can help you in the future.