Introduction
Taking responsibility for the well-being of another human being is a serious responsibility, and that is what software engineering managers are expected to do. The people whose careers you have to look after have other people they have to look after as well. The decisions you make as a people manager will have a potential ripple effect on others you don’t directly manage.
Traditionally, and to an extent professionally, that is not how we think about employees. Personal matters stay at home, right? Business is business. But the angle here is shining a spotlight on the cascading responsibilities, and how we often shift our focus onto what our leaders want instead of what our people need.
There is a balance, and your people’s happiness will reflect in their work. If you hire the right people, they will go the extra mile, make you look good, and this will overflow to their managers as well. This is not rocket science, but we often see managers managing up only!
You may be a new manager or a manager experiencing some difficulty and going through a season of introspection and change, and your past management style is no longer serving you well due to people or organizational changes.
Let’s dive into some important points to cover.
Shift the focus from you to others
Work has become a very personal experience. When you excel and stand out, you get rewarded, and that can become addictive and selfish because we typically have one employer and they are our enablers. The more money we are earning, the more we are gain in our personal lives, such as our children’s education, the house we live in, or the car we can drive.
What got you to management is because you exceled or because of your experience and tenure at the company. You may be a natural leader finally getting your chance, but often, we promote our high-performing individual contributors (I hate those words, but using them anyway) because we want to retain them. Unfortunately, these engineers are not always ready for management.
When there is lack of people-first mentally that should be a warning sign. Nevertheless, it is within everyone’s ability to manage people if you make the effort and humble yourself.
When you were an engineer cutting code, your focus was on you. Yes, you worked in a team, but you had your own stories and tasks to finish, so naturally, you thought for and about yourself.
The focus has now shifted from your productivity to the productivity of others. Here are some questions to illustrate the focus shift:
- Are my engineers doing what they are supposed to do?
- Are they set up to be able to complete their assignments?
- Are they performing optimally, or are work conflicts or personal circumstances preventing them?
- Are any of my engineers at risk of leaving due to the work environment or underpay?
From these examples you can clearly see that your role and responsibilities as a software engineering manager have become exponentially more complicated. Instead of you times the problems you have it is the number of people multiply by their blockers or problems! In the past, worrying only about yourself was easy, but now, you have exponentially more people (2x or 10x) to ensure are set up for success.
If the focus remains only on yourself as their manager, this is going to have a bad ending. What is sad is that this type of bad management style is prevalent and overlooked because you as the manager still have the technical expertise, so losing other team members won’t create an immediate gap and crisis, but it is just a missed opportunity for them and the organization and more importantly losing capable people.
The first couple of months as a software engineering manager are the hardest
Not to demotivate you further, but there is more bad news. Moving away from being an individual contributor to a manager is two different worlds. Let me explain.
Cutting code and committing, building pipelines, creating ETL processes, and architectural diagrams are all tangible outputs. You know that checking in that code after, hopefully, testing it, is a satisfying and productive feeling. It is immediate, and the more you do it, the more visible results you see, and the more dopamine you get.
As a software engineering manager, you may still dedicate a percentage of your time to contributing to code or architecture, but often, you move onto tasks like budget management, organizational setup, people management, strategic meetings, etc.
Let’s focus on new managers moving completely out of being an individual contributor. The first couple of months as a new genuine manager will be challenging, as you may feel a sense of total uselessness. If we recall the questions in the first section, these items don’t have immediate tangible results. These aren’t the types of problems that can you can solve in a day. It takes time to resolve these issues and to see results, often weeks and months.
Shifting engineers’ responsibilities takes time, and the results won’t be immediate. You are now effectively managing other people’s expectations and worries.
Your role as a software engineering manager will be hard and unpredictable. Humans are unpredictable. We know ourselves, but depending on the way the focus of your lens, it will be challenging to solve these problems, and over time, the reward will be people and process synergy. Those wins tend to stick around for a while.
Adopting a strategy of honesty can lead to more favorable outcomes for all parties involved
The key ingredient in being a manager is honesty! Simple words, but difficult to practice because of the many different people, company policies and unique situations you’ll encounter.
I personally used to avoid conflict. In itself, that is being dishonest. The situation at hand requires resolution. There is another angle: Avoiding conflict is also dishonest because you cannot handle the truth about your short comings. You aren’t true to yourself and the situation.
A situation with a report may reveal that the engineer is unhappy, not set up for success, and struggling. The metrics show this. It could be due to a failure as a manager. A lack of thoughtfulness on the best course of action for this engineer. That is hard to hear. I always feel disappointed when people are disappointed in me. It still remains, but I’ve learned how to deal with it and not let it deter me from resolving conflicts.
In cricket and baseball: You may drop the catch but you can still get a run out!
Honesty is the great equalizer! It is important to receive honest feedback from others. This helps to improve or do things differently to improve when a similar situation presents itself in the future. It is uncomfortable, but it relieves pressure after admittance. Leaving the situation unhandled will result in it getting worse over time. In my experience, dealing with it later is usually harder with much worse consequences. Deal with it immediately.
Giving feedback can be daunting. You are telling someone they are making a mistake or they messed up really badly. You know from working with that person for a while that they aren’t going to take it well. However, our perception often doesn’t reflect the truth. That person may needed a release from the old ways, or they needed the kick in the backside to get their career back on the right path. The truth always prevails, and for the short-term pain, there are usually long-term gains for you and, more importantly, the person who had to suffer the consequences.
Honesty releases tension over time. You cannot help if someone does not like you, but if you are honest, there is not much that engineer can hold against you. If they decide to leave, then it is potentially best for both parties. Honesty cleanses the situation for both. Sometimes, people aren’t compatible. Period!
Honesty creates trust! When you cultivate a culture of trust, they will respect you and will do almost anything for you.
I cannot share everything with my direct software development managers and engineers. I try to as much as I’m allowed because it is important to share. They trust me to keep them involved and informed. If people hear news from other sources and you, as their manager, I failed to inform them. It creates trust issues and a sense that either they aren’t important enough or that you are too busy to care about them.
Doing a lot of things and being busy is not an excuse. You don’t have time deficiency problems. you have prioritization issues. There is more than enough time in a day. No excuse!
What can I do to improve as a software engineering manager
The job is hard, as I mentioned previously. You need to take care of people’s well-being to get the best out of them. Focusing on yourself only as a manager and your career will cause problems and ultimately mutiny. You can bullshit your way out of it, which tends to happen but only lasts for a short while.
So, here are a couple of additional items to focus on to improve:
Be present. It is important for your direct report engineers to feel that you are available and attentive. In a previous post (How to improve one-on-one conversations as a dev manager), I provided guidelines on how to effectively interact with your engineers. This will build trust, and your engineers will give their best for you.
Let a to-do list be your assistant. This one still blows my mind that there are so many leaders in our industry not keeping track of items and conversations. A to-do list reduces cognitive overload. It is so simple to follow the list and to action items on it. Now, actioning items is a topic for another day. However, it is important how you break down these items, especially the complex ones. Use apps like Trello, Microsoft Planner, or any other task management tool.
Confirm with your company if there is a vetting process to vet for internal use. It just comes across as professional to follow up on items, even if others forget. It sets you apart. The main gain is that you GET SHIT DONE! More on this in a future post.
Micromanagement is not always bad. Think about it. Micromanagement infers being close to engineers where your presence is not required. You can do more damage to the situation by not having all the context. You also may have context, but you take a learning opportunity from a direct report. However, when there is a tough problem to solve, your presence may be appreciated. Another use case may be a new joiner feeling out of their comfort zone or overwhelmed. Checking in often and spending some direct time, even going over the work they have done, may just give them the welcome they need. After that, you can step away.
You are only as good as the feedback you receive. I’ve been in situations where I’m told I’m doing great and exceeding expectations, but it feels like you become stagnant. In an earlier post, a previous Director of a previous company told me I’m not a good coder, which was exactly what I needed to hear to become a good coder. The same applies to management. You need to listen to your boss, and hopefully, they are good, or you need to find a mentor. In addition, you need to take feedback from your reports! Yes, you are the boss, but they should have a say, and you should be open to it. If not, then you may have a problem that will make management very challenging for you.
Feedback is new information, like reading a new article and learning something.
Conclusion
In conclusion, becoming a software engineering manager is a transformative journey that requires a shift from individual achievement to team-centric leadership. The role demands more than technical expertise. It requires emotional intelligence, a commitment to honest communication, and an unwavering focus on the well-being and development of your team. Remember, your success as a manager is measured not by your personal output, but by the growth and satisfaction of the engineers you guide.
Embrace this role with a mindset of service and continuous learning, understanding that each decision you make impacts lives beyond your immediate scope. By prioritizing the needs of your team over individual accolades, you not only foster a positive work environment but also drive meaningful progress within your organization. To all aspiring and current managers, your role is crucial—approach it with humility, courage, and a deep sense of responsibility.
