DEV Community: Waydev

What’s the Difference Between Engineering Leadership and Engineering Management?

Waydev — Fri, 20 Nov 2020 09:52:11 +0000

It has become a constant temptation to praise engineering leaders and undervalue engineering managers, but maybe we shouldn’t be focusing on their differences but on correctly understanding their roles. An engineering manager’s job is to assemble a team that’s fit for the task at hand, to ensure that each team member has everything they need to do their job, track progress and remove roadblocks, and generally, to keep a steady course towards the desired outcomes. Nothing wrong with that now is there?

Problems arise once we begin expecting all engineering managers to, other than doing everything on the above list, also be incredibly inspiring visionaries. That isn’t possible. It’s also not necessary. Other than having a great power to inspire people to give their best, great engineering leaders also have a reputation for following their own path, questioning the status quo and inspiring people to walk alongside them, etc.

Now, imagine that every team would follow a different engineering leader. It sounds a little bit like a recipe for chaos and misalignment with a hint of disaster, wouldn’t you agree? While there is no doubt that engineering managers should work towards developing engineering leadership skills and use them to help their teams, their overall mission is different.

Why engineering managers matter

In her book ‘A Guide for Tech Leaders Navigating Growth and Change,’ Camille Fournier, Managing Director and Head of Platform Engineering at Two Sigma, and a former Tech Vice President at Goldman Sachs and CTO at Rent the Runway explain how quality engineering management is the salt and pepper of good engineering, healthy workplaces, and profits.

She is challenging the idea that engineering management is a soft skill that is less worthy of being developed than hard engineering skills. Camille argues that building engineering management skills is not only a more challenging task than many software engineers seem to think it is, but it also a rewarding and fulfilling experience.

In Camille’s view, software engineers need to understand that:

organizations don’t grow just by having great engineers who can write code. Someone needs to coordinate them;
on top of continuing to develop their technical expertise, engineering managers must also become skilled at coordinating resources and projects;
a good place to start for engineers looking to take the management route is tech lead or mentoring interns or new joiners. Both tech leads and mentors have an interesting and immensely useful challenge of influencing people without having any formal authority. Along with ensuring clarity of direction, milestones, goals, and that the right people are focusing on the right things, and that engineering managers are also responsible for helping team members develop professionally and grow their careers.

One of the caveats when it comes to being a good engineering manager is that you can’t manage others if you aren’t very good at managing yourself. Growing skills like grit (passion for a goad mixed with tenacity), listening, empathy, actively and constantly seeking out feedback and action on it, along with the understanding that all the strategies in the world don’t add up to anything in the absence of good execution are the building blocks of getting a good grip on who we are as professional and then being able to manage others. Self-awareness, accountability, and a growth mindset are also a must.

What makes a great engineering leader

One key trait of any engineering leader is that they can inspire and “move” people (both metaphorically and literally), often in the absence of formal power or authority. We used to give charisma and gravitas great credit for those abilities — some people seemed to inspire trust and respect in others or could naturally and easily draw people towards them.

A more nuanced definition of a great engineering leader has become necessary, and charisma doesn’t seem to hold that much value in the new paradigm. In his ‘Good to Great‘ bestseller book, Jim Collins argues that being charismatic isn’t really an essential trait of a transformative engineering leader. Instead, he points to attributes like knowledge, discipline, passion for what they do, but also humility, a sense of responsibility for their teams along with a deep desire to help others succeed.

Putting others’ interests first or at least being mindful of them is already a step in the right direction. Clearly, that’s no easy task. Ignoring selfish impulses is not only unnatural and against our nature, but the jobs get even more complicated when trying to fight biases that we are not even aware of having. However, a genuine interest in others and the desire to help them grow and succeed is a recognizable trait in all engineering leaders.

And as if the list wasn’t long enough, already, popular leadership guru Simon Sinek also adds the ability to create a culture governed by safety and mutual trust to the desired skills. In his view, a great engineering leader understands that a team’s strength lies in building on the trust shared by its members. Great engineering leaders develop and nurture a culture based on mutual trust.

Summing up, to succeed at any career — whether the aim is to become a Michelin starred chef or the CTO that leads its engineers towards unicorn status — a list of necessary skills and a strategy to achieve them is essential. Also, there are very few jobs or businesses where the ability to manage resources or to influence others is not only precious but also necessary. Whether a company needs more or better-engineering managers as opposed to engineering leaders, is a mix to be figured out case by case.

3 Things Great Engineering Managers Do

Waydev — Thu, 19 Nov 2020 10:12:48 +0000

As all Spider-Man comic book fans know, with great power comes great responsibility, and being a great manager isn't just about being good at telling people what to do. It turns out that effective engineering managers aren't mind-bending wizards — they're just good at a few things. Here's a few of them:

Protect the team

Your team expects you to set the course and drive them to the target destination. For them to be able to focus on what they need to do to get there, they must first feel safe and comfortable. If they have to worry about some other team interfering with the project, power struggles, or other managers' egos, you're not doing your job and keeping them from doing theirs.

Advocacy

