I went through a career reboot earlier this year. All these years, I grew in my career through the individual contributor (IC) ladder. Sometime during 2019, I realized that it was enough. I wanted to reboot my career and create more opportunities to grow as a leader by switching over to the manager career ladder. Thanks to certain people who believed in me, I got an incredible opportunity to build and lead a new team at the beginning of this year.

I kept quiet on this blog till now, mainly because my mind was as clear as mud for several months. The journey was rocky first, and I had to retool how I work with others, strive for outcomes, and lead. Though I expect to continue this process, my head is less muddy than it was even a couple of months ago. Many people, including the people who report to me, helped with this transition; and I can’t be grateful enough to them. I’m also thankful to the people who suspected my readiness as it helped me understand why.

Most people who manage others start small earlier in their careers and slowly grow to manage other managers and managers of managers. As I skipped these usual stages, I got the luxury of making certain mistakes and developing perspectives that experienced managers may have forgotten about. I want to share my perspectives in this post as I realize that I’m not in the majority and that others may find these useful.

Some of what I share below may sound discouraging for those in the IC ladder, but these are important considerations no manager would tell you. Let me also be clear that I’m a sample size of one, that others may not share my perspectives, and your mileage might vary.

IC and manager career ladders are not equivalent.

IC career ladders are not new in tech companies, and more and more companies seem to be clarifying and establishing separate career ladders for ICs and managers. These ladders clarify competencies, expectations, and differences between different levels in each ladder. For those looking to understand their career progression possibilities, such ladders provide at least a theoretical direction.

Some companies end their IC ladders at roles like Principal Engineer and Senior Staff Engineer, while larger tech companies tend to extend these to Distinguished Engineer and Fellow roles. Career ladders, when published, highlight corresponding manager levels. For instance, a Principal Engineer level might correspond to a Director level, and a Distinguished Engineer level might correspond to a Senior Director. A Fellow might correspond to a Vice President. But these vary from company to company.

As you move up along the IC ladder, you get a perspective of big problems worthy of solving, plenty of access to senior leaders and organizational resources, a seat at the table to influence impactful strategic decisions, and a latitude to work across org boundaries. These are perks that people in the lower levels of the IC ladder or even the manager ladder can only dream about. Besides, nobody will stop you from exploring different problems.

People at the top of this ladder usually have huge followership; they have done a lot to help grow the company and are well respected. It is also common to groom and promote internal candidates into these roles instead of hiring from outside. When someone leaves at this level, the position may not get backfilled at the same level.

However, these roles don’t go on forever. First, IC roles reach a plateau sooner than managerial roles. Your career progression stops upon reaching the senior-most IC level. This may be acceptable for you as long as you retain the flexibility to solve your company’s most impactful or niche problems just through influence.

Furthermore, IC career ladders tend to run steeper than the corresponding managerial ladders. Just count the number of individual contributors and managers at the topmost IC level and the equivalent managerial level in your company. Fewer and fewer get to climb to the top, with most getting stuck in the middle. Although this is generally true for managerial roles, manager ladders seem to suffer less from this steepness.

As I began to realize that I’m leaning more on influence than on specialized skills to get things done, the fanciness of the IC ladder began to fade away, which brings to my second point.

To be successful as an IC, you must be a great influencer.

I can’t emphasize this point enough. If you are an IC and like to continue to grow in your career and do impactful work, you better learn to like people and learn to influence them. Don’t expect to continue to grow in your career by being the fastest or the best coder in the team. Even your deep domain knowledge acquired through working for years on the same set of systems might not help you keep going. Eventually, others below your level will do better than you do. The sooner you learn to scale yourself through influence, the better for you. I sometimes run into ICs that want to code and don’t want to deal with people. That may appear fine but be aware that such an attitude will limit your career growth.

The single most important advice I give to ICs is to learn to solve ambiguous problems. Ambiguous problems force you to learn to influence. It’s common to equate dealing with people and influencing them as “messy politics,” and I can tell from experience that it is a mistaken and counterproductive perspective.

