The In-Between of Being an IC and a Manager

Problem

Many companies tend to create a role that blends the responsibilities of an IC and a manager. That person should be a leader for an engineering team, but the one who also contributes. We also did that, and we did for quite some time before we realized that by doing so, we are asking someone to do two things that don’t fit well together.

Actions taken

We introduced a new role, named team lead, a split role between management and individual contribution. At first, it seemed that this split role yielded results. Many people wanted it to succeed, and when people are seeking change, they are motivated and willing to put in the extra effort. That is a phenomenon widely elaborated in change management; every change will be positive for a while. But the question is not does it get better, but does it stay better. Therefore one needs to be sensitive to the idea that this split role may not be working. It took us almost two years until we realized that it was not working.

In our dual career track, a team lead was inserted between the two tracks -- it could be a springboard to management being 50/50 management and IC, but it could also mean prolongation of contribution work. There was a clear break of how people took the role. One group did only managing and didn’t do any contribution while the other did mainly coding and did a half effort on the management side.

It was a 50/50 role, and they didn’t have a management ratio to be full-time managers. They simply couldn’t be full-time managers while managing four people without spinning their tires a bit. The same could be applied to people who did a full-time contribution. Though that was not our conscious intention, we were in effect forcing people to choose between the two, and those two were incompatible activities. Also, their schedule didn’t allow them to be productive as expected. As noted by Paul Graham in his succinct article “Maker’s Schedule, Manager’s Schedule,” as a manager, one would have to attend a lot of meetings, and their schedule will be broken up a fair bit. On the other hand, as a contributor, one would need blocks of time to create value.

The end result of efforts to introduce a split role was that incredible developers did okay-ish management and vice versa. We found out that a large majority of people did poorly because combining the incompatible activities was not achievable. What we did was to relegate our star performers to okay. That was enough for us to rethink our approach. We decided that management should be a dedicated role. We introduced EMs, which is a standard industry title for people managing ICs, but we made sure they had a management ratio that could be a full-time job. We have recently changed this and made management a dedicated role for which we would promote or hire an EM, We would allow people to try it for a while, and if at any point they would decide to step back, we would support that decision. We never wanted it to be “you either get in or get out.”

Lessons learned

• When an organization scales, at some point, one needs to hire managers. Many people think of tentatively stepping in and having it as a part-time role. Don’t do that. You are either not big enough to need managers or you are big enough to have dedicated managers.
• Be critical of your ideas. Of course, you want something to succeed, but if after a while something doesn’t work out, it might be the plan and not the people.
• Most of the time, people fall under one of the two (manager/IC) because it is difficult to be good at both. Forcing them to do both will bring no success, and they will be inclined at most times to choose one over the other.
• Make sure to have realistic expectations that are communicated to team leads. An imposter syndrome is commonplace across the engineering world and when people are put into a new role, they will attribute all hardships to their own incompetence and not the inherent contradictions of the role.