Solid lines signify effectiveness; dotted lines signify fraction of total effort spent on low-level technical work. The person spending less time on low-level technical work is more effective toward the beginning of their tenure. But due to (a) changes to the technical field and (b) loss of memory and practice, their effective utility is quickly reduced.
Consider a scientist or engineer with several years of experience—someone who’s at least a decade beyond earning a degree in physics, engineering, computer science, or chemistry. She might be working at a large technology corporation, co-founding a startup, or starting as a professor. Regardless of her employer, she was selected for a management or leadership role because of her exceptional technical skills. The thinking behind this is clear: rather than focusing on the finer details of one project, her advanced technical knowledge can add much more value when applied across many projects at once.
Many people in such a position feel they no longer have the time or the will for coding or other technical work. They quickly become pure bureaucrats. And while it’s not universal, the belief that managers don’t even need to continue some hands-on work is widespread. This notion is so accepted that some high-profile CEOs don’t even have any education in the field they're managing.
In fact, it’s not only uncommon for managers to get involved in technical work—it’s sometimes considered improper. A collaborator of mine (at a big tech company) once told me that his manager liked to help out with coding. Though he wasn’t required to do so, he enjoyed it. But rather than being appreciated for this extra effort, he was criticized for this by other managers. I guess they didn’t like the idea of him outshining them.
Further—incredibly—hardcore technical work is sometimes thought to be disqualifying in determining whether to promote. I’ve seen this before IRL. But it’s perhaps best captured in Joseph Heller’s novel Catch-22, where protagonist Yossarian muses about a colleague:
Orr was an eccentric midget, a freakish, likable dwarf with a smutty mind and a thousand valuable skills that would keep him in a low income group all his life.
Valuable skills will keep you down, the thinking goes. This is a surprisingly common opinion.
I hold a mental model that contradicts these views. Here is how I see it. Consider Alice and Bob. Both worked in a software-related field and were promoted to manage a team of around 10 people. Bob decides he’ll stop doing any coding whatsoever, while Alice decides she’ll indefinitely set aside 20% of her time for “real” technical work.
In the very beginning of his time as manager, Bob is a more effective leader than Alice, because he spends 100% of his time setting and correcting the direction of the team. But as time goes on, he slowly becomes less in touch with the changes to computer languages, with new packages that people use, with novel mathematical approaches that have transformed his field. Because he is no longer a real practitioner, he even begins to forget fundamentals, losing touch with fundamental algorithm design principles that he never thought he’d forget. As a result, his performance slides.
On the other hand, Alice spends only 80% of her time on management. Hence she is roughly 80% as effective as Bob is in the beginning. But because she holds on to a chunk of low-level hardcore work, she is able both to continue having a feel for the field and to have a deep understanding of the new industry trends. Alice, I am completely convinced, will be the more effective manager in the long run.
I posit that this mental model is correct across industries. Software engineering. Mechanical design. Food companies. Academia. (Happily, in some industries this is already the model–many newspaper editors, for example, never stop writing.)
Further, Alice will be able to more effectively distinguish between high-quality and subpar work. Antonio Garcia Martinez phrased it well in his book Chaos Monkeys:
The principal reason for you [a project manager (PM)] to be technical is not to help technically design the system under development; if you’re doing that, then you’re PMing wrong. No, you’re technical so you can tell when engineers are bullshitting you, which will be often. At times it’s accidental [...], due to either miscommunication, bad memory, or wishful thinking (engineers are as inclined to it as anybody). Sometimes it’s more stealthy, their passive-aggressive way to disagree with the product direction (“That’ll eat up all our servers”), or laziness (“It’s impossible to build that”). The PM is there to give a sniff test to any such product-killing assertion.
In the long run, you cannot be an excellent leader without continuing to engage in deep, low-level technical work. A similar argument applies to non-technical managers, such as those running a media company. Happily, this perspective is freeing. I know many scientists who regret no longer having time for the science they once loved because they've become professors or group leaders. However, the reasoning I’ve outlined offers a justification to return to those roots and carve out time for meaningful work—without any guilt.
Comments