A lot has been written on servant leadership, but I have a question on it. I first read about this concept in Team Geek, where it says:

“[Servant leadership] is a nice way of saying the most important thing a manager can do is to serve her team, much like a butler or majordomo tends to the health and well-being of a household. […] This may mean removing bureaucratic obstacles that an engineer can’t remove by herself, helping a team achieve consensus, or even buying dinner for the team when they’re working late at the office. The servant leader fills in the cracks to smooth the way for her team as well as advise them when necessary, […]”

I like this notion of the manager role very much, because I think it matches reality in our field quite well. We are in the software business, so we deal with smart people. If you hire well, these smart people will also be self-motivated and self-directed, so there will be no need to closely monitor and micromanage them. In fact, these practices can be devastating to motivation as well as innovation.

Instead, you a) get out of their way, and b) try your best so that nothing else (bureaucracy, process) gets in their way, either. Rands puts it this way: They do not work for you, you work for them. And Joel Spolsky’s version is not far away from that: “Management is a support function.” You, the manager, support your people so that they can concentrate on their work and are more productive and satisfied with their environment.

Beginning and end

However, a question that I have been thinking about a couple of times is: If servant leadership starts with removing obstacles and creating a productive environment for your people, then where does it end? Does it end at all, i.e., are there things that you should let somebody else do instead of doing everything yourself? For example, apart from the things already mentioned, here are some things that I do for my people:

• Order books
• Organize workshops and training
• Document culture
• Encourage them to give internal talks, and set up the appointments for them
• Maintain the shared notes from our one-on-ones, and keep them up to date
• Remind them to sign up for a conference so that they do not miss it
• Give trainings like departmental onboarding sessions
• Run a guild
• Finish a blog post for them that existed only as a draft, because they have no time

Basically, I do a lot of things that can be described as “somebody should” tasks. “Somebody should document this.” or “This Slack post is so well written, somebody should actually turn it into a blog post.” And while I like doing this, sometimes I wonder how you best balance servant leadership with two other concepts:

A good manager replaces herself

Ideally, managers should train their own replacements, so that they can go on vacation, leave the company, or otherwise become unavailable without affecting the performance of their organization too much.

At first glance, this runs counter to some of the things listed above, because, if you, as a manager, do all those things yourself all the time, then you are certainly not training your replacement. Rather, you are making yourself indispensable.

Wait, indispensable, really? On taking a closer look, maybe it depends on the specific activity. There are some tasks that are definitely no rocket science, so somebody else could pick them up without any training. Ordering books and organizing workshops are mostly routine work (although there are some tricks to organizing a workshop), and anybody who knows how to use the Web, write emails, and book a meeting room could do it. So you do not really need to train a replacement for that.

In order to remove obstacles and help with bureaucracy, you mainly need to know the organization and its people, and be in a position of a certain authority. You cannot teach people to be in a position of authority, but you can teach them how certain things work in the organization, or take them along from time to time when you set out for a diplomatic/political conversation. So, while it is usually you who takes care of the bureaucracy, it might still be a good idea to take a future “replacement” along every odd time, to show them how you get things done in this environment.

What about running a guild? Should the servant leader do it all himself? After all, there are rooms to book, emails to write, agendas to prepare, and working groups that need to be coordinated. All these activities take time, and will keep others from doing development work if you hand them off. If your job as a manager is to create the most productive - i.e., distraction-free - working environment for your people, then the answer should be: Yes, this is the manager’s task.

However, let us assume we are talking about a Python guild, and the manager is not very passionate about Python? Should he still run the guild? Maybe there is an employee who would like to step up and take the coordination in her hands? After all, in a guild with good participation, you can get a lot of things moving. If the manager thinks the employee has the talent for running the guild, I think he should gradually hand its organization over. Even if Henry Ward is, in principle, right to tell us to delegate the work we want to do, I think this advice does not hold when somebody else is happy and willing to take the job.

Moreover, I think that there can also be growth opportunities in handing something over. It might be the right thing to “shield” more junior employees from unwelcome outer influences, so that they can focus on their work. However, developers who have been with you for a while might be looking for new responsibilities, and are ready to learn about new aspects of their job, even if they are not all that pleasant. This is where Andy Grove’s Task Relevant Maturity (TRM) comes into play: There is no one style of management that is appropriate under all conditions. Rather, you should work hard to know your people well, and therefore be able to judge who to ask when it comes to delegating work.

Delegation as a high-leverage managerial tool

Speaking of delegation: Another argument against taking servant leadership to the extreme and doing everything yourself is the low managerial leverage that goes with it. In theory, delegation is a great management tool to increase that leverage.

