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.
Top comments (0)