One of the responsibilities of engineering leader is to support their teammates with self-development. Growing a high-performing team with knowledgeable and experienced engineers should be the ultimate goal for a manager. But It also comes with the fear (I’ve got this question multiple times during my 1:1s with engineering leaders):
“What if those people were smarter than me? How am I supposed to manage them?”
In this post, I’m sharing some techniques and materials from Practical Engineering Management that will help you lead a team of senior folks with strong technical skills and rich professional experience, and you cannot constrain them with a command and control management approach.
According to Wikipedia, here is the etymology of the word “management”:
The English verb manage has its roots in the fifteenth-century French verb mesnager, which often referred in equestrian language “to hold in hand the reins of a horse”. Also the Italian term maneggiare (to handle, especially tools or a horse) is possible. In Spanish, manejar can also mean to rule the horses. These three terms derive from the two Latin words manus (hand) and agere (to act).
While “holding in hand the reins of a horse” sounds extreme, it somehow reflects the default behaviors of fresh engineering managers.
The administrative part of management is indeed needed (like managing expectations, timelines, resources, costs, etc.). However, there are more effective ways of working with skilled people than telling them what and how to do.
As an engineering leader, your job is less about managing people and more about managing their talent, potential, and growth. Here’s how you can do this:
- Manage through expectations
- Manage through problems, not solutions
- Manage through purpose
- Manage through principles
Manage through expectations
Telling people what to do and how to do it has many flaws. By micromanaging, you don’t use the full potential of your direct reports. You are also a bottleneck since everyone is dependent on your explicit instructions.
Rather than giving orders, change the narrative to having some specific expectations:
- Expect the team to solve a given problem.
- Expect an engineer to own their work (e.g., monitor the health of their services or keep them up to date).
- Expect particular requirements to be met (e.g., quality KPIs, non-functional requirements, etc.).
By going this way, you show the team what the expected results are while it’s on them to figure out how to do it properly.
To extend your expectations management practices, go beyond just goals assessment.
Here are three fundamental aspects you should take into consideration when discussing performance with your teammates:
- Skills
- Impact
- Attitude
Great software engineers should be a mix of all of these. It’s not just about being a good developer or software architect (Hard Skills). It’s neither about being a great public speaker or a decent negotiator (Soft Skills).
Hard and soft skills are critical but only matter when appropriately allocated (Impact). And your teammates’ willingness, openness, and proactiveness (Attitude) are the ways to maximize this impact.
Manage through problems to solve, not solutions
One of the common pitfalls in software engineering is that we jump into solutions too quickly before we even define a problem we’re trying to solve. If you, as a manager, give your strongest people solutions to implement, not problems to solve, you deprive them of the opportunity to find the right solution.
In the complex world we live in, the initial solution coming to your head is rarely the optimal one. Complex problems may have multiple definitions, none of which is ultimately the right one. A problem may have multiple stakeholders, each with their own solution, and these stakeholders may have different power to articulate their preferences (the loudest one in the room, the most senior on the org chart, or those who prefer to remain silent).
That’s why, before diving into any problem, task, or challenge, try answering these questions first:
- What is the problem?
- What are the facts underlying the problem?
- What are the root causes of the problem?
- Who is affected by the problem?
- Is solving the problem worthwhile? Is it in alignment with broader goals and strategy?
- What are the options for solving the problem? Which are the optimal ones?
- Implement the solution.
- Are success metrics defined and met through the solution?
Including your senior engineers in answering these will bring you needed perspective and help with framing the problem.
Manage through purpose
In materials on Practical Engineering Management, I often share this statement:
The role of technology in a product company is to solve customers’ problems.
This is especially critical for skilled engineers, who, thanks to their expertise, can have a huge impact on the product. Your job is to ensure that they don’t just build features for stakeholders but are an integral part of the product organization.
It means your strongest engineers should take part in discovery and delivery processes as well as own their work post-launch. To achieve that, assess their work not by tasks accomplished but by achieved outcomes.
Driving a team with outcomes requires some level of the organization’s maturity. If you think your company is not yet ready for that, you can try to define the purpose of your team through the factors that are universal for most product companies:
- growth
- expansion
- customer satisfaction
- costs
Manage through principles
A company’s mission and vision are often high-level and not easily translated into tangible actions and decisions. To keep the organization aligned, a company can promote a principled leadership culture. The concept of principles serves as a framework for decision-making and pursuing the company’s strategy.
Principles provide alignment and autonomy for your team. Even with strong software engineers, there are countless ways to solve a problem. Principles guide decision-making without constant supervision. For instance, if considering an additional security layer for an API, Apple’s principle of “Privacy is a fundamental human right” would make the decision a no-brainer. In contrast, Facebook’s “Move fast” might lead to a more nuanced discussion.
While your team should be responsible for the “HOW” of a given challenge, your principles should provide them with a context on what matters the most in their work.
Here are some example principles from the industry:
- Google’s “Focus on the User and All Else Will Follow”: Emphasizing user-centric design, this principle inspires software engineers to prioritize user experience, ensuring intuitive and accessible products.
- Amazon’s “Working Backwards”: This principle encourages engineers to think from the end-user’s perspective and work backward to ensure the product meets its intended goals.
- Netflix’s “Highly Aligned, Loosely Coupled”: A principle of having teams that are aligned in their goals but loosely coupled in their execution can inspire software engineers to work autonomously while still contributing to the broader objectives of the organization.
If your organization hasn’t developed clear principles, don’t let that stop you from creating them for your team. In a small company, this is an opportunity to lead by example and influence the entire organization.
Other materials
No matter how skilled the engineers you are managing, there are some practices that should be universal for leaders.
5 Characteristics of a High-performing Team Leader
The book “Accelerate” highlights five key characteristics that define a high-performing team leader:
- Visionary,
- inspirational communication,
- intellectual stimulation,
- supportive leadership,
- personal recognition.
1:1s
It was mentioned countless times on Practical Engineering Management — if you can pick a single leadership technique to work with your team, let it be 1:1s.
1:1 meetings are where:
- you make these abstract concepts tangible.
- you support your team in reaching their potential and succeeding professionally.
- you translate strategic objectives into daily actions.
- you foster the company’s culture.
Starting your first 1:1 meetings can be challenging. You must bring structure and continuity to these sessions, as well as ensure they are valuable for your team members. On Practical Engineering Management, you’ll find materials on running these meetings, their core principles, and focus areas.
End Notes
This compilation is designed to help you lead senior software engineers, who are supposed to be more skillful than you in some areas. My mission is to help engineering leaders make great ideas happen.
Originally published on Medium