For example, if you want to document your development culture in an employee handbook, this might be worth delegating. It is focused, one-time work, and somebody who cares about this topic might enjoy writing about it. If you find that someone, you can take care of other things in the meantime, until you discuss the result together.

However, recurring, small, non-creative tasks that bring with them a lot of interruptions can cause a loss of focus and productivity for your developers. Take the organization of a workshop, for example. Several times, you have to check if people signed up or if they confirmed the invite. You will get emails with questions about the schedule, questions if they can switch their time slot with somebody else, questions if they need special software to install up front, and a million other things. Being the target of all these requests can kill the productivity of any developer - think maker’s schedule vs. manager’s schedule.

So, by delegating, you might actually decrease the output of your organization, because you sacrifice your employee’s focus to free up some of your own time.

Weighing up

In the end, it comes down to a couple of questions that need to be weighed against each other. On the one hand, you have the potential benefits of handing things over to somebody else instead of doing them yourself:

• Increase in your output (positive managerial leverage, because you free up time for yourself)
• The task is done in a better way (e.g., because your employee has more knowledge/skills/passion).
• Employee growth

Against these potential benefits, we have to weigh the potential drawbacks:

• Decrease in output of somebody else (because of lost focus and productivity)
• The task is done in an inferior way (because of missing skills/knowledge/passion).
• Decrease in motivation because the employee can see they have been assigned a task nobody else wants

Let’s put this set of questions to a test. Say you are teaching the same class over and over again, whenever there are newcomers to your department. You know that some people on your team have the talent to teach, but have little opportunity to develop that talent. Should you stop doing all this teaching work yourself and hand it over to somebody else (maybe only partially)? How would you answer the six questions above?

• Would it increase your output, i.e., increase your managerial leverage? Yes, it would, because it would free up some of your time in the long run. Short-term, you might have to put some more time in, because you might have to prepare and train your employee for teaching. Moreover, you should attend at least the first one or two sessions in order to give feedback.
• Would your employee teach in a better way? This cannot be answered generally, but I have made the experience that rotating teachers can bring new perspectives and fresh ideas, so I tend towards “yes”.
• Would it help your employee’s growth? I would say “yes”, because teaching is a great way to learn.

What about the potential drawbacks?

• Would it decrease your employee’s output? Yes, to a degree. Of course, the time your employee uses to prepare and teach the class, she cannot use for software development or other IC (individual contributor) work. However, we are probably talking about very few contiguous blocks of time she would need, rather than a constant series of small, focus-killing interruptions. So I would say the decrease is made up for by the benefits.
• Would your employee teach in a worse way? Already answered above. Select well, and the answer will be “no”.
• Will your employee’s motivation suffer because you assign her the task? Again, it depends on how well you select. Of course, you should ask her up front if she wants to help you with teaching. But even if she says “yes”, you cannot be sure, because, you know, you’re her boss and so on, so she does not want to disappoint you. Therefore, observe how she performs the teaching. Is she enthusiastic or bored? If she seems bored, you might want to reconsider your choice.

Summing up: I think teaching is fair to be shared with employees. It provides an opportunity for growth, and comes with few interruptions. As Andy Grove puts it in High Output Management:

“Conducting training is a worthwhile activity for everyone from the first-line supervisor to the chief executive officer.”

Let us test our questions with a second example: Should I, as a servant leader, hand over the task of organizing a workshop?

• Would it increase my output, i.e., increase my managerial leverage? It would free up some of my time, yes.
• Would my employee organize the workshop in a better way? Maybe, but probably not significantly. It’s not rocket science.
• Would it help my employee’s growth? Probably not, because the job is not that challenging.

What about the drawbacks?

• Would it decrease my employee’s output? Yes, because she would be faced with many requests and questions that might interrupt her flow. As a developer, she will be more affected by these requests than I as a manager.
• Would my employee organize the workshop in a worse way? Maybe, but probably not significantly.
• Will my employee’s motivation suffer because I assign her the task? It might, actually. Unless she really screamed for the task, she might be annoyed by the interruptions that come with it, and the damage that is done to her focus and productivity.

Summing up: Organizing a workshop is something that you should rather do yourself. You might negatively impact somebody’s productivity and output otherwise, without any personal growth attached. If you have an assistant, he can do it. But don’t hand it to a developer if you can avoid it.

Conclusion

I think I will use the above set of questions next time I am confused about the boundaries of servant leadership. While shielding your team from bureaucracy and distractions is definitely the way to go, some non-core activities might be interesting to some (not necessarily all) developers, and provide opportunities for personal growth. Sharing the load of these activities with your employees is not “delegating shit work”, but actually a win-win arrangement you should take advantage of.

Time investment

Writing this blog post and finding the pictures took me about 5h of work. It is an example of finding the answers to my own questions while writing about them.