So you’re doing quite well in your career as a software developer. You’ve proven your technical chops several times over. You always deliver the work you’re asked to do. Then, sooner or later, the question comes:
“Are you interested in taking on a management role?”
You think about a little. But you dislike office politics. You loathe meetings. You abhor menial administrative tasks (managers do a lot of those, right?).
Even worse, you think to yourself, you can barely stand working for “the man”. No way you could be the man. The man cares more about the “business” than the quality of technical work. The man is out of touch with technical work. And he definitely cares more about the business than the development team.
No, no, no. You’d be betraying everything you stand for. No way you could do that.
“I’d rather stick to the technical track,” you respond. And that’s OK, you’re told, because your company, like other cool companies, has a “dual ladder” system. You can keep getting promoted, keep having more influence, keep making more money, as an individual contributor (IC).
I’ve seen this scene play out over and over again. And sometimes it works out.
Sometimes it doesn’t because the company is lying about the dual ladder. The managers have (or create) a chummy system that works to their advantage. You’re not in the room when important decisions are discussed or made, but they are.
On the other hand, sometimes it doesn’t because the developer believes they’re exempt from “management-like” tasks. “I’m not a manager, so I don’t need to sit in meetings, I don’t need to worry about influencing other people, etc”. I’d like to talk about that a little bit, because it’s a common mistake I see developers make in their career.
Just because you decide not to become a manager, you’re not exempt from technical leadership.
Technical leadership is broader than management. Most modern software development is not done in isolation. It’s a heavily collaborative, cross-functional discipline. The “people” are necessarily a part of the technical system, often times even more important than the code (and definitely less deterministic).
As you progress in your career as an IC, you will need skills like the ability to communicate with people on your team and outside your team, the ability to influence others, the ability to coach and mentor others, and so on. And as you progress further, you will need to think about what makes your team (or your company) effective or ineffective. These are all skills that are required of managers, but are still very useful for ICs. A manager without these skills will probably fail — an IC without them might just have a stunted career.
I’m not saying you need to spend all your time in meetings, or that you need to learn to play corporate politics. But I’ve seen many ICs who are so turned off from anything management-related that they throw the baby out with the bathwater. So don’t shy away from skills that might seem “managerial” just because you’ve decided to grow on the technical ladder — rather, invest in them!
Another (maybe more cynical) reason to not totally throw out leadership is because your company will have people processes, and as you progress, you will more often be on the receiving end of them. Recruiting and hiring? You’ll go through that process. Performance management? You’ll go through that process, too. You’ll witness good management and bad management. You’ll have to manage up. You should understand those processes, why they are designed the way they are, their strengths and weaknesses. And every process has weaknesses.
So just because you’re not a manager, you’re not exempt from leadership. When people come together to achieve something, leadership is always required. Those with more experience, with more capability, must provide it. Even if their title isn’t “manager” and they don’t have people formally reporting to them.
You have the potential to provide leadership, and that potential implies an obligation to use it.
Somehow Manage 