This is article is a follow-up to My First Thoughts as an Engineering Manager. It is a description of some behaviors that as engineering managers we have to avoid because they have a negative impact on the teams.
I’ve read many books and articles about software engineering team dynamics, the term “Hero” usually references a software engineer that tries to help everyone and solve all the problems not using the best practices and focusing on the short term. Of course, I’ve seen this behavior in some engineers but usually, it hasn´t a big impact unless there is a “hero” culture in the organization.
In my professional career, I’ve seen more “heroes” in the management layer, and the most important thing is that they generate a worse overall impact on the team and also on the organization’s culture. In my opinion, there are three main problems with the heroes at the management level:
- They are closer to the business and C-Level layer, so the impact of hero behavior can spread easily to all the organization.
- Heroes are the beginning of a toxic culture because many of them are looking for awards. More heroes mean more egos.
- People who always say yes to every business request, try to solve all problems, and always is ready to help are what everyone wants in his organization. They provide a lot of value in the short term but a lot of problems in the medium and long term.
In the beginning, it is so complicated to identify who is a hero and who is a high-performance professional.
Learn How To Say “It Is Not Possible to Achieve”
The trust between business and technical teams is one of the most important things in order to achieve the goals and have a successful organization. Achieving trust requires a lot of effort but losing is easier.
I’ve seen many times how there are managers that say yes to every request from the business because they think that our duty is to make possible all the requests. I don’t agree with this, the technical teams are responsible for two main tasks:
- Analyze the request, determine if it is possible to achieve, provide a technical solution and have a plan to achieve it.
- Deliver the request meets the requirements of the acceptance criteria.
If we can not achieve the request goal in terms of functionality or timing, we have to explain what are the reasons. There are many reasons why a request is not achievable and I’m not going to describe them in this article.
As an engineering managers, we need to support the teams to increase their performance and also to help the business layer to understand the capacity and skills of our teams, and what is the current status of our technical architecture. When we say “not possible” but we explain why and maybe provide alternative options, we are also increasing the trust between business and technical teams.
The teams with a “hero” manager accepting all the requests, usually have the following indicators:
- They have thousands of tasks queued in the backlog and the priorities changes continuously.
- The teams are doing an extra effort continuously to try the achieve unrealistic expectations.
- Generates frustration on the team because many of the tasks are not reachable. Generally is easier to explain beforehand, why a request is unreachable than try to achieve it and fail in the process.
Don’t Promise What You Can’t Deliver
Our day by day is to support the people and the teams. The teams need to improve their skills, to provide more quality software and many other things. In an ideal world, our organization would have all the resources required or the capacity to provide these team needs. But the real world sometimes is hard, we have to work to achieve it but be careful to promise unrealistic goals.
Generating an expectation and not being able to meet it, has a very negative impact on the team. If this behavior occurs many times, the team probably will lose trust in us and probably in the organization.
If you are going to work to improve some of their needs, it’s important to share with the team and also identify the priorities. Depending on the topic, the timing is also important. I believe in transparency, but transparency doesn´t mean sharing every single thing that goes through your head. For example, if you are working to increase the team salary, it would be good to verify with the organization if there is enough budget to do it before you share it with the team.
Micro-management is one of the most negative behavior to the team and people. This behavior can destroy a team in a few months. To have someone trying to control, deliver and monitor everything usually results in the following:
- Non-scalable teams.
- People with no self-confidence.
- Burnout in the people.
- Not evolving people.
- Increases employee turnover rate.
Apply micro-management imply that there is no planning because there is someone making changes at the scope and priorities anytime, so we are always working in the short term. When an engineering manager applies micro-management means that he doesn’t trust the team and the people. If the team needs to increase the performance, the micro-management is the opposite of a solution, the results will be a team less performant and less self-confident.
Assume you have a director or CTO making micro-management, talking every day with the members of the teams assigning tasks, and changing the priorities continuously. These actions make it impossible to have any type of planning, agreed timings and will result in a totally disorganized team.
This behavior promotes an unfair priority task flow. Where people with greater capacity to influence the Engineering Manager, are able to prioritize their tasks against the organization’s goals.
Foster Team Organization
The teams need an organization, of course, it can be self-organized but in the end, we need to know which are our responsibilities. There are organizations where the Engineering Manager is the Tech Lead, the Product Manager, the QA Engineer, the Architect, etc. These are organizations based on “Hero” culture.
The people of the team should have visibility and responsibility to grow professionally. They need to present architecture proposals, lead incidents resolutions, and many other tasks. The engineering manager can not be the face of everything. As engineer managers, we must focus on the growth of the team and not prioritize our own personal growth.
Teams with no real organization or professional career path are usually the result of micro-management. If we have a tech lead in the team but we don’t let him/her perform his/her duties, is like not having a tech lead at all.
Avoid Always On-Call Situations
In a performance team, there are no indispensable people. The idea of the team is that all team members should help each other and work in unison to achieve a common goal, and not be dependent on one person. I’ve seen many times how the Engineering Manager has to be always on-call even in his/her free time.
This situation is a symptom of “hero” management. Teams without an organization, and where the engineering manager is the fireman for everything. The teams have to be autonomous, not dependent on one person, have visibility and standard communication channels. Dependency means that there is something that we are not doing well.
As engineering managers, we have to support the creation of great teams and professionals. This means caring for the growth of the team, supporting them to achieve the goals, and making their day-to-day life easier. Support is not making all the decisions, is helping them make the decisions.
“A Hero” destroys teams and we have to help to create them. If you like to be a “Hero”, you don’t have to be an engineering manager.