In engineering management circles, a common question that gets asked—in podcasts, in job interviews, and sometimes in peer coaching sessions—is whether managers should stay technically proficient, and if so, how and how much. The subtext here is that as people managers spend their time tending to the actual people on their teams and developing true people skills, there’s little opportunity to keep up with technology as it evolves or even practice the discipline of software engineering. Inevitably, the default middle-of-the-road answer is something along the lines of “I try to work on my side projects in my spare time,” which both sounds unsatisfactory and sets a bad example of not defining work-life boundaries.
Of course, this is just my take on the topic and some completely lean into the idea that management should be completely technical. I guess the idea is that if you’re not a great engineer in addition to a great manager, then your team won’t respect you; you won’t be able to hire great people; you’re not passionate about technology; and you can’t make great decisions.
Hmm, in writing out the arguments in the negative, it does read a bit silly, doesn’t it?
First off, there’s a common pattern for defining engineering roles atop a company’s corporate hierarchy. The definitions that Fred Wilson devised a decade ago are what I see most commonly used: CTOs are chief technologists who advance the state of technology for the team, while VPs of Engineering are responsible for the team itself and its output. The roles are sometimes less starkly differentiated from one another, but what stays persistent is dividing responsibility for the technology and the team across 2 positions1.
The simple reason for having 2 roles is that trying to be both technical- and people-focused generally means you just end up being mediocre all-around. I would hope that a great technologist would be spending the vast majority of their time honing and refining that skill; similarly, a great people manager should orient the vast majority of their efforts towards people-centric matters. It’s akin to expecting your generalist engineer to also be your best front-end developer. And best back-end developer. And best DevOps guru. Oh, and also your most experienced ML engineer.
I often see this sentiment of having your best managers also be your best engineers come from senior leaders who are legitimately good engineers, but are poor enough managers that they are blind to the power imbalance this construct creates. A senior leader who makes both detailed technical and personnel decisions for their engineering team no longer has reliable feedback loops for their decisions. Even if the team respects their technical capabilities, any potential disagreement is superseded by their other power, of hiring and firing.
Another tell is that these highly technical leaders believe that they are there to make tough decisions and that when needed they can perform the job of any member of the team. Sure, there are times when a manager is much more experienced than the rest of their team, and in that capacity, they’re acting more as a Tech Lead/Manager to provide technical leadership. At the more senior management levels, though, the assumption that the manager has to serve as a superset of their entire team and their collective skillsets is frankly impossible. It goes back to the absurdity of being somehow capable of specializing in every engineering discipline—all at the same time—while also bringing excellent people management chops.
Critically, great managers attract and retain talent who are better than they are in their specialized fields. This is trivially true when talking about chief executives: a core skill for CEOs is building out an executive bench for each function of the company, with the explicit goal of that leader making better and more informed tradeoffs for their function. It turns out the same principle applies to CTOs and VPEs; a dose of humility about the limitations of their abilities enables more fruitful partnerships with seasoned engineers, more than some misplaced Darwinian tug-of-war where the boss believes they are always the technical superior.
I also scratch my head around this idea that someone overseeing large parts of the organization can feel like they can make informed, educated tradeoffs in ways that their team cannot. Then again, this happens often enough that there’s even a term for it: seagull management, whereby managers come by when they perceive problems, hastily make decisions without fully understanding complex issues, and inevitably leave a mess for others to clean up. As a VP, your position in the org chart certainly gives you the authority to call things into question and make unilateral decisions, but that’s hardly the same as coming to solutions with the best available information. More often than not, it’s about the leader’s need to feel important and relevant.
That said, it is valid that some level of technical prowess is needed for engineering leadership. It sucks for a report to be unable to explain their problems to a non-technical manager, and when tie-breaking happens they’re usually better made with technical context. Engineering experience can inform architecture and how systems can progress, which in turn helps with the allocation of resources and making areas of investment. And yes, demonstrating technical chops adds credibility and some engineers ascribe a level of leadership excellence to managers who code alongside the team. I advise aspiring managers to spend several years as ICs first before making the jump, to better understand how to build and maintain complex systems and develop enough of a technical foundation to raise the ceiling of their eventual careers.
But the overwhelming interpretation of the assertion that “your CTO/VPE should be technical” is to treat the role like a staff-engineer++. Push the same interview processes; define the whole architecture; filter all code reviews to the head of engineering2. Certainly, these teams do need someone to come on board to address their issues, but someone who can do all of that well—who has spent and continues to spend their career on technical excellence—will need someone else to handle everything else needed for an engineering team to thrive.
