If you’ve been an engineering manager for any length of time, you’ve likely had to manage up, down, and across. The question is, have you been successful at all three? Most engineering managers will excel at building relationships with their direct reports (managing down). Still, they may struggle with their relationships with their supervisor (managing up) and the rest of the organization (managing across).
This article will cover how engineering managers effectively manage up, down, and across an organization by sharing knowledge from other engineering managers’ experiences.
We will cover:
- What is managing down and how to do it well.
- What is managing up and across, and why it might be the most challenging aspect of being an engineering manager.
Managing Down
Managing a team of engineers (direct reports) is no longer about the engineering manager’s productivity but about providing the environment and resources for the team to be productive.
This article discussed what engineering managers do to maintain effective teams, which is critical in properly managing down. Here are more ways engineering managers can be more effective at managing down:
Delegate tasks based on strategic priorities and engineers’ strengths
In the managing spectrum, at one end of the spectrum, engineering managers can let the engineers “sink or swim.” At the other end, engineering managers can micromanage them.
At the “skin or swim” end, engineering managers let the engineers carry on with their tasks, and it’s up to them to deliver. With micromanaging, engineering managers direct every single task giving the engineers no autonomy whatsoever.
What lies in the middle of the spectrum is delegation, and that’s what good engineering managers managing down, do. In delegation, engineering managers can hold on to a few rules of thumbs:
- “Trust but verify”: “Trust but verify” is an English translation to a Russian proverb, which means relying on people and checking in to make sure they are succeeding at what they are tasked to do. It is imperative that engineering managers do not micromanage but inspire, motivate and guide the engineers to meet the expected outcomes.
- “Inspect what you expect”: This rule of thumb says that engineering managers need to check on the engineers to make sure the expected outcome happened.
Build and maintain motivation
We discussed in this article how having engineers who lose motivation impacts the team negatively.
Ron Lichty – in his course – Managing Software People and Teams, shared a chart from his book “Managing the Unmanageable”:
In the above chart, the factors on the left-hand side are significant motivators: causes of satisfaction. Most engineering managers focus more on them as they directly impact the project and organization. Unfortunately, many ignore the right side, which is the most significant cause of dissatisfaction.
It is up to an engineering manager to cater to all the needs of their engineers to thrive and grow and not only the ones that directly affect the organization.
Give detailed feedback during performance reviews
Fundamentally people count on their managers to give them feedback regarding how they are doing. Software engineering is a team sport. Reviewing engineers should be based on their contribution to the effectiveness and output of the team, and it is really important they get that feedback.
It’s a well–established practice to give specific feedback instead of generic feedback. It helps engineering managers start a proper conversation. Specific feedback is concrete and creates situations and events that will help an engineering manager suggest what the engineer could have done differently.
Managing up and across
Managing down is where engineering managers do most of their work. Still, there is a need to build good relationships with their supervisors (managing up) and the rest of the organization (managing across).
Managing up and across is a conscious approach an engineering manager makes to work with their supervisor and peers (other teams, stakeholders) toward mutually agreed-upon goals that are in the team’s best interests, the project, and the organization.
Managing up and across isn’t mere political maneuvering; instead, it is a process an engineering manager uses to influence their supervisors and peers to make decisions that benefit the team, the project, and the company.
Ron Lichty, in the same course, shared that managing up and across may be quite challenging for an engineering manager because their supervisor and peers may not be technical or may have forgotten all the rules of software development.
Engineering managers whose supervisors and peers aren’t technical or don’t remember being so may pressure to take on futile, ineffective, or counterproductive activities like:
Proving the team’s productivity/performance
Some supervisors may pressure engineering managers to report detailed metrics on the productivity or performance of their team.
They might want to have hard metrics to measure developer productivity, not understanding tech debt, and push for functions too soon. If engineering managers start emphasizing metrics, there is a possibility that engineers will start gaming those metrics.
Fundamentally, users, teams, and leaders (even if they ask) don’t care about metrics, they only care about functionalities that delights them. But when managing up, you will still have to deal with the metrics.
Filling the team’s plates to capacity
Slack is critical to throughput, but 100% capacity results in bottlenecks. Engineers multitasking, which may be in the supervisor’s mind, may bring in more overhead costs for the team to achieve more—also, micromanaging and imposing needless software engineering practices on the team. All these activities will affect the team’s effectiveness and output negatively.
Ron’s advice for engineering managers managing up
Ron provides two of his favorite quotes that he uses as a rule of thumb:
- “The single most important leader in an organization is your immediate supervisor.” – Jim Kouzes.
- “You can safely assume all perceptions are real, at least to those who own them.” – Joe Folkman.
The truth of the later quote, he says, is that it doesn’t matter what an engineering manager does, but what matters is their manager’s perception of what they do.
Regardless of any challenges managing up, an engineering manager should ensure their manager’s perception matches what they do. To achieve this, he recommends communicating regularly and thoroughly the project progress and the effects certain decisions make on the team.
