The transition from Individual Contributor to Manager was one of the most difficult professional hurdles I think I’ve overcome- in some respects far more difficult than shipping a product.
“What- why?”
Shipping a product is difficult, but in the last phases you’ve generally converged on what it is. It often requires herculean effort to finish the ‘what’ but it’s pretty well defined. Putting in effort on a well defined problem isn’t difficult, it’s a question of time and willpower. Making a move from Contributor to Manager means simultaneously shattering your model of what it is you ‘do’ while being asked to start shaping and aligning the mental models of what others do. It’s going to be a stormy process, and you’re going to initially struggle with sentiments of not feeling like a productive team member.
First, realize your contribution has changed. Every Manager goes through this, and as noted by many authors, Engineers can have an especially hard time with this transition. Engineers are creators, they measure their contributions by system contribution, and application to create new things, visible things, things which can be manifested. As a manager, this is no longer your primary purpose- I don’t even believe it’s a secondary purpose, it’s maybe tertiary at best.
Your primary purpose is now the comprehension of the ‘system’ which is your team. It’s complex and far less deterministic than most of your other systems were before. Embrace it. Apply your knowledge of this system to align it’s members mental models, their notion of where we are, where we want to be, and their purpose in this mission. You optimize their ability to contribute toward the mission by recognizing procedural faults, or poor resource allocation, and mitigating it. Of course there are caveats to this, small team technical leads don’t need to devote as much time to managing, but it’s a good chance to learn the fundamentals.
It’s easy to find new managers trying to do the contribution juggle. What is the contribution juggle? Look for any manager striking out and latching to any task they can do, or not relinquishing control of systems they own. Look for managers missing meetings because they were working on IC work. Look for missed 1:1s. These are red flags.
“Why? More work is good.. we’re trying to ship a product here”
I think there’s often a misconception, and I’ve fallen victim to it in the past as well, that your team will appreciate the hard work you’re doing and see you as someone ‘in the trenches’ with them- and yes, to a point, but if your core responsibilities as a leader or manager begin to drift or become unfulfilled, then you might actually run the risk of falling into another category- a neglectful manager whom cares more about their own work than their team’s optimization.
Additionally, we should ask ourselves why someone needs to snatch and defend a piece of individual contribution. Sometimes this signals a dangerous situation. This can signal a manager who isn’t confident in their role as manager, and is searching for the ‘old medicine’ technical achievements that they can lean on for satisfaction and dopamine boosts. It can also signal a problem with process and scheduling. If there’s no available resources to take on a problem, the manager will do it themselves.
Do it yourself? That’s great, but you’ve masked the problem that got you here in the first place: bad project management. Someone, somewhere, needs to be told we’re asking more than we have resources to accomplish. Working late or on weekends will hit targets, but it won’t solve the underlying issue that manifested this problem. Eventually it will tip the boat, just give it time.
If it’s confidence issues, this can spiral out of control rapidly. A manager feels uncomfortable about managing, snags technical work and avoids the discomfort and learning to get quick dopamine hits from lingering work- but never improves their core management skill sets, and then in turn continues to feel uncomfortable about managing. Eventually they’re habitually late for meetings, or absent in meetings, or signaling working late hours trying to juggle contributions and management work in unison. Their team doesn’t understand what’s going on, and drifts in mental alignment.
Understand that both the problems described are the same thing- a lapse in management. Your job as manager is to understand the system of your team, and it’s interfacing with the organization, as well as the organizations targets. You should then apply that knowledge to continuously optimize your team and those interfaces.
If you aren’t raising concerns on project management, or hiding their ramifications to those higher in the chain, you aren’t doing that.
If you aren’t learning core management or leadership skills and you’re spending 50% of your time trying to remain an individual contributor, you aren’t paying enough attention to your team, the mission, and the organization.
Management and Leadership are not soft ‘born-with’ skills. They are skills to be learned, refined, and applied- just as any other skill set. Sometimes taking on your own technical challenges is perfectly valid (and intellectually stimulating) but next time you open an IDE to take on a technical hurdle, pause for a moment and ask yourself: Is this something I should own, or something I want to own? What skills do I need to development right now to maximize my potential, and that of the organization?
Besides, it’s pretty satisfying building your own technical challenges on weekends- you can still get in your implementation dopamine hits.
R