Before I started working at Captricity, I was an ignorant, know-nothing, over confident college kid who thought that the only destination in an engineering career is management. I thought that all engineers ended their career as engineering managers, trading code with meetings. Having always loved the problem solving aspect of coding, I dreaded the thought of work days full of meetings. Little did I know, within one year of graduation, I ended up at the base of the management track leading a team of 4 engineers at Captricity.
At the time, I was not prepared to become an engineering manager. One year of experience taught me nothing about management. I knew little about running meetings, or making important tradeoffs around engineering resources. I struggled to find the right balance between delegating various tasks to stay hands off and jumping right in to implement the solution myself. In the end, I defaulted to taking on the “dirty work” (work that no one liked) while handing off the fun stuff to my peers. While this cleared the path for most of my peers to have uninterrupted bursts of work, I was left with an unhappy work environment fixing more bugs than shipping features.
I also spent more time in conference rooms than at my desk coding. I was brought in on all high level design discussions to act as a “technical advisor,” making comments on how things should be built, even though I was not the one to execute the implementation. While the majority of the times my comments were appreciated by the team (thank god), in some cases, they were considered out of touch. These times were definitely not the most fun I’ve had in my career.
However, over the course of one year, I learned completely new skillsets unrelated to coding. I learned how to read resumes, interview people, do reference checks, resolve cross departmental conflicts, propose product features, facilitate meetings, prioritize features, and spec out multi service architectures. I stopped taking on bugs and started to distribute the load. I took on larger projects where my experience would help, and acted as a mentor providing insight into legacy code bases to the junior members of the team. With each management struggle, I came out better, learning what not to do as a manager (as well as what I should do). Nowadays, I feel less of the negativity towards management and I am even starting to enjoy some aspects of it. Of course, I still don’t consider myself a great manager: I think it takes years for one to become a world class leader.
The biggest thing I learned, however, is that management is not for everyone. Not everyone should, and can become a manager. Sometimes, people are better utilized as a coder. I learned that some people are damn good at coding and fully up to date even after 20+ years in the field (like our Chief Scientist, who is now my role model). And they should be respected as such, being considered as valuable and as experienced as someone high on the management track.
Management is not the be all, end all goal of the technical ladder. People should always be given a choice between being a people leader, and a technical leader that advances and innovates the technology, as opposed to the people. As for myself, I’m still searching for answers.