Servant Leadership is a topic that I’ve seen frequently discussed and just as infrequently defined in the context of Software Engineering Management. I’ve seen practitioners of the craft lead extremely effective teams, but nearly as often, I’ve seen self-proclaimed servant leaders use that mantle as a justification for neglecting their team and abdicating responsibility for the lack of support they provide. I’d like to offer a definition for a few things that I think effective Servant Leadership is, and a few traps that I’ve seen catch well intentioned managers hoping to become Servant Leaders themselves.
At a core level, servant leadership is rooted in a desire for the success of your team. It implies that, as a servant, you don’t consider yourself above your team in any way. As a manager, you occupy a different, but no more critical role than the people who are actually doing the work. It also tends to imply a focus on the success of the individuals on the team, in addition to the team as a whole. These are all great principles.
Where I’ve seen trouble creep in is when a leader mistakes service for a lack of agency – if you think that being of service to your team is to do what you are told, only once you have been told it, you are probably not serving your team well. Yes, your job is to serve the needs of your team, but those needs don’t always jump out at you wearing bright colors, yelling “I am the problem that needs to be solved!” By the time they do, literally or figuratively, something has gone very far off the rails.
There is a reasonable analogy to be made with product design. A key part of designing or specifying a new feature is talking to customers, but the process does not stop there. From time to time your custom will tell you exactly what they need, and it is exactly the right thing for your product, but this is the exception, not the rule. Very often, when you hear a customer ask for a very specific feature, you should hear it as a problem statement, and then consider how to solve that problem – you might come to the same conclusion as the customer making the request, but maybe there is another way that gives the same gain with lower cost, or that works with the broader system more elegantly.
The same holds true as a manager – you will get specific requests from your team to fix a problem: “We spend too much time in meetings”, “I need a faster laptop”, “I want to switch teams”, “we should spend less time working on bugs”. Each of these is a problem that needs to be solved, but odds are none of them will be fully solved by just taking the requested action. To just pick a single example: we don’t hate meetings just for their very existence, we hate them because the content is irrelevant. Is the problem that you have too many meetings, or is your team spread so thin that no person cares about what any other person is working on? Are you okay with that?
I’ve seen two places in particular where I’ve seen self-styled servant leaders struggle with the expectations of an engineering management. Owning decisions and providing feedback both provide a similar discomfort: how can I be a servant to my team while also telling them what to do and passing judgement on the work they have completed? For me, at least, the key to resolving this discomfort is to focus on two things: this work is key for the best functioning of my team, and as a manager, I am sometimes in the best position to provide that service to my team.
I once learned of a manager who uninstalled their IDE, and made a policy of never looking at the code that was checked into source control. The reasoning, as I understood it, was to remove their temptation to interfere in decisions made by their team. The problem with this is that one of they key roles that you can play as a manager is to be the connection between your team and the rest of the organization. It is impossible to be this connection without a profound technical understanding of what your team is doing. The alternative could have been worse, their instinct for meddling might have been so problematic that ignorance was the lesser harm, but in either case their team was not being well served by their manager’s lack of involvement.
As a manager, you often have the broadest context for the decisions that the team needs to make. You know what everyone is working on, you have insight into the skills and desires of the members of your team, you have a deep knowledge about the needs of the company, you have the bandwidth to collect and analyze data about your teams execution and you have an awareness of the work that is happening outside of your team. You might not have as deep of an understanding of business requirements as your Product counterpart, or as deep of an understanding of your architecture as your Tech Lead, but you probably do have the best ability to bridge the gap, just by nature of the conversations you are a part of. If you fail to bring this knowledge and context to bear, you will be providing a disservice to your team.
Making and owning decisions is also a way to maintain the efficiency of your team. There are times in which an imperfect decision made quickly will allow the team more success than the dreaded paralysis by analysis. Breaking the impasse, however imperfectly, is a service that a managers are in a hierarchical position to provide. This is a dangerous tool to wield, and should be done so with care, but to take the option off of the table in the name of serving your team would rob you of an important mechanism of service.
Monitoring, evaluating, and providing feedback to the members of your team is also incredibly important. Feedback, even challenging or critical feedback, can be a huge asset to your team, as it lets folks know where to focus their efforts on improvement. You do not need to be the only source of that feedback, but you are responsible for making sure it arrives. You are likely the third party with the broadest perspective, and the most investment in the success of the members of your team, so even if nobody is asking for it, providing that feedback is a service to the team.
All of this is to say that servant leadership is not the oxymoron that it might appear at first glance. Leadership is not in conflict with serving your team, leadership is a service you provide to your team.
It’s also worth noting that servant leadership, or leadership of any flavor is not purely the domain of management. Managers are well-positioned to provide some types of leadership and direction, and if leadership does not come from elsewhere, there is an imperative for managers to fill that gap, but leadership can come from any level and any job function and this leadership can be provided in service of the team.
Leave a Reply