Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

Common management failures in developing individual contributors

You can't afford to let the ICs on your team feel that they have no career path.
February 23, 2021

You have 1 article left to read this month before you need to register a free LeadDev.com account.

The tech industry has worked hard over the years to make it clear that there is a career path for people who don’t want to become managers.

Most companies have carefully created separate senior career tracks that provide details of the differences between being a manager and being an individual contributor (IC). And yet, many people still believe that you can’t get ahead without becoming a manager, and many companies who want more senior individual contributors struggle to promote people on this path. This is a shame; great engineers really shouldn’t need to manage large teams to get promoted, and companies lose out on a critical skillset when they push all of their good engineers into management. 

Why do we have this problem despite all our efforts? I believe the problem with keeping people on the technical track starts with managers. Specifically, it starts with new managers. You see, most people become managers right at the point where career tracks split between ‘technical’ and ‘management’ specializations. The result is that many new managers have most recently been very technical, yet they have no idea what it means to climb the technical track, and they will be managing people who want to follow that path. To be a great manager, you can’t afford to let the ICs on your team feel that they have no career path, so it’s up to you to manage this well. Here are some common pitfalls that you should work to avoid.

Doing all the technical design work yourself

You’re just coming off of being an IC or maybe a tech lead, so you are still pretty deep in the technical details (especially if you’re now managing the team you were working on). You might still be writing some code, which is fine if you’re managing a very small team. But it is critical that you step back on the technical decisions to make room for the team members to own things and grow. 

This is going to be hard because you may have a small team with a lot on its plate, and the other ICs may not have your skills in communication or project management. If you respond by filling in for their skill gaps, you are going to quickly hit two problems. First, you won’t be able to scale because you’ll be too busy doing technical stuff to take on a bigger team. Second, you won’t be able to scale because you won’t have a person to whom you can delegate. 

Doing all of the project management yourself

This one you would probably love to give up, I know. If you have a very small team, as a manager, you’re the right person to do most of the project management for them. But for their career growth, your technical track folks also need to learn how to run projects themselves. The more senior you get on the technical track, the more that you will be expected to understand not only how to solve really hairy technical problems, but also how to break down the solution into milestones and even into projects that can be worked on by multiple people. 

Teaching someone how to run a project is painful, and they will often say that they don’t want to do the work, don’t want to learn it, and they will make your life difficult in the process. And yet, teaching your ICs these skills is one of the best things you can do for their future promotion prospects! Plus, it’s one of the best things you can do for your own future prospects. A manager who successfully creates a tech lead capable of solid design work and project management now has the bandwidth to take on more and expand their scope. 

Neglecting to give feedback

Many new managers are comfortable giving technical feedback and uncomfortable giving other kinds of feedback. They freely criticize the design and technical work of their team, but they don’t challenge their team members on other growth areas like collaboration, communication style, or project ownership. The result is the impression that management is the way to have technical authority over a group, which leads ICs to wonder what the technical track is even for. 

One of the ways to give feedback that will stick is to give it in the context of career growth. Take the time to understand the technical and non-technical skills that your company looks for in senior engineers, and use that framing to set goals on both of these aspects for your team. This will force you to pay attention to more than just the technical delivery, and make it easier to talk about non-technical areas for improvement as needed for future promotion. 

Hoarding information

You’re now in a position where people will naturally pass information on to you. You may be in more planning meetings with the product team, or staff meetings with your boss and peers, and you may become the person who gets pinged directly when someone has a question or request for your group. This means that you’ve now got a lot more details about what is going on around your team, and this information is critical for you to lead your team well. You must distill this information and then communicate it to your team in a way that helps them understand their work.

When you don’t give your team the context for the work and just pass on tasks and work items to them, you make it clear that they are simply ‘doers’ and your job is the job of the ‘decider’. There is a fine line between giving the team focus time and excluding them from meetings where they would get the necessary information and context to feel ownership of the projects. Your growth challenge is to learn the balance of providing information to the team and inviting them along to get that information, while not overwhelming them with meetings.

Focusing too much on your personal output

As a manager, your output is not measured by your individual work. Rather, your output is measured by the work of your team and the people that you influence. The work you choose to do, and the work you choose to neglect or delegate, will lead to amplified outcomes in both positive and negative directions.

If you continue to focus on your personal contributions, such as writing code, technical design, and day-to-day decision-making, you will constrain the output of your team to only what you can fit into your schedule. If it’s your code that gets you over the finish line for every project, you aren’t providing multiplicative value for the team, you’re providing the additive value of your work as an engineer. When you turn your focus to the work you can do to improve the team’s output by training them to do these tasks, ensuring that they work well as a team, and giving them the context they need to make decisions themselves, you now start to create multiplicative value. When they become more productive and less reliant on your hands-on work, your time is freed to identify bigger challenges. This is the path to growth for the whole team, but it’s hard to find if you’re heads-down in the details.

Conclusion

New managers, make sure that you aren’t trying to be a senior engineer who has direct reports. If your heart is in the code and systems, perhaps you should be on that technical track yourself! Otherwise, remember that your job is now about generating leverage by developing your team, which means delegating the technical work to them while helping them identify other skills they will need to successfully grow as an engineer. If you can do this, you’ll have a bright career in management, and a loyal group of amazing senior individual contributors to work with in the future.