Deciding If a Management Is the Right Career Path for You

Problem

As an engineer, you can choose between management and technical route and I was one of those engineers who wanted to go the technical route and become a principal engineer. I was in the software industry for about 12 years as an IC and was enjoying immensely mentoring people and sharing my knowledge of technology. That organically propelled me to become a lead on my team.

One day my manager approached me and told me that she had noticed how good I was at communicating with other people and keeping things moving and asked me if I wanted to try out management. I was very reluctant as I wanted to stay on the technical side of things but at the same time, I was also not confident enough about my people skills. She proposed that I manage three people while still working on the code.

Actions taken

My first management year was a disaster for multiple reasons, but predominantly because I was trying to juggle between too many things. I was assiduously doing the management side of things while trying to stay knowledgeable about every technical detail. I was trying to put out the fires by working 10-12 hours a day and struggling to catch up on things. Managing other people was taking almost half of my time and I had only as much time to do coding and I felt I was not as half productive as I used to be. A year later my manager realized that I was doing too many things at once and heading straight towards burnout.

I decided to take some management training and one that stood out for me was situational leadership. When I was managing people on the team I would approach them the same way I wanted to be managed and as a high performer, I needed a constant challenge and would prefer a hands-free approach (go and figure things out by yourself). I was managing other people by giving them autonomy and encouraging them to go and figure out things by themselves. But after that training, I realized that I had to adjust my management style to each and every individual on the team.

People are on different spectrums and based on the situation they are in they have to be managed differently. For example, high performers would love to be hands-free and constantly challenged with new projects and responsibilities. On the other hand, junior people and low-performers would appreciate more direction and strict guidelines. Before I took that training, I would typically refrain from providing additional instruction because it felt like micromanaging and imposing tight constraints. But that training helped me expand my understanding of different management styles and that comprehension was immediately translated to the team and improved their performance.

Another insight that I owe to that training is that as a leader you don’t have to know everything but you have to be the one asking the right questions. In the past, I was trying to get into details of everything and I had to learn to feel comfortable stepping back and asking questions. This approach tremendously affected my style of management as I would encourage my team to propose their own solutions instead of me merely prescribing them.

I also took another training on communication, finding the one on how to run one-on-ones particularly beneficial. I am a rather talkative person and have a hard time biting my tongue while one-on-ones should be all about your engineers and providing them with an opportunity to talk about their problems and career. I learned how to become more comfortable with silence and have them do all the talking.

In addition to training, I was avidly reading books and articles about management and was eagerly applying many of the things I’d read about. I was noticing how I was getting better at managing people and started to enjoy it more than being involved with the technical side of things. I never thought I would like management but maybe it was always there in the form of mentoring people, explaining technical problems, etc.

Lessons learned

• What Got You Here Won't Get You There by Marshall Goldsmith inspired me to understand that what made me an accomplished IC won’t make me a good manager.
• I love technology and still have a tendency to lean toward the technical side of things, but I realized that I don’t have to time-box my love for technology within those four hours dedicated to coding. Work is not the only space where I get to do technology and I immensely enjoy doing side gigs and passion projects.
• People who are choosing to go the technical route will often encounter a lack of opportunities. There are far fewer openings for architects or principal engineers in comparison to a huge number of openings for managers, directors, or VPs. - - People usually become principal engineers after staying for long enough with a company to know the system in and out and this is a progression that takes a lot of time and committing to staying in one place.