From Servant Leader to Situational Leader

I used to describe myself as a servant leader, and at the time, it was true. This was early in my management journey when I was a new manager, and even before that when I was an engineer with aspirations toward management. Before becoming a manager, my influence on the team was purely without title. My goal was to elevate the engineers around me, to see the team succeed, to improve how we worked as much as what we were building in code each day. It was pure. The servant leader ethos fit. And I think that’s true for a lot of engineers who become managers. Servant leadership fits most engineers pre-management precisely because they experience influence without authority, credibility through contribution, helping teammates succeed, and aligning with engineering culture.

Over time, I evolved as a manager. As much as my goal was still to help the engineers on the team and enable them to be their most impactful selves, I suddenly had other goals too: deliver an incredible roadmap, structure the team to support their growth and my own, and show leadership I was capable of matching (or even exceeding) their expectations. Managers serve multiple stakeholders, not just our teams. We serve our team, our roadmap, and our organization, and those constraints shape nearly every decision we make.

And here’s the kicker: servant leadership alone doesn’t resolve conflicts between them. At some point, every engineering manager discovers this the hard way.

When I became a manager, the narrative I had told myself about being a servant leader started to create tension with the role I was now expected to embody. Often I couldn’t even define what that tension was at the time. I was naive and slightly moralistic. I assumed senior leadership didn’t care about my team as much as I did. What I didn’t yet understand was that their responsibility extended far beyond my team alone.

As I managed my first team, I only made changes by “nudging”. Nothing dramatic, nothing sudden. Everything had the support and full buy-in from the team. It’s the approach I had used as a team lead when I didn’t have authority to operate differently. I was playing it safe because it’s all that I knew at the time, and I prioritized the team’s immediate comfort over the deeper changes they actually needed.

With my second team, they were in a very different position when I took over. They had a lot of broken processes, zero trust, and change-fatigue. If I tried to nudge them in the right direction it could take years, and I’d lose the trust of my director in me that I was in fact capable of managing the situation. So I took a different approach. I made a series of sweeping changes. I called it a level set and explicitly told the team that they could (and should) iterate on each of those changes but we needed to start from a healthier baseline than the one we were currently operating at. 

I was terrified. I was a dictator! They would hate me. Instead, the only engineer who strongly resisted the reset was someone who ultimately wasn’t a fit for where the team needed to go. Everyone else adapted, the team did iterate, and by the end of the year we were the highest delivering team in the subdomain.

I didn’t stop being a servant leader. I stopped believing servant leadership alone was enough. 

It wasn’t until a few weeks ago that I could even properly articulate that I had made this evolution. I participated in a discussion where a group of engineering leaders were asked about their style of leadership. People gave various responses and the facilitator said something along the lines of, “I’m so glad no one said ‘servant leader.’ You wouldn’t believe how often we get that as the answer.” I realized servant leader had been the phrase floating in my own mind as the one I used to identify with, but I didn’t say it out loud because I knew it no longer fit. I just didn’t know what else to call myself. I also didn’t feel comfortable abandoning the principles of servant leadership which were a real guiding principle of why I got into management. 

The more I reflected on it after that conversation, the more I realized that servant leadership is incomplete as a default operating model for engineering managers. Servant leadership describes intent. Situational leadership describes execution under constraint.

The shift wasn’t about abandoning the values that brought me into management. It was about learning when those values needed structure, direction, and sometimes decisiveness to actually serve the team.

The goal never changed. The way I had to lead did.