On Servant Leadership
The first time I tried implementing something I'd call servant leadership, I misunderstood the whole thing. I thought it meant being perpetually accommodating. I spent three months clearing every minor inconvenience from my team's path, saying yes to every request, shielding them from management, and treating any feedback as an attack. Productivity dropped. Quality slipped. People stopped caring because there was no friction to create standards. I learned pretty quickly that the model isn't about comfort. It's about removing obstacles so people can do the work they're actually hired to do. The core idea comes from Robert K. Greenleaf, who wrote about it in the 1970s, but anyone who's managed a team knows the concept independently. The leader's job is to serve the people they lead, not the other way around. The measure of success isn't how much authority the leader accumulates. It's how effective and happy the people become. That's it as a definition. The practical application is a lot less intuitive. When I ran a platform engineering team, we had a deployment process that took forty-five minutes because of manual approval gates, flaky integration tests, and a deployment tool that required context-switching between three different dashboards. The problem wasn't laziness. The system was the problem. I stopped asking the team to work faster and instead spent six weeks rebuilding the pipeline. We cut deployment time to eleven minutes. Nobody complained about being micromanaged after that because the work itself became tolerable.
That's the actual mechanic. Identify what's blocking people and remove it. Not just once, but continuously. It's a operating rhythm, not a one-time event. Most leaders treat these things as background noise and move on to other priorities. The ones who make it work track what the team complains about the most and tackle those items with the same urgency they'd give a production outage. Here's the part nobody warns you about. This approach breaks when the person you're trying to serve doesn't want to be served. I had a senior engineer who actively resisted having his blockers removed. He wanted to fight through things himself and viewed my intervention as a sign that I didn't trust his judgment. He'd accept the help politely, then deliberately slow down to prove a point. I stopped trying to clear his path and started framing the support as optional consultation instead. He it within a week. The workaround was basically letting him think he was in control while I handled the actual obstruction removal. Another counter-intuitive thing: servant leadership requires more authority, not less. You can't remove obstacles if you don't have decision-making power. I've seen leaders try this model in organizations where they lacked budget control or hiring authority, and it collapsed immediately. They could offer emotional support but couldn't actually change anything. The team noticed and lost respect for them because support without leverage reads as manipulation. If you can't move resources, change processes, or make headcount decisions, you need to get those things first before attempting this model.
There's also a timing problem. During a P1 incident at 2 AM, servant leadership is the wrong approach. You need command-and-control. Clear directives. Someone making unilateral calls. Trying to serve the team during a crisis usually means slower decision-making and confused responsibility. The model works during planning, execution, and development phases. It fails during active fire drills. I learned this the hard way when I let a team vote on incident response priorities during a cascading failure and we lost two hours we couldn't get back. The biggest pitfall I see is confusing servant leadership with being a pushover. They're different. A servant leader says no to protecting the team's focus, says no to bad deadlines imposed by upper management, and says no to processes that add no value. They also say no when someone on the team isn't pulling their weight. Serving the team doesn't mean enabling poor performance. In fact, it means doing the hard thing of addressing underperformance directly because letting it slide hurts everyone else. There's a specific tension with high-performers. They often need less hand-holding and more autonomy. The standard servant leadership playbook of regular check-ins and proactive support can feel like micromanagement to someone who just needs to be told the goal and left alone. I adjust my approach based on the person. For a mid-level engineer building confidence, I do weekly one-on-ones and offer unsolicited guidance. For a principal engineer, I send a Slack message once a month asking if they need anything and otherwise stay out of the way.
Get the Full Details
The metric that actually matters is retention and throughput, not satisfaction scores. Engagement surveys will tell you if people feel heard. But the real signal is whether people stay and whether they ship more quality work. I tracked both for eighteen months after switching to this model. Turnover went from 23 percent annually to 7 percent. Deployment frequency increased fourfold. These aren't the only factors, obviously, but the correlation was strong enough that I kept doing it. If you're in a role where you genuinely don't have authority to change anything — no hiring, no firing, no process control, no budget — then this model won't work for you. You'll burn out trying and accomplish nothing. In that case, the alternative is influence-based leadership. Build credibility, earn trust, and slowly expand your sphere of impact through informal channels. It takes longer but it's the only realistic path when formal authority is absent.
