Some time ago, I sat at a table littered with business detritus in one of those small, “private” conference rooms whose windows attract the flickered glances of everyone outside it, listening as my manager gave me advice. “You’re a good manager, but you should probably avoid participating so much with the technical parts. You’re never going to be as strong there.”
A few years later, I sat in a similar room chatting with an engineer who asked a surprisingly difficult question: “Why is it important for managers to be technical?” I quickly answered that there were clearly many good reasons, and then stopped and stared blankly when I tried to enumerate them.
More recently, I referred a friend for a management position. My conversation with the hiring manager went well, but toward the end of their questions, they surfaced their core concern about my friend: “They seem great, but are they truly technical?” This wasn’t the right moment for me to share that I’m increasingly unclear on what it even means to be “technical”—so I just said yes.
Industry trends drive hiring practices as well as job requirements. Around 2010, with Google ascendant, product managers were finding more and more doors closed to them if they didn’t have a computer science degree. If this policy worked for Google, it would work at least as well for your virality-driven, mobile-first social network for cats.
Management has trends, too. One of the oldest is scientific management, codified in Frederick Taylor’s 1911 book, The Principles of Scientific Management, which advocated combining pervasive data collection with the scientific process in order to optimize manufacturing results. According to Taylorism, as it was called, the manager’s aim was optimal utilization of their resources, and management was conducted from a sufficient distance that workers and wheelbarrows took on the same fuzzy appearance.
Taylorism remains alive today—look no further than the gig economy—but its ideas hold little sway in modern engineering management. Modern best practice was influenced equally by the “knowledge worker,” introduced in 1969 by Peter Drucker’s The Age of Discontinuity, and the research-driven style developed at institutes like Bell Labs and recounted in Jon Gertner’s The Idea Factory.
As knowledge workers, software-development teams spend most of their time working on problems that they haven’t solved, which blunts the impact of precision measurement and optimization. As researchers, they control both the problem statement and the solution, which provides an ideal inroad for creativity, unpredictability, and innovation.
When considering both the knowledge-worker approach and the research-driven one, the most common definition of engineering manager today emphasizes the responsibilities of guiding and enabling teams to navigate uncharted seas filled with novel problems. Being technically proficient in the area of work is important to both traditions, and is particularly central to the research-driven approach.
Software companies have mostly learned this lesson, and now the vast majority of engineering managers come from software-engineering backgrounds. This is true both at the market-elected collection of technology companies known as FANG (Facebook, Amazon, Netflix, Google) and at the latest crop of technology IPOs, like Fastly, Lyft, and Slack.
Being technically proficient in the area of work is important to both traditions, and is particularly central to the research-driven approach.
While engineering management has not prioritized its own measurement, there is evidence that expert leadership works in some fields. Amanda Goodall’s 2011 Social Science & Medicine journal article, “Physician-leaders and hospital performance: Is there an association?” states that expert-led hospitals score 25 percent higher on quality measures than do facilities not led by experts in the field. If this is the case, modern technology companies are already well along the right path.
This is where the story gets a bit odd. If we know that managers with technical skills outperform others, and we’re already hiring managers with backgrounds as software engineers, why are we still worrying whether they’re technical? If these folks have proven themselves as practitioners within their fields, what is there left to debate?
Sure, there is anecdotal evidence to the contrary. If you work long enough, you’ll collect a handful of secondhand horror stories: We’ve all heard the one about a manager who was “promoted out of the field” because their engineering efforts were sufficiently hazardous (and leadership was sufficiently conflict averse) that their company moved them into the “safe” role of managing their peers’ careers. But that story, if real, is the stuff of exception. Most folks I’ve seen painted as “not technical” have an extensive background in software engineering.
This is an awkward inconsistency. The most likely explanation is that “being technical” has lost whatever definition it once had and has completed its devolution from demarcation to slur. Personally, I’m working to clear out space in the crypt where I buried “not a culture fit” and inter “not technical” beside it. It’s uncomfortable to recognize that a distinction I relied upon so heavily for so long no longer means anything to me, but comfort has never been a good reason to get into management. With the term “not technical” unusable, I instead focus on the details. Is there a kind of technology that a given person is not familiar with? Were they uncomfortable, or did they lack confidence when describing a solution? Would I care about them knowing this detail if I didn’t personally know it? Given their role in and relation to the project, was the project’s success dependent on them knowing these details?
Unpacking the tyranny of “technicality” has also helped me better understand how to navigate my own career, focusing less on role (no longer chasing the coveted title of vice president) and more on particular skills (like public speaking at conferences and clearer written communication). The path doesn’t have to be linear, and there are many ways to travel it. (One particularly good arc is captured in Charity Majors’s blog post “The Engineer/Manager Pendulum.”)
Looking forward to the next 30 years of management trends, only a few things seem certain: Managers should be technical, and the definition of technical will continue to change. We are still in the earliest phases of our industry’s development. Today’s status quo feels permanent, but collectively we can change our vocabulary and our beliefs.