on
A Note on Engineering Management
This post contains a few points and notes from my discussions with some friends and colleagues in engineering leadership and management positions.
Our job is to make sure the team delivers. But in order to do that reliably over a long period of time, we need to make sure that the team is conducive and stable.
To do so, we must:
- Set a culture for the team.
- Maximize each individual’s strengths.
- Align each individual’s personal interests with the team and company goals.
The following are some things we can do to achieve it.
Setting Up Team Culture
First, define what kind of core values we want for the people in our team. Different derivative characteristics might be needed for different job roles. For example, if I’m hiring for a red teamer I might be looking for qualities that aren’t normally present in platform engineers and vice versa. But they should still align with the core values we desire.
The core values are the values we want as the foundation for the team. For example, if we want to build a team with strong individual contributors, we might want to set their hunger to learn and improve as a core value. If we want people with strong communication capabilities and conflict management capacity, we might want to look for people with strong strategic empathy.
Suppose we’re running a team whose purpose is primarily for infrastructure management and platform engineering in a company. Infrastructure technologies are evolving quickly and every new project might require the engineer to learn new networking protocols, new services to run, or doing a deep dive into some tools we already use. In this case, a characteristic we would want from our team members is the ability to learn quickly and independently since at times they might be the first person in the whole company to touch the technologies they’re handling.
After we define the values and characteristics we want from our team members, we need to check if we’re building the team from scratch or if we’re inheriting an existing team.
When building a team from scratch, we’ll have the freedom to choose who’s in the team. Of course, as long as we have the hiring budget and the freedom to set up the environment for the people we want in the team to thrive.
When inheriting an existing team, depending on how far the team is removed from what we consider ideal, we might need to put some more effort into shaping the team’s culture and direction by communicating with the team members. Depending on how it goes, we might need to hire more people or let some people go.
Hiring
Hiring is a pipeline that consists of a few steps.
- Sourcing the candidates.
- Technical interviews to ensure the candidates have the right skills.
- HR and culture fit interviews to ensure the candidates can fit into the team.
- Salary negotiations and offering.
- Onboarding the candidates, if they accept the offer.
- Rejecting the candidates and responding to their rejection of our offer.
Some of these steps are obvious enough, but a few things that I can give some tips on:
- When sourcing, it’s preferable to look for candidates from talent pools that suit your hiring budget. You probably don’t want to approach people from top-paying companies when your budget isn’t enough to compete with these companies’ compensation packages.
- There might be some occasions when people from higher-paying companies apply to your company. Just process them as usual, sometimes there are people who look for something other than money and are ready to take pay cuts as long as they can get what they want (usually for learning or connections to further their pursuit of their personal goals). Just make sure to be fair when offering them. Since they’re taking a pay cut to join you, you must make sure they will get what they join your team for.
- When negotiating for closing an offer, try to understand what the candidate wants from joining your company. Think how you can help them get what they want, and align it with your team and company’s goals by planning how by pursuing their own goals, the candidate can help our organization achieve our goals.
Letting Go
I’d like to avoid the word “firing” here since letting people go isn’t always about firing them. Sometimes it’s just about them realizing that they need to move on to further their growth due to their needs and the company needs aren’t as well-aligned anymore.
Don’t take it personally when someone decides to leave. I’ve seen some companies with immature leaders being bitter about the people who were leaving the company and ended up making enemies of them. These people’s friends and connections probably wouldn’t be too excited to work for us if we’re not being professional and mature when letting them go.
Maintaining good relationships and building alliances with the people who have left your organization can help you over the long run since you can still support each other despite not working at the same company anymore. Also, at some point, you might need them back at your company and they might be interested in rejoining you. Or you might be the one who needs to explore new opportunities somewhere else, and they happen to be able to help you.
Conducting One-on-Ones
There are a few strategies I’ve seen people use when conducting one-on-ones:
- Schedule it often (weekly or biweekly), but skip it when there’s nothing the team member wants to discuss with us.
- Schedule it not as often (monthly), and just make use of the time to get to know the team members and their life updates, or generally just try to bond with them if there’s nothing they need to discuss with us.
- Just schedule it whenever we or the team members have something in mind to discuss.
I tend to use the second approach, with the occasional third approach. From what I see, it works better for bonding with the team if compared to the first approach since I see people tend to talk exclusively about their work/project updates when the first approach is taken (and skip the one-on-one meetings entirely when they don’t have any work-related thing to bring up).
It’s important to bond with your team members and understand their aspirations if you want to know them better to identify what motivates them and to know their strengths and weaknesses better. If you want to be the type of manager who can maximize each individual’s full potential, you need to understand how to interact with them well since you will need to convey your vision and the company goals to them in a way that allows them to understand it accurately. This will allow them to understand what they can do to contribute to those goals, and what is the best way for them to contribute given their strengths and weaknesses (which you can also discuss with them).
Because of this, it’s a bit hard if as a manager you have too many direct reports if you’re leaning towards this strategy. If you want to manage more people but with less investment in each individual person (you just want their job done), using the first one-on-one strategy might work better for you. Jensen Huang exclusively uses the third strategy, it seems.
You can choose whichever approach you find more suitable to your team management strategy.
Developing Individual Contributors
There are a few core factors for growing individual contributors’ careers:
- How good are they technically within the scope of their domain?
- How big is their scope of ownership over the company’s system components?
- How sharp is their sense of technical decision-making?
- How good are they in designing systems architecture?
- How deep is their knowledge of some niche parts of the system?
- How reliable are they at work?
- What high-value contributions can they make in their domain for the company?
- How many domains of expertise can they develop?
For junior to mid-level engineers, make sure they focus on improving their technical skills and their scope of ownership to the level they can be a reliable and independent contributor at work.
For senior-level engineers, they need to be able to work on more architecturally complex systems and systems that requires deeper niche technical knowledge in the domain. They should be a reliable contributor with ownership over some relatively important parts of the company’s system.
For staff engineers and above, they can develop one or more narrow and niche areas of expertise that can be valuable to the company. Or they can focus on expanding their areas of expertise, if they want to focus on versatility and the breadth of their range, but with a few pockets of areas with relatively deeper understanding than lower-grade engineers. Also, they need to have visible high-value contributions in their domain.
Developing New Leaders
To develop leaders, they need to develop the following qualities:
- Technical expertise, at least must be on par with a senior engineer. Even better if they’re on par with staff engineers or above, that should give them some more edge when developing technical strategies.
- Strategic empathy, the ability to understand other people’s goals and how to align their goals with the company’s in order to have both the team members’ and the company’s goals achieved. This will help motivate the team members since they can achieve their goals by following the leader, who can then lead the team to deliver what the company wants them to.
- Hiring skills, they should learn where to source candidates, how to “sell” the vacancies in their team to the candidates, and how to close deals with the candidates who pass the hiring process. It’s also important to learn how to deal with problematic candidates and how to reject them.
- Negotiation skills, can be used for day-to-day work negotiation with other teams, and also for retaining employees who’re resigning. The better our strategic empathy is, the better our negotiation skills should be, as we can offer things that appeal better to the other party if we know what they’re trying to achieve.
- Influence and communication skills, basically charisma.
- Budgeting skills, this is important for higher-level leadership positions where we’re managing budgets for salary raises and infrastructure costs.
- Organizational design skills, including planning for team expansion, team regeneration, and ensuring that the team can stay functional and last for a very long time (ideally the team can thrive even long after we as the leader/manager left).
Bonus points if they can also develop a good sense of business in the industry we’re in.
Conclusion
Most of the skills required to run a team are non-technical. But in order for us to be able to connect with the more technical team members and gain their respect, we must stay relatively sharp in technical aspects. So for me personally, ideally the more senior engineering managers and leaders should also be equal to the most senior ICs in the team in terms of technical understanding.
It’s understandable if the managerial people are a bit rusty regarding the actual implementation and usage of the technical tools, but it’s best if they can stay sharp enough to grasp the concepts quickly.
Aside from what’s mentioned, there might be a lot of backstage negotiations happening between a team’s manager with the stakeholders, another team’s managers, or the senior/top management in order to ensure their team’s success. So it’s important to get the respect and trust of people in the company. Different companies with different cultures might have different traits that they use as a measure for how respectable and trustworthy we are though, so understanding those factors is important to navigate the political landscape of the organization.
References
Ask Alto: What is strategic empathy, and why is it a key leadership skill in 2025?