Software development requires servant leaders

You have to be careful being a servant leader. It's often a thankless job. And most of the time other people will be taking credit for your work. It's not noble to suffer like that -- it can be damaging to your health.

It's an effective position however and comes with it's own rewards. I personally relish seeing my team grow and the people I help mentor flourish.

I recommend getting a good therapist and taking small, frequent vacations. The trade off to being a servant leader is basically an environment that will wear you down. If you have conditions they will be amplified. If you don't take care of yourself you will develop conditions.

This is an interesting article, but I do not agree with a number of its points. On the main one: servant leaders are not required; they work on some teams, and this is great. But other teams need a strong leader who knows what he wants and directs the execution. And team members are often OK with it when probed -- "he is an asshole, but sharp and gets things done. We rarely work long hours and are respected by senior management for delivering. I am not changing teams".

Many topics follow a theme: leave us developers alone, we are working. Do not negotiate with our estimates, etc.. This may not work in the real world. When a project involves several teams (one builds hardware, second UI, third computation, fourth preps algorithms and tools for analysis, etc.), there are common test events and mid-course corrections. Blowing past schedule affects others -- canceling a test event for a geographically distributed team is expensive.

In such cases when the developer says that they need an extra 2 months do X, "what can you do in 2 weeks" is a reasonable counter question. It may be an unreliable junk and those 2 weeks of work will have to be tossed and redone, but this may still be the best option in the grand scheme of things. Here developers often dig in and start throwing articles and links on technical debt; making them finally write a quick, limited capability prototype is a MAJOR effort. My 2c.

In my experience it is rarely enough to just "lead" more thoughtfully, which seems to be what the author here is promoting. Software development does not just require servant leaders in the helping sense, but in the working sense. The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. They have the power to move the project forward on their own, and working with them lightens the effort for everyone. Those who also adopt the ideas in this essay do foster the sensation among those they lead that they were never led at all, and rather achieved their common objectives together.

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never had to invent different kind of leadership and procedures or change office floor plans or hire outsider non-engineers as our (scrum) masters, or talk about the client as stake holders etc.

Sorry about hurting your agile feelings!

I can't stand the phrase "servant leader". You can have a "good leader" without any other adjectives. The word "servant" is a loaded word in a way.

And, has anyone heard of a "servant" that works just under the "servant leader"? Kind of a meta-slight against any group to be blessed with a "servant leader" instead of just a good one.

Edit: Consider flipping the phrase, "Leader Servant". Now hopefully the silliness and almost meaningless title this really is.

Also, I've heard this used by leadership to justify their abusive behavior as well, so titles mean nothing, actions mean everything.

> The idea of “servant” leaders has been on the rise in the agile community of late. Robert K. Greenleaf coined the term in a 1970 essay, but the idea is timeless.

At least in German, that term is arguably much older, going back to the Prussian king Frederick II, who wrote "the sovereign is only the first servant" ("The sovereign, far from being the absolute Master of the people which are under his domination, is only the first servant").

Maybe. I think there’s all sorts of leaders and all sorts of ways and configurations projects can have.

IMO the most inspired software is the implementation of the vision of one person who had an artists/visionaries clear idea of what they want to create, who listens to input and brings in new ideas from others, but has absolute control over the decisions.

Servant leaders of software projects I’m guessing has the potential to lead to somewhat ordinary software.

I think the difference in software engineering is that the cost and time of digging a tunnel is almost zero. When you write code that "digs a tunnel", writing the design and code are the hard part, distributing the compiled code is usually predictable and simple. So I think software engineering is closer to the planning phase in civil engineering, where you need to go research the mountain, plan multiple routes, deal with regulation, etc. I bet it is also hard to estimate in civil engineering how long it's going to take to complete the plan to build a tunnel.

I experience "servant leaders" crash and burn. It's often done so poorly. They never make decisions, they just keep making vague requests for the team to come to a consensus and it's chaos. Also, another con of servant leaders is that they often don't hold people accountable. Bad behavior on the team starts to spread and moral tanks. Yes, the concepts of a servant leader sound nice, but it's often implemented horribly. Sometimes the leader needs to be aggressive, make unilateral decisions, and hold people accountable.

Man, the first part of the article hits close to home. Ik currently in a project where there's a combination of scope creep and inexperienced developers causing the work to take longer than expected. Business however is unwilling to move any deadlines.

> When the business side “wins”, the developers end up in a death march.

This is a pretty good way to describe what I feel like now.