Engineering managers can advocate for their teams using Git Analytics tools. For example, if your team has been working on cleaning up technical debt in the previous sprint, you can bring up the Project Timeline report in stakeholder meetings, so that the data tells the story. The only thing worse is having a manager who blames the team for missed targets, delays, or other issues — very few things scream bad manager as loudly as that.

Protecting your team also means not wasting their time — time that they could spend working on moving the project along. As an engineering manager, you can spare them the frustration of having to redact those dry corporate reports by using Git Analytics reports. You can learn more about this here.

Balancing protection

That being said, as with all things — balance is the key, and overprotection can be just as bad wasting people's time. While your team should be spared all unnecessary frustration, they need to be able to function within a complex web of relationships within the company. They should be allowed to focus on moving the project along but should also learn how to relate and build relationships with colleagues in other departments.

While flexibility and innovation are exciting, people can only digest change in small quantities. Make sure you carefully consider the frequency and timing for any changes. It's one thing to fix something that isn't working and a completely different one to keep jumping from one thing to another. Your team will probably appreciate not having to manually fill in annoying reports by hand and switching to dashboards.

Build and maintain motivation

You've probably outgrown by now the old paradigm where motivation was directly related to payment levels. As a manager, you are now completely aware of all the other factors that motivate people and keep them that way.

A more current model emphasizes three main factors that influence motivation levels: autonomy, purpose, mastery. This applies to engineering teams just as well as other ones. In terms of autonomy, your people need to be able to work without being micromanaged. Outside of emergency or crisis situations, they need to control what tasks they focus on, in what order, and in what way.

Purpose

Purpose relates to your engineers understanding the bigger picture and what part they play in reaching the end goal. If that's still not clear, it's up to you to help them see how they fit in and the impact of their efforts. It also helps if they are personally invested in the product. It can feel utterly exciting to be working on something you're passionate about.

The experience will be completely different if an engineer feels like they are being forced to use their skills for a product they deem useless, unethical, or immoral. Engineers will usually experience performance drops if they feel their efforts go to waste. Engineering managers can monitor individual performance drops using the One-to-one reports provided by Git Analytics tools, such as Waydev, Pluralsight Flow, and Code Climate Velocity.

Mastery

Mastery refers to a need to learn and improve continuously. If your engineers aren't learning anything new or don't feel challenged, it's likely they will not be putting all of their efforts into it. It's not uncommon and hardly surprising to see a developer walking out to join another team for the opportunity to play around with a different tech stack and solve some new problems. When it comes to helping your team grow, there is rarely a need for expensive, sophisticated learning programs. Allowing them to learn by exploring new technologies or taking on projects that spark their interest will probably be useful.

Being able to take pride in what you are building or have built is a source of great joy and a reservoir for renewed energy and motivation. You could help by making potential projects known and available to them. Such a project could bring together teams of young students interested in technology with mentors (members of your team). They could then be assigned a real project and given a chance to develop a product that would address a real need for a real NGO.

It's a win-win-win type of adventure. Young students work alongside seasoned experts, while the mentors kick out to teach the new generation the rope. Also, as it often happens, adults build new skills (how often do they get to have a go at teaching?) and give something back. Not to mention the immense joy, the pride, and the sense of achievement and contribution that both youngsters and mentors gain from seeing something they've built being used for the good of the community.

Recognition

Recognition is another essential piece of the motivation puzzle. Make sure you attribute and recognize both effort and success. Never take credit for your team's work. Highlight their achievements to higher management and help your team access development opportunities when they become available.

Get to know your team members, learn what they're interested in, what they're passionate about, and what they appreciate. Giving a developer a raise after staying up nights for a month fixing someone else's bad code and saving the project might not always be a good idea. Especially if what they really want is to work on something they're really passionate about and the extra money doesn't help much in terms of motivation.

Get good at making tough decisions the right way

You're probably already familiar with Daniel Kahneman — respected psychologist and Nobel prize winner — and his conclusions about rational decision-making in business and otherwise. His main point being that there isn't such a thing as a perfectly rational decision or, at least, that we humans aren't much good at making them.

Decision responsibility

As an engineering leader, you are the one responsible for making decisions. Gut decisions can prove to be wrong, and we all know that wrong technical decisions can have disastrous outcomes. Luckily, engineering leaders can make decisions backed by data using Git Analytics tools, specifically the Reports features.

In the '7 Breakthrough Decision Practices' white paper, Cloverpop's Erik Larson talks about an imperative need to go about making decisions in a step-by-step, process-driven way. If checklists are a great tool for highly skilled professionals like doctors or pilots, they shouldn't be disregarded by managers either. Larson then goes on to recommend a six steps process for all decisions:

Make a list of 3-5 company goals that will be impacted by the specific decision.
Come up with a few alternative options (4 should be enough).
Note any mission information or details that could potentially change your decision.
Think about the impact that the decision might have — positive or negative. Write that down.
Write down the context in which you are making the decision and document the decision.
Document the results of the decision.

In Larson's words, use a decision-making tool and avoid becoming a decision-making fool. Think about that next time you're raking your brain, struggling with a tough decision. Choose a Git Analytics tool and save yourself and your organization from the pain of wrong decisions.