Engineering Management - Technical Leaders
Share
This is the fifth and final part of a series of notes regarding my thoughts during my time in engineering management at Facebook. Read the intro here.
Technical Leaders
All external management hires must be able to write code and show a high level of technical proficiency, up to and including the head of the technical department. If the company is a technology company, this should also include the CEO.
There is an odd misconception that this is not a necessary requirement for an executive or manager, as though programming were just a fancy form of typing. No other specialized industry seems to feel this way: banking executives are expected to be able to read a balance sheet; an automotive executive would never be hired if they didn't know what a catalytic converter did.
Alternatively, it's sometimes said that technical proficiency is impossible to test for, because a great management candidate will have likely spent the last few years managing, and not directly in touch with the technology. And besides, a great people manager can manage anything. This is false.
Certainly the candidate should not be expected to build a full-scale system at the limit of current scalability technologies, or tune a chipset down at the metal, or recite obscure syntax for a particular language or framework. But it is entirely reasonable and desirable to test if a management candidate has a strong individual technical background. I refer to basic tests for skills which, if the candidate had ever been a competent technical contributor they will inevitably retain, such as coding tests involving some simple iterative or recursive algorithm, and conceptual tests involving elementary computer science concepts like pointers, hashing, and operating system fundamentals.
For example, one particularly low bar includes the fizzbuzz question. Many readers here may assume that this is a test that any programmer could pass, but this is not true. There are numerous, numerous programmers who cannot do this (not that being able to do this means you're a good programmer, but not being able to do it definitely means you're NOT) and early in their careers, they found they weren't good programmers, and because they happened to be in an organization without strong technical rigor, they were promoted because they happened to be good with people (or good at using people). Many of these people fill the ranks of technical management and executive candidates today.
Furthermore, they are usually very skilled at talking a good game and sounding like they know what they're doing (or they wouldn't have gotten there). The only way to determine if a candidate has real technical competence is to either (1) subject them directly to a simple coding test of the nature I described or (2) find some open-source code they've written which you can directly evaluate. [Example]
Candidates who cannot pass these tests or who don't have a verifiable record of public technical work should not be hired.
The reasons should be obvious, which is that management needs to be able to tell what's going on in order to make informed decisions. A skilled non-technical manager can get a pretty good idea, but all other things being equal, they will be outperformed by a similarly-skilled manager who has a technical background. Further, they will certainly not be able to provide technical leadership, and if you want your company to be a technical leader, your leaders first need to be technical.
A "technical" organization whose leadership is non-technical fails in one or both of the following ways:
1) Leaders are unable to tell when the technical staff is not performing up to snuff, because they cannot reliably differentiate between excuses for poor technical performance and true obstacles that arise when contending with difficult technical challenges. Performance management then becomes impossible, leading to mediocre work and eventually, outright and repeated project failures.
2) Business needs cause leaders to override the suggestions or opinions of the technical staff. Today's harsh business environment requires that business leaders push their organizations continually beyond their old boundaries, and sometimes this means that a leader has to tell their staff to "damn the torpedoes" and stretch further than they are comfortable. Unfortunately, a non-technical leader has no personal ability to gauge the actual risk profile of overriding technical suggestions (i.e. shrewdly exceeding old limits in certain special situations) and is then prone to eventually overriding technical advice which should not be overridden.
At companies other than Facebook, I have witnessed more than one large system failure that stemmed from a lack of core technical literacy in the executive staff. At Facebook, individual technical competence happens to be required of all engineering management staff and extends all the way up to the head of the department and includes the CEO (who continues to participate in Hackathons). This allows the company to repeatedly take daring technical risks in order to achieve significantly innovative product goals and execute at a consistently rapid pace: the more you understand the rules of the game, the better you can play it.