Leading vs Managing

What is Leadership?

Too often people talk about managing and leading without being clear about what they mean. This can be particularly problematic when trying to mentor a developing manager. Managers have many responsibilities requiring a variety of skills and lack of clarity in our language can make it harder for managers to learn and improve.

In this post, I want to discuss “leading” and “managing” as behaviors (or skills) rather than a particular job (eg “engineering manager”). Many positions require both behaviors to varying degress. For example, a VP Engineering will spend more time leading than managing, while that ration will likely be reversed for a first level engineering manager. But, that engineering manager will still need to exercise some level of leadership to succeed.

So, how do I distinguish the two? My take is:

• Managing = activities that cater to the unique individuals on the team.
• Leading = activities that focus on the team as a whole and the commonalities of the team members.

Let me clarify with an example. One might want to motivate a team to deliver an important project on time. Exercising leadership skills, one might focus a team meeting on the importance of the project to the company and their customers, reminding the team of the competition they face and the opportunity this project represents. Exercising management skills, one might use their 1:1 with Susan, who’s played such a big role in the project, how a big win here will help her career, while focusing George on how much his teammates are depending on him. In the first case, the focus is team-wide, while the second case leverages understanding the motivations of the individual team members.

Note that others distinguish these differently. I encourage you to consider other viewpoints as well. For instance, this HBR post focuses on influence versus authority. Personally, I disagree, although I wholeheartedly agree that influence is critical to successful leadership. A leader whose influence only comes because of power will be less effective.

Engineering Leadership

With that distinction hopefully clear, I really want to focus on some aspects of engineering leadership I believe are essential. The primary responsibility of the head of an engineering organization is to produce results. Recruitment and retention are important components of this, but they are a means to an end, especially important to producing sustainable results. (Of course, making your organization a desirable place to work is a moral good as well. And, thankfully, it aligns with the bottom line business demands, particularly for an area like software engineering.)

As discussed in Bumper Cars or Go Karts?, creating and maintaining alignment of the team is crucial to producing results effectively. It also reduces frustration on the team, leading to higher retention, engagement and job satisfaction. And, the reason for discussing it here is that aligning teams is principally a leadership activity.

What needs alignment?

An engineering leader must provide leadership in several areas.

Company Values

All leaders in a company should exemplify the values the company wants to foster, be it transparency, reliability, curiousity, etc. But, in addition to being a good exemplar, a leader will also on occasion need to call out others who fail to live up to those values. If someone violates the values in some public way, then it may be necessary to call them out for it in that same “public”, as it’s important to see that the values really do matter. I would not make a hard and fast rule on this as there can be all sorts of nuance to any particular situation. But, the leader must at least consider the need to demonstrate to others the enforcement/reinforcement of the values.

Business Context

One aspect that distinguishes more senior engineers from less senior ones is their consideration of the business context when thinking about solutions. While it’s great to have engineers that can design and build highly scalable systems, a senior engineer understands that this is not always the right thing to do. (For example, often times a more lean/agile approach is more appropriate to deliver sooner and assess the value.)

Engineering leaders must recognize the business context and help align their teams on it. Some example topics are scalability needs (in concurrency, data size), relative importance of speed of delivery, quality, cost to deliver, etc. Left to their own devices, engineers will often want to make things more interesting (read: complex), often in the name of trying to anticipate circumstances (eg scale). The engineering leader bears responsibility for setting the context that gives the team the confidence to keep it (appropriately) simple.

Strategy

Again, engineers should understand the company and product strategy. More senior engineers will already recognize the need to understand these. As an example: are we building for the long tail, or for high end users/partners? Do we want to optimize our integrations to minimize our effort or our partners' effort?

Goals

Everyone should understand the company and team goals, including how they are being measured. If they are mentioned but not actively tracked and discussed, the team will likely grow to discount their relevance. A good leader must continue to reinforce the goals by discussing them and the progress so far.

A Note about 1:1’s

While it’s perfectly appropriate to discuss these topics in 1:1’s with individuals on the team, the engineering leader must still make these central topics in team meetings. It is insufficient to deal with these only in 1:1’s. The team needs the opportunity to discuss and debate issues, concerns and suggestions on such topics as a team, and that is what truly builds alignment.