I’ve never liked the term “servant leadership.”
As I eased into my engineering director role, one of my main responsibilities was conducting interviews for a wide breadth of engineering and engineering-adjacent roles. With engineers, the technical portion of the interview inevitably meanders into projects that require spinning up a microservice or three. Project and program managers gleefully list out their ScrumMaster and Agile credentials. Product managers always make it a point to emphasize their obsession with the customer1. And when it comes to engineering managers and directors, I’d posit that in well over half of my interviews, I’ll have a candidate talk about how they’re servant leaders who serve as enablers for the people who report to them.
That’s not to say that the theory itself is bad; far from it, the characteristics defined in the original article—empathy, an emphasis on individual growth, leaning on persuasiveness and influence—stand in sharp contrast to the command-and-control, authoritarian leadership style common in supervisory positions. I distinctly remember the former CFO of Square, Sarah Friar, espousing a core principle of “People First”; I’ve stolen that catchphrase and have added it to my managerial repertoire.
The “strong leader” archetype gets a bad rap among the rank-and-file managers2 because it’s associated with micromanagement, aggressive operating style, and overbearing demands for production. I get it—if you’ve worked under a boss like this early on in your career, the instinct is to avoid repeating the sins of the past. The vast majority of us don’t get away with emulating Steve Jobs and Elon Musk, and academic studies have proven that, despite popular sports culture, intimidation doesn’t squeeze more out of teams.
The instinct is then to go in the other direction and emphasize management support. The label of operating as a servant leader, and its common understanding among our cohort of people managers—those who have risen through engineering ranks—often takes the theory too far. That is, engineering managers shape their roles solely to serve their engineers. Examples highlight how they exert the extra effort to unblock their reports’ tasks, or put in time to lay out career paths and follow up fastidiously, or cite mentorship as a core motivation to pursue the managerial career path. Certainly, these activities are what managers should be doing for their teams, but they should not be the only accomplishments. What’s missing are some of the qualities stereotypically associated with strong leadership: crisp decision-making, clear communications, and consistent output.
This feels particularly relevant in our industry today. The job market for software engineering managers has been particularly rough these last few years: high interest rates have already shrunk department budgets, and AI-enabled development further reduces the raw amount of software engineers needed, with that ultimately propagating to the management layers above. Some of these most recent layoff rounds have highlighted an intentional flattening of the org chart, where their people managers aren’t adding enough value—output—to justify their costs and added organizational complexity.
I speak from experience. In going from engineer and working my way up to running engineering organizations, there were points along the way where I embraced the role of the servant leader, though not quite in those exact terms, and spent most of my energy on nurturing my team and, at times, my peers. I leaned hard into my volunteer work at Plato to hone that skillset. I consistently received stellar reviews from my reports on how I managed the team.
Things started unraveling at the director level, with more than one layer of managers between me and the engineers. A part of the problem is simply scale; taking care of every single person on the team takes a lot of work with each individual, and there weren’t enough hours in the day. But the tough feedback from my CTO at the time was that gradual improvement of the team wasn’t good enough: absolute output matters. Given the lengthy feedback loops inherent in management initiatives, modeling the right behaviors and taking action—overriding a report’s area of responsibility to make quicker decisions—is sometimes necessary to set an example. Another way to frame this style duality is to figure out when to lead from the front, versus leading from behind.
And as with most things, the key is establishing a healthy balance and varying your approach as the situation demands.