In my case, all the impactful problems I could solve in recent years were entirely through influence. But influence is a slow process. While it may take several weeks or a few months for you to go deep into a problem and find a way to solve it, depending on your organizational culture and structure, you may have to spend a lot more time influencing and mobilizing others to execute the solution.

Moreover, as you go up the IC ladder, you will find that individuals and teams within the existing organizational structures can already pick up all easier problems. Consequently, the problems you pickup tend to be ambiguous with no clear ownership and accountability. Solutions may not fit well within existing structures and processes. Therefore, you need to have patience and tenacity to use your influencing skills to navigate organizational boundaries to align people.

IC roles are also consultative.

Influencing is a great force multiplier. When successful, you will find others preaching your ideas and approaches and multiply your impact.

However, the flip side of leading through influence is settling for consultation. As you get better at influencing, you may find that your role becomes increasingly consultative in nature. You will often get asked for inputs, and those inputs often count. However, inputs are not decisions. Due to organizational or business considerations that you’ve limited control over, your inputs may not see the light of the day. Accountability for outcomes usually lies with managers. Consequently, many key decisions, including hiring, team structures, objectives, decisions to start/stop projects, etc., lie with managers.

Also, no one is obligated to follow you and line up behind you unless they see value in what you’re proposing. Consequently, even when you succeed in influencing people across organizational boundaries, people may decide to follow their managers and not you in case of conflict.

These ladders diverge as you move up, making it harder to jump.

IC and manager ladders diverge as you move up. Opportunities to jump from the IC ladder to the manager ladder become far and few as you move up the IC ladder. The longer you stay in the IC ladder, the harder it would be to jump to the manager ladder. Jumping is possible, but you need to be patient and need sponsors who believe in you and clear obstacles.

Finding such sponsors won’t be easy. Even the people that worked with you closely in the past and leaned on your technical and influencing abilities to get major projects done will hesitate to take the risk of sponsoring you or giving you the opportunity. They may believe, rightfully so, that you are not ready or that you may not succeed as a manager. I’ve had this happen to me as well, and understand the risks involved. There are several valid reasons, but let me cite the three that I found most important.

1. First, your organizational leaders would have no way to judge how you would react in difficult or emotionally challenging situations. To give you a simple example, consider the difference between providing poor feedback about someone to their manager and acting on such poor feedback about someone you manage. It’s easier to give feedback than to take timely and constructive actions on people you manage. Others have no way to know how you would handle such situations.
2. Second, leading through influence as an IC is different from managing. As a manager, you will have to learn to use managerial leverage to improve organizational performance. For example, as an IC, you will tend to get down to work and develop one or more ways to solve the problem when you find an interesting problem. But as a manager, your job is not to solve it yourself. Your job is to leverage the people in your team, create a sense of why it is important to solve the problem, orchestrate means for the team to figure out how to solve the problem, and then set up supporting mechanisms to ensure that the problem gets solved.
3. Third, in case of failures, managerial roles have a larger blast radius than corresponding IC roles. It is easy to contain or repair any damage that an IC can cause to an organization. You can contain the repair to just that individual. But containing or repairing an ineffective, or arrogant, or know-it-all manager’s damage can be difficult. You may have to rebuild the entire organization.

There are more. As an IC, you may have theoretical knowledge of such differences and situations from reading books and observing managers. You may have hypothetical solutions to tackle challenges that managers need to deal with. But without a track record and muscle memory formed through trial and error, your chances of failure are high.

As they say, the grass is greener on the other side. Both roles offer you a way to learn and drive change. But, if you’re an IC that wants to jump to the managerial ladder, be patient. Continue to develop leadership competencies like influence, creating paths for ambiguous problems, dealing with conflict, etc. Even if you decide to stay on the IC ladder, these competencies will take you farther than your domain skills. As Tanya Reilly says in her Not all engineering leaders are engineering managers, “many of the leadership skills that make for good managers (e.g., setting a clear direction, caring about other humans, understanding the business, building consensus, communicating ideas) are also the ones that make stellar senior, staff, and principal engineers.”