There and back again: Individual Contributor & Manager – lessons from a dual path career (so far)
Switching between being an Individual Contributor & Manager during your career, back and forth, is an unusual choice, with some remarkable benefits.
Charity Majors wrote about The Engineer/Manager Pendulum a few years ago, but most of it still holds true.
I’ve been in the tech industry for 24 years(!) now, held numerous roles, ranging from numerous Individual Contributor (“IC”) roles, to hybrid roles, to managing individual teams, and managing managers of teams. Much of this has been going back and forth. I have had stretches as long as a couple of years without writing much code at all, to then go back to full-time coding.
This variety has enriched my experience greatly: being subjected to management as an IC made me a better manager. Being a manager made me a better IC, with better judgement and appreciation for the big picture and trade-offs that come with it.
Individual Contributor or Manager? Be only one at a time!
However, what the experience has also taught me is, it is immensely difficult to be both an IC and a manager. It is a fast path to burn-out. And it is also a fast path to alienating your IC co-workers because doing both at the same time is nigh on impossible and should, in fact, never be done in a healthy organization.
It’s fine to go between IC & Manager. But don’t do both jobs at the same time, because they require different modes of working. As an IC, your job is to obsess about the detail, find solutions to problems, while greedily protecting your focus-time.
As a Manager, you need to learn to let go, trust your engineers. Effectively be their shit-umbrella, personal assistant/administrator & enabler. You make stuff get out of their way, so they can do their best work. Your “leadership” should mostly boil down to facilitating when needed, and helping to shape & define problems, so IC’s have sufficient context to make good quality decisions and work in a goal-directed way.
Managers are not “bosses”
The greatest misconception that lives on about management is that managers are “bosses”. Any manager who gets drunk on their formal power is patently unfit to hold the role (and oh, boy, are there many like this!).
In fact, because of this formal authority fallacy, as a manager, one has to be cautious with words and direction. As a manager of technical teams, one should avoid all sorts of “I’ll do the proof of concept”, or “we should use technology X” suggestions. Firstly, it’s supremely disempowering to for teams to not be given the option to choose themselves (within reason, there are a minority of exceptions when management should decide).
Secondly, because of the formal authority-fallacy, your words carry weight. Any suggestion a manager makes will cause psychological pressure, especially on less experienced individual contributors, to do exactly what you said. This is true, even if this was not your intention at all!
Why should anyone switch back and forth?
Given IC & Manager are different skills, different modes of working, why should anyone consider switching back and forth?
The book “Range: Why Generalists Triumph in a Specialized World” gives a few good answers to this:
Firstly, the world is made up of two types of problems, “kind problems” with well-defined domains, suitable for experts to solve. These are perfect for specialists with expertise bourne out of repetition of a specialized skill with learned pattern matching (think golf, chess, well-defined programming problems). The second type of problems are “wicked problems”, problems with uncertain environments and ill-defined challenges with rapidly changing context. These tend to be better solved by generalists.
Secondly, the wicked types of problems (commonly faced in business-, especially startup environments), are best solved by integrating broadly across domains, and “interleaving” these domains to identify which sort of strategy is best suited for the problem. Having a broader range of perspectives greatly helps in doing this.
The issue to sticking to one lane solely is that we do not build a broad enough range of perspectives and ideas to pick from. Our problem pattern-matching can get stuck in a local optima, where we mismatch based in specialized bias, rather than make the right diagnosis. This bias of specialization is quite common across industries. Think of the expression, “if all you have is a hammer, everything looks like a nail”, and you get the idea.
A third benefit of building a broader set of skills is you learn to learn new skills. It is the same concept as language learning: it is easier for a bilingual person to learn a new language than for someone who is monolingual. It is easier yet for someone who speaks four languages to learn another language than it is for a bilingual person, even when learning from an unfamiliar language family. The more you know, the easier it is to learn to know even more because you can draw parallels and mnemonics between unrelated fields and skills.
In conclusion, switching from time-to-time will broaden your skill-set, improve your judgement and pattern-matching. Building a more general set of skills, where you can be effective across domains, can become a personal superpower. The drawback, of course, is, people will find it harder to pigeon-hole you.