How to Be a Better Software Engineering Leader by Mirek Stanek Practical Engineering Management
How to Be a Better Software Engineering Leader | by Mirek Stanek | Practical Engineering Management #
Excerpt #
The first-level managers — Tech Leaders, Engineering Managers, Product Managers, or Team Leaders — hold the most crucial roles in the company. This statement underpins the entire Practical…
Strategies for Elevating Your Engineering Leadership #
[
]( https://medium.com/@froger_mcs?source=post_page-----286a82ec278e--------------------------------)[
The first-level managers — Tech Leaders, Engineering Managers, Product Managers, or Team Leaders — hold the most crucial roles in the company. This statement underpins the entire Practical Engineering Management philosophy.
Their challenging job is to blend hands-on experience with strategic thinking. They combine knowledge about products, business, and technology. They translate long-term objectives into day-to-day tasks. No one is closer to the customers. They have the power to deliver features directly to them.
The organization’s success depends very directly on these first-level people managers. Yet, during another challenging year for the software engineering industry, more companies decide to flatten their organizations and either reduce engineering manager roles or translate them into more hands-on positions (Engineering Manager -> Tech Leader).
Why is that?
Apart from cold cost calculations, reducing distractions, and narrowing the company’s focus, sometimes engineering managers simply aren’t good enough. It’s a harsh truth, but if their role is only to assign tasks, give orders, and read reports, it may bring more harm than the absence of such a manager.
Let’s look closer at the differences between good and bad managers and what we can do today to be better software engineering leaders.
The Role of the Engineering Manager #
In a healthy tech organization, engineering is not a cost center but a profit center. This means it’s the product (customers’ needs) that drives technology, and the technology enables the product.
The engineering manager’s role is to ensure product context influences the technology and that the technology is built in a way that enables further product development — its growth or expansion.
But if the engineering manager is the only one who knows the product context and controls the engineering team through top-down orders, we end up in a situation where the team either only writes code (worst-case scenario) or builds product features here-and-now (better-case scenario, but still bad).
The role of an empowering engineering manager is to ensure that people know exactly what problem they are trying to solve — so the product context is widely known. And those people have the skills, tools, and processes to resolve these problems in the best possible way.
What’s the difference between good and bad managers?
Bad managers:
- Micromanage — they merely assign tasks, not allowing for collective decision-making.
- Don’t contribute to product discovery — they don’t try to understand the real problems to solve.
- Don’t manage expectations — they don’t focus on course correction, don’t grow teams’ skill sets, and don’t look for the most impactful initiatives for their people.
- Are gatekeepers, not enablers — rather than finding a solution, they “protect” the team until they get 100% of the requirements.
Good managers:
- Manage talent — challenge and grow engineers or fill gaps with good hiring.
- Manage expectations — focus a team on outcomes, not inputs.
- Manage people — make people feel valued, motivated, and productive.
- Manage impact — allocate people to the best possible initiatives.
- Manage product — build a profound understanding of the problems they are trying to solve in order to build the best possible solutions.
- Manage technology — maintain technical debt, improve developer experience, align the tech stack with product strategy, set tech standards, KPIs, or SLIs/SLOs, and more.
Read my take on the subject: Do companies need fewer engineering managers or better engineering managers?
Top-down or Center-out? #
There are two types of leadership approaches — top-down and center-out.
Many engineering managers stick to a top-down leadership style for too long. Initially, it can be effective for bootstrapping the team or processes, or taking the lead during times of crisis. However, if the engineering manager is the only one who possesses the data and makes all the decisions, while the team is expected to merely execute their directives, it’s not an efficient way of managing teams in the tech world.
The top-down approach doesn’t allow teammates to think. They lack context for the work and are not invited to collaborative thinking. It’s especially dangerous in the context of senior software engineers, who are likely more knowledgeable about the technology than their leader. Being a top-down leader for them strips the team of all the experience and knowledge they have.
Read more on the subject: How to lead a team of senior engineers.
The top-down approach also leads to cognitive overload for a leader, as the person who must be on top of everything. This constant urgency and the need for a highly detailed understanding of their landscape leads to the worsened quality of their work and their decisions.
But there is a different way to work — with a center-out approach to leadership, leaders can enable collective intelligence and foster more creativity by involving experienced teammates in decision-making.
Rather than focusing on coordination (people, decisions, data), center-out leaders focus on communication, facilitation, and knowledge sharing. If you wish to work in this manner, you must build mutual trust and delegate effectively. This doesn’t mean working less (delegate and forget) but working smarter.
Center-out leaders create and maintain an environment where people know exactly what problem they are solving — they have all the necessary data and product context, and they can devise their own solutions. Leaders can then synthesize learnings from these local solutions into system-wide knowledge, which is then shared across the organization.
Read more: Top-down Leadership vs Center-out Leadership
The cheat sheet of the article:
You can check more cheat sheets on Practical Engineering Management — 🗃️ All Files page.
Management is not about Execution but Improvement and Growth #
The role of the engineering manager is not to control the execution but to constantly improve the situation so the team’s impact grows over time.
Executing #
Bad managers focus on execution. They manage the situation here-and-now. Tasks come in and come out. Their job is mostly about scheduling with the hidden assumption that things will stay forever as they are.
But this is an illusion, especially in tech organizations where “the only constant is change.” Our software becomes increasingly complex, declines in quality, and becomes more difficult to maintain. The organization constantly evolves — people come and go, priorities change, and the business landscape advances.
Organizational entropy and inertia are powerful and destructive forces, and being an engineering leader who focuses only on execution will not only keep your impact flat but also decline over time.
Read more: Entropy and Inertia in Engineering Leadership.
Improving #
More impactful engineering leaders focus on getting things better over time.
Here are a few examples:
- Improving the tech stack during development — in many organizations, teams have “10–20% time dedicated to technical improvements”. As an engineering leader, you set goals, KPIs, or non-functional requirements and expect that each product development task also contributes to these goals.
As a source of inspiration, you can use Ten Types of Technical Debt. - Growing teammates — each of the teammates has their growth objectives, e.g. set as SMART goals. Over time, people get a variety of different tasks, training opportunities, and bigger responsibilities. They can climb the career ladder.
If you want to grow your teammates, you can find some inspiration here: Intro to Expectations Management - Improving through reducing — we improve things not only by adding something new but also by simplifying or reducing. It’s not always obvious to our brains (check this Nature’s article: Less is more: Why our brains struggle to subtract), but often a bigger impact comes from things that are smaller, simpler to maintain, and less complex.
Compounding #
Compounding is like improving, but with the difference that we focus on the right things. Leaders here still make their tech stack better as well as focus on growing the team’s know-how. But rather than improvisation (e.g., we set SMART goals because our HR department told us to do so) or overoptimization, goals, KPIs, and initiatives are planned and informed.
So, next to proactively applying improvements during our work, we also have to work with feedback mechanisms to assess if we invest in the right things and, over time, we’re getting closer to expected outcomes.
Here are a few tools and techniques that should help us not only improve but also compound our impact over time.
Build a culture of candid feedback — your job as a leader is to set up multiple streams of information for yourself. If people feel comfortable sharing feedback with you — their struggles, ideas, and thoughts, you will have access to “ground realities.” It’ll help you to validate in a qualitative way if the improvements you provide are making things better.
If you seek inspiration, check this article: Mastering the Feedback
Be more data-driven — next to qualitative feedback, you should also collect numeric data, which will tell you more about the progress of your work, expected outcomes, etc. Some examples can be:
- DORA metrics — deployment frequency, lead time for change, change failure rate, and mean time to recover (MTTR)
- Basic behavioral analytics, so you understand how your product is being used by customers (read more: Product Analytics for Engineering Leaders)
- Data dashboards you built for your specific needs, e.g., to track the team’s objectives (read more: Practical solutions to track your goals)
Build a better understanding of the problems ahead of you — sometimes, when we get a product task to work on, we just jump straight into the implementation without giving any extra thought. At least in big, strategic projects, I encourage you to reframe the problem so you have the full understanding. If you do that, it’ll be easier to pick the right way — solutions, architecture, and other resources, to solve these problems effectively.
If you need some inspiration, check The Problem-Solving Framework
Be consistent — compounding means improving things over an extended time. That’s why you should validate your objectives, wins, and distractors on a regular basis. I recommend having a weekly leader’s journal where you write down these things to validate your outcomes and maximize the impact of your work.
You can check the Leader’s Week Framework if you want to standardize this process.
Have a plan — compounding is not improvisation but a coherent set of actions as a response to strategic problems ahead of you. If you want to build such a plan, there is no better source of knowledge than Richard Rumelt’s Good Strategy/Bad Strategy. The critical elements of a good strategy, according to it, are:
- The Diagnosis — involves understanding the current situation and identifying the key challenges that the organization faces.
- The Guiding Policy — involves setting out the overall approach the organization will take to address its challenges.
- The Coherent Action — involves taking a series of coordinated actions designed to implement the guiding policy.
In practice, I draw boards (using Miro or FigJam tools) with all feedback collected during 1:1s and brainstorming discussions with engineers, leaders, upper management, and product and business stakeholders. Then I categorize it with Rumelt’s framework, and based on this output, I draw 6–18 month plans.
On Practical Engineering Management you can find detailed materials about building engineering strategy, including FigJam Board. Read more here: Engineering Strategy Framework.
Preview of Engineering Strategy Framework
In the dynamic landscape of engineering leadership, the distinction between merely managing and truly leading has never been more critical. This article has explored the essence of what it means to be an effective engineering leader in today’s fast-paced technological environment.
Explore more content on practicalengineering.management. You will find there practical strategies for effective engineering leadership. Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.
If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.