“I don’t want to be a manager” is always a sad line to hear from software engineers. Granted, I have a conflict of interest: I’ve chosen this line of work as my profession for the last 5+ years, and it turns out that hiring engineering managers is generally even harder than hiring good engineers. When people preemptively opt themselves out of the possibility of a future in management, it likely ends up giving me more work.
And hey, I understand the sentiment. Even assuming that parallel career paths exist at a company for individual contributors (ICs) and managers, more role models—in the form of senior engineers—exist for mid and junior-level folks 1. To make matters worse, the role of management is stereotyped as a meeting-centric, consequence-ridden, and judgement-heavy. It’s not an unfair or completely inaccurate assessment, and some folks are completely correct in declaring their disinterest and unsuitability.
What I like to point out is the necessary trait of leadership that exists for experienced—and hence, senior—engineers, whether they choose to manage people or otherwise. It’s an important distinction, as sometimes the tactical maneuvers employed by managers:
- Making decisions via meetings
- Establishing and documenting a new process or development workflow
- Reorganizing teams and communication patterns
Are mistaken to, by themselves, constitute the role of a leader.
Instead, let’s just define the term “leadership” tautologically: a leader is someone who others follow. This video is a great take on this simple concept:
I point this out, because detesting the way leadership manifests in management roles is focusing on the wrong area. Leadership is expected of experienced folks, because they are relied upon to be the mentors and role models others look up to. From the standpoint of building complex software systems, a senior—or lead, or principal, or whatever titles denote experience—engineer is the anchor for the team, someone who others will follow to execute on the project.
Sometimes, that role requires holding meetings to discuss and decide on a technical direction. It may mean having to justify an architectural investment to non-technical folks. Hell, it may even mean evangelizing a new process to onboard the rest of team who are less familiar with your new coding methodology. When it comes down to how leaders work, people leaders and technical leaders often end up employing the same techniques to earn that quality.
So if you’re running away from a possible future in management because you just really hate writing performance reviews, that’s at least a fair conclusion2. But becoming a more experienced developer—whether you define it as working on bigger systems, having more impact, or earning more authority and decision-making credibility—requires, not necessarily the ability to manage people, but the propensity for earned leadership.