All Posts

A Fork In The Career Ladder

Photo by Oliver Roos on Unsplash

I’m standing at a fork in the career ladder.

To the left is advancing as an individual contributor to become a principal engineer. This means taking more responsibility of technical decisions and solving harder technical challenges.

To the right is making the jump to management. While still involved in technical decisions, the role is more focused on managing people. It’s about leading a team of people to achieve company goals.

How should I think about this decision?

For a long time, I thought I wanted to go down the individual contributor path. Communication and leadership are not my strong suits. I’m much more comfortable being part of a team and supporting others.

However, as I get deeper into my career and get exposed to what technical leadership actually involves at the highest levels, I realize that the job involves just as much communication and people management.

Once I became a principal engineer, it quickly became clear to me that my job involved a lot more than closing tickets and writing code to achieve things.

I also realized that while I am still an individual contributor, the principal engineer role carries enough cross-organization work, and enough people skills, that it is much closer to management than it may seem without engineers reporting directly to me.

https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html

That post showed me that both paths are about managing people at the end of the day. On the principal engineer side, even though I don’t have any direct reports, I’m still leading a team, guiding junior engineers, and communicating across teams to accomplish goals. On the management side, I’m explicitly managing others, responsible for their growth and morale, and responsible for business outcomes as well.

From the same blog:

Once at a certain level, all problems are solved by people. There is no such thing as ‘purely technical problems’. In fact, this is the level where one wishes more problems were purely code because we can make code do a lot of things. Making people do anything is harder and influencing people to do what we want is harder still.

This is what principal engineering is about. The role is far less about solving intricate technology problems (although there is that too) and more about being a good influence, convincing the rest of the technical team why Thing A should be solved with plan Foo and not plan Bar.

https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html

I need to develop my communication and leadership skills no matter which path I ultimately choose. My fear is that my technical skills will atrophy. How can I keep my skills sharp while my focus is on improving my communication and leadership skills? That’s a post for another day.