01 June 2024
"Golly, Evelyn is so smart, she knows everything there is to know about Javascript and React, we need to reward her somehow. Lets make her the manager/VP/CTO and give her a title that mirrors the 'weight' that she brings to the company." Sadly, the Smartest-Engineer Manager antipattern is a trojan horse antipattern--it looks and feels like the right thing to do, but in the long run, it's really not. Evelyn is probably not really ready to have people report to her, and her people-centric mistakes over time come to outweigh her technology successes. Either Evelyn quits, or she is quietly shunted off into a different, hopefully individually-contributing, role.
Context:
Companies (and, sometimes, the engineers themselves) make this mistake out of hubris, the idea that being smart at any one thing translates into being smart about pretty much everything. Hubris runs rampant in the software developer space (witness all the developers who, on message boards and forums and social media who frequently comment--with confidence--on subjects like international law, macroeconomic theory, and molecular biology, despite having had zero training in any of those subjects), and it's natural that it would translate into "sure, I can run a team, how hard can it be?" thinking. What's more, it's a promotion! And in many companies, the only way to crack past the "technical ceiling" is to move out of singular individual-contribution (IC) track (which usually ends at "Architect", which is why the "Architectural Committee" is where good programmers go to die) and into the managerial track--because the company doesn't have any other alternatives for those who want to keep getting better at what they do.
Making it worse, the educational path for an engineer, regardless of whether "classically-taught" (a la the Computer Science program) or "self-taught" (a la bootcamp or self-disciplined review of YouTube videos), often doesn't wind its way through any sort of managerial training. When looking at books to buy, Evelyn often heads towards the "Programming" section of the bookstore rather than the "Management" or "Leadership" sections. If she's challenged to read something that's not Programming, she'll instead choose Architecture or Cloud, because even if the company isn't using those things, they still bring utility to bear on her engineering duties. Or they did, before the promotion....
Consequences:
Evelyn goes from being in a position where she's constantly bringing her formidable technical skills to bear on intrinsically solvable problems to being in a position where she's constantly bringing her unknown human skills to bear on intrinsically unsolvable problems. (Even once a human problem is solved, it's not really, because the problem can manifest again tomorrow in a different--or sometimes even the exact same--context.) Unless Evelyn is actually interested in dealing with human problems, she's being asked to give up what she likes doing to do what she doesn't like doing, and it's hard for her to see this as anything less than a demotion.
Having had little to no training as a manager, Evelyn often doesn't know how to handle certain situations well. Or, in some cases, even legally--she runs a serious risk of doing something illegal and opening the company up to liability.
Variants:
The Longest-Tenured Manager: if an engineer sticks around a company long enough, somebody's going to get the idea of promoting them into a management role "because nobody knows our systems better". Give them the hardest problems the company is currently facing, whether that's releasing a new feature or debugging a nasty Heisenbug, but don't waste their technical brainpower (and highlight their weak human skills) on things like 1:1s and performance reviews. Caveat:
The Architect Manager: At some point, an architect gets frustrated if the team doesn't follow the guidance and "standards" they've created, and start to demand some kind of enforcement authority. The natural next step, of course, is to promote them (often into the CTO role) so that they have some modicum of authority to "enforce the architecture" but without any real clear guidance as to how, when, or with what kinds of corrective action available. (Think about it for a second: Is the company really ready to fire an otherwise-productive senior engineer just because they refuse to use the architect's naming conventions? Or suggested designs?) Considering that architecture in any company larger than 10 people is likely to be its own full-time job anyway, promoting the architect into a management role is only going to create the same pressure on the Architect Manager as the others in this antipattern.
Mitigation:
If you work for the Smartest Engineer: If they've already tried to get out of the role, them simply going to your skip (your boss' boss) and complaining isn't likely to have much impact. (Either they can't, they won't, or they don't want to make a change.) Instead, work with your manager to find some aspects of their job that they don't care for, and see if you can take on some of those responsibilities to help free up some time for them. Some (like performance reviews!) will have to be theirs to do, but others (leading meetings with the rest of the team or with groups outside of the team) you might be able to take on without HR or your skip getting upset. In essence, you're offering to take on a "Chief of Staff" role for them, and it has the fortunate side effects of (a) giving you a taste of management without having to swallow the whole thing in one gulp, and (b) elevating your own profile higher up and wider out along the org chart. This helps your own career mobility and opportunities.
If you are the Smartest Engineer: Talk to your boss. Explain the loss of productivity, particularly if you're also expected to continue your technical duties (a la the Tech Lead Manager) and don't have the time to do both. Identify somebody on your team who is better-suited (either because they have the interest, the human skills or preferably both), and begin to include them in meetings that you'd normally attend alone. (This is called "succession planning" and it's really something you should've started the moment you took the promotion... but it's likely nobody ever told you that.) This is your "Chief of Staff", and as your peers and boss get accustomed to the idea, you'll be able to start offloading some (but definitely not all) of your responsibilities to them--which potentially helps them grow, as well as identify them as a likely candidate for future promotion. Now, with your free time, start focusing on being the "manager" instead of the "engineer".
If the Smartest Engineer reports to you: Instead of promoting them into management, create at least one (possibly two) new tracks for IC roles. (One is to have them get smarter in a deeper technical subject, like the language/virtual-machine technology stack you use; the other is to have them get smarter across a broad viewpoint, such as architecture.) Then, make them a "Technical Fellow' or "Principal Engineer" or some equally-lofty title, with a salary band that's equivalent to a VP, and zero human-reporting responsibilities. Keep them included in performance reviews and loop them in on interviews as subject-matter experts. Keep in mind that if you move them into management, in order to do that job well, they'll need to be managing, which means they're going to spend 100% of their day in meetings with people (on the team, above the team, or outside the team).
Tags: management antipatterns