
Software development requires servant leaders - mooreds
https://adl.io/essays/why-software-development-requires-servant-leaders/
======
agentultra
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.

~~~
allochthon
I think part of the challenge is fostering a culture in which people are
discouraged from taking credit for other people's work; e.g., doing so is seen
by most as being tacky and tasteless. That is a different culture from one
that prevails in many American companies, where the rewards go the other way.
But I think it's one worth striving for.

~~~
hinkley
Teamwork. The word you’re hunting for is teamwork.

Fred Brooks was wrong. We shouldn’t be like surgical teams. A couple of highly
trained egotists taking credit for everybody who spends all day cleaning up
after their messes.

Software is a team sport. Might be worth looking there for inspiration. Except
for the PEDs. Maybe we can skip those. Caffeine is the only one I’ll do.

------
ptero
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.

~~~
humanrebar
> ...making them finally write a quick, limited capability prototype is a
> MAJOR effort.

Fair, but why is that. I've been talked into just-for-now solutions over and
over in my career. Rarely does the org actually go back and clean it up in a
timely fashion.

It's possible, regardless of servantness, that leaders don't have a good
reputation for following through and finishing things.

~~~
hobs
Rarely? Try never. Then its now your job to support the mess from now on. You
can call me a recalcitrant developer if you want, but its like asking "Oh,
well what bridge can you build in two weeks?"

Sometimes you should build a raft instead of trying to pretend you can build
major infrastructure in no time flat.

~~~
andyidsinga
The raft metaphor is a good one.

I've often used a similar one: "first we build a go-kart. It's a cool little
go-kart, and will help us overcome certain barriers to adoption with a certain
kind of customer for whom a go-kart meets their needs."

I find that the main arguments against the raft/go-kart strategy (from the the
business leader) are along the lines of "we need a Ferrari man! not a go-kart;
_our target customers_ won't even consider a go-kart".

Its at this point that an very important discussion has to be had about how
customer development and barriers to adoption are overcome. BTW - the applies
to both new product development and features for existing products.

This is not easy. This discussion must include "Look, the experts who are
building this are telling you ________ and ________; you can choose to accept
that or continue down a path of uncertainty and investigation until they come
up with another set of recommendations...". The goal for the technical leader
is to setup a set of options for the business leaders to choose - none of
which are allowed to be chaos.

If chaos is the norm, either the business leader or technical leader will be
removed - or the business will likely fail due to that chaos and its effects
on the team.

~~~
s73v3r_
I don't know if this is a good time in history to be referring to "experts".

~~~
andyidsinga
Hmmm. I understand why you say that - alas, yes in the political environment
experts are cast negatively.

In the above context, I'm talking about the people we hire to do the things
that need to get done to move a business forward - we hire them for their
expertise and skills.

When I'm talking about the people I've hired - to management, peers in other
groups etc - I refer to them as "the experts who are building the ________,
tasked with accomplishing ________" and so on. It reminds people that they're
here for a reason - to contibute ..and not here by random coincidence.

------
eggie
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.

~~~
monkeydreams
> The best leaders in software and technical domains are also those who can
> write (either code or ideas) better than anyone else.

Technical and programming skills have very little overlap with successful team
management skills. It's the very essence of the Peter Principle.

~~~
codingdave
I would say they have little inherent overlap, but they are not mutually
exclusive. A leader can cultivate both skill sets. I think the problem arises
because as we advance in technical skills, it is an incremental advancement
over years. However, switching to a leadership role brings on a large,
deliberate, fast learning curve to pick up brand new skill sets. Many new
leaders just keep learning incrementally, taking far too long to get good at
their new role. But the ones who do make a fast jump, and actively pursue
their missing skills, tend to be great people to work with.

------
phakding
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!

~~~
repolfx
Because structural engineers work primarily with other structural engineers,
or maybe (real) architects at best. You were insulated from the ultimate
'customer' by at least one layer of profession, maybe more. You were also
doing work that was safety critical which meant you had the final call and
final veto, always, because you could say "that won't be safe" which is a
debate-ending move.

Software engineers get to do "engineering" where they don't control their own
deadlines, can be forced to launch at arbitrary unplanned times, where the
customer can't explain what they want and what they want is always changing
anyway, and they are effectively disempowered to fix any of this because they
posess no debate-ending move like other forms of engineering do. And many
other fundamental problems that make it a different kettle of fish altogether.

~~~
phakding
Structural engineers do not work primarily with other SEs. They have to
collaborate with architects. Architects tend to take lot of artistic freedoms
when designing a structure. We get to tell them to shove it as implementing
some of their artistic designs would involve defying gravity and other laws of
physics. Although that doesn't work and then you get failed/delayed/extremely
over budget project

SEs also work with civil engineers/site supervisors etc.

No there's no veto resides in hands of engineers in any industry. There's a
reason why bridges collapse and buildings need to be tore down for safety.
It's not because engineers got to decide what's right.

~~~
repolfx
Can you show me cases where a bridge collapsed because the engineers on the
project said "this will be totally unsafe" and were overruled by non-technical
business managers?

~~~
phakding
[https://www.usatoday.com/story/news/2018/03/16/miami-
bridge-...](https://www.usatoday.com/story/news/2018/03/16/miami-bridge-
collapse-suspension-cables-support-tower/431418002/)

[http://www.ejinsight.com/20180406-hk-engineers-raise-
concern...](http://www.ejinsight.com/20180406-hk-engineers-raise-concerns-
over-safety-of-mega-bridge/)

There are many more, but the fact that engineer's safety concerns were side
stepped rarely sees light of the day after disaster strikes. Also it doesn't
have to be a catastrophic failure. Sometimes the reduction of life span of a
structure is cause of not taking care of all the concerns.

Also this does not stops with construction. Have you not heard about problems
in cars or other engineering projects where safety concerns were ignored. If
not, I have to ask you how old you are.

~~~
repolfx
The first story doesn't seem to support your point. It's talking about
engineers saying a bridge was unsafe _after_ it collapsed. Whilst a FIGG
engineer seems to have reported that the bridge was collapsing two days before
it did, what I'm talking about is where a senior engineer i.e. chief engineer
on a project says "this design is not safe" and is then told to build it
anyway, or where a bridge isn't finished on the day that was expected and then
traffic is put on it anyway whilst the builders are still working. People
realising they screwed up after disaster strikes is normal but unrelated to
project management discipline.

The second link has the same issue - the engineers cited as saying something
is unsafe are saying that _after_ problems are spotted and they are _not_ the
same people who built the bridge. Sure, anyone can say "that was clearly
unsafe" after the fact.

To repeat, what I asked for is cases where the engineering management of a
project said "this is not safe" _at the time they were being told to build it_
and non-technical management then overruled them and put traffic on it anyway,
that is, the engineers were not allowed to complete the job to their own level
of safety satisfaction.

------
RobertRoberts
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.

~~~
Floegipoky
I disagree that the phrase is meaningless. This leadership philosophy is very
different from traditional Western ideals of leadership, though tbh I don't
think the article did a very good job describing it. I first learned about it
from the best leader I've ever worked for, David Cancel (CPO at the time). I
absolutely considered myself blessed to have the good fortune to work for
someone whose primary focus was making my work easier, rather than wringing
every last drop of efficiency out of me. Perhaps it's a difference that one
needs to experience to appreciate.

~~~
RobertRoberts
> _This leadership philosophy is very different from traditional Western
> ideals of leadership..._

The crux of the issue. You can't label a western leader with an eastern
ideology and thus "make it so", that's called lying.

Actions speak louder than words, and labels aren't needed to prove reality.

------
elcapitan
> 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").

~~~
chrisper
Pretty sure that the word servant had its origins from Latin (servus).

~~~
elcapitan
Obviously I meant the idea of a leader _as a servant_ , not the word.

~~~
chrisper
Wasn't so obvious to me. Sorry, I misread it.

------
jbell0385
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.

~~~
hopsoft
You’ve setup a false dichotomy. Servant leadership can & should be decisive.

~~~
jbell0385
Sure maybe there's a "right way" to be a servant leader. I'm telling you how
it's often executed in practice...which is poorly.

~~~
yarper
I think that's describing no leadership rather than a variety of it, but yeah
most leaders suck, especially in software

------
hguhghuff
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.

~~~
ordinaryperson
There's no one-size-fits-all management style. Evil megalomaniacs can also
have success.

It's good to have humility, but that's true for individual contributors, not
just leaders.

As you point out, if a leader is too humble, at especially at Big Corp Inc,
products can end up designed by committee, an ugly Mr. Potato Head that
everyone hates.

It'd be nice if success required 1-3 specific personality traits but they
can't be correlated exactly. But this kind of "If you do/have X, you will
succeed" articles will probably always be popular.

~~~
lazyjones
> There's no one-size-fits-all management style.

I guess someone has to tell the Agile people, who are obsessed with rules and
formalisms, about this.

Leaders need experience to cope with different situations. If a team wants a
good leader, it should choose him/her based on his/her successful projects
instead of relying on FotM Agile concepts and the candidate‘s willingness to
adopt them.

~~~
ordinaryperson
Obsessing over any rule pattern, whether it's Agile, Lean, Waterfall, etc.,
is, of course, stupid.

Those patterns are designed to help groups work together more efficiently, not
lord over them like the gods of Olympus.

Assuming you've already explained your frustration to your manager, might be
time to seek a new opportunity...

------
javierluraschi
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.

------
donkeyd
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.

~~~
undreren
The term for this is "developer abuse".

------
jonstokes
This is the sort of article that makes me imagine a dialogue between a senior
software engineer and a newb developer that goes something like this:

Newb: Hey man, I think for this project I'll write my own SQL datastore from
scratch. I've looked at a bunch of them and my project, which is basically an
inventory management system, is such a special snowflake that it needs its own
datastore.

Senior: That would be insane. Never do that. Use what's already out there, and
is tried and tested. In fact, just use postgres and make it work.

Newb: Aw, ok. I was so much more excited about writing a new SQL datastore
than I was about the actual project it's for, but sure, I'll just use
postgres. _starts to walk away..._

Senior: Hold up a sec before you go, I want to run something by you. Because
our discipline, which is basically a team of people who are hired to build
things on a schedule, is such a special snowflake, I've invented this totally
new way of thinking about work, and of organizing a team and leading it, and
there's a bunch of new terminology and I have some cool diagrams... I'm
lobbying that we all switch to this at the end of the month.

~~~
groby_b
You just might not have experienced decent leadership.

Servant leadership doesn't mean you do what your reports want. It means you
enable your reports to make good decisions, instead of deciding for them. It
doesn't mean you don't teach, or you don't share experiences.

Let me quote from the original: "The best test, and difficult to administer,
is: Do those served grow as persons? Do they, while being served, become
healthier, wiser, freer, more autonomous, more likely themselves to become
servants?“

Do you think the senior can answer "yes" to this if they just acquiesce to
everything?

~~~
mooreds
I think GPs point was that building cohesive teams is a known art and yet
software folks keep trying to reinvent the wheel.

~~~
marcus_holmes
I did an MBA, and have built and led software dev teams for decades. Just to
establish my bona fides, because the "known art" of building cohesive teams
and what actually works for software teams is definitely two different things.

Actually, having talked to friends in other creative industries, I don't think
anyone gets this right for creative processes. And I think TFA gets it
completely right when it talks about estimation as the root of the problem.

We know there is no method of correctly estimating software development
timescales before the development begins. This is also true of other creative
processes, but usually they have the ability to ship a half-complete product.
Think of writers meeting a deadline with something they know isn't "right" but
doesn't actually burn the reader's eyeballs out of their skull. Or graphic
artists who have to send something off that they know isn't great, etc.

Software actually is unique in this respect, because it doesn't work if it's
not complete. There are bugs that need to be fixed, features that actually
need to be complete, etc. While a graphic artist will usually get a couple of
requests for changes, there are usually contractual limits around this. No
such luck in software (imagine saying to your customer "you can report two
bugs or incomplete features for free, then we start charging you again").

So the basic problem (as TFA says) is that estimates are never accurate, and
yet businesses need accurate estimates to make decisions. A good software team
leader/project manager/CTO/IT Director/Tech Wiz bridges this gap and manages
both sides so that the business can function.

To do that requires empathic understanding of the needs of both sides.
Authoritarian leadership, either from development refusing to heed deadlines,
or management insisting on them, will (as TFA says) break the business.
Servant leadership allows both sides to make the necessary concessions to keep
the business afloat.

Awesome that someone has written this up so well :)

~~~
angersock
To be fair, we can all totally ship incomplete and buggy software to good
effect. Imagine a shipping system where users have to submit orders and then
manually update the address zip code--sure it is buggy but the end user still
gets value.

People are too concerned with perfect software.

~~~
Bartweiss
This is true, but it doesn't mean software can be delivered at any point in
the development process.

Something like a novel is (hopefully) shipment-ready at most points from the
first draft on. A full rewrite might happen at some point, but much of the
development process happens after the first draft and can be interrupted with
minimal cleanup. If you've only copy-edited half of chapter one, you can still
finalize those changes and ship without trouble. And, you're unlikely to get
95% of the way through writing and discover an issue in Chapter 10 that
invalidates chapters 2-6. (This does _happen_ , especially with mystery
novels, but it's not the standards outcome. It's much more likely to just hit
a problem that makes you _want_ to rewrite, rather than actually breaking the
piece.)

A lot of software has a high percentage of work happen ahead of the MVP, and
even if progress past the MVP is done while maintaining a working state, the
individual tasks don't tend to be interrupt-able. If that shipping system is
instructed to handle bulk-loading of 50,000 orders, fixing the manual zip code
issue is probably still an all-or-nothing task. And, of course, there's a high
chance of invalidating past work. If a contract comes in that requires multi-
user ownership of orders, that might break invariants across the entire
database while still looking to the buyer like "just adding another user to my
order".

Pretty much any field has some minimum unit of work to move between acceptable
states. You might print a novel mid-editing, but not while a sentence is half
reworked. You can launch a new car model with fewer units finished than you'd
like, but not (easily) with contracts for dealers that will be unfulfilled,
and certainly not if you find a problem with the airbags.

Software development frequently gets planned like creative or social work
which generally has small minimum increments and few catastrophic surprises,
but ends up playing out more like construction or physical manufacturing where
unexpected failures are likely and shippable states are noticeably far apart.
Hence death marches, outright broken releases, and a lot of the other issues
the field is infamous for.

------
patrickg_zill
Was Steve Jobs a servant leader during the development of the original
Macintosh?

~~~
ken
In some senses, yes. For example, the original developers got to sign their
work -- a way to say "We ourselves have achieved it!"

No software project I've ever worked on let me put my name on it.

------
vinceguidry
Everything needs servant leadership. The whole idea of servant leadership is
so unbelievably powerful that it spawned a religion that managed to convince
the European world that there's a magical servant leader that was sent down to
teach and serve us, and regular non-magical non-servant leaders killed him
because magical leadership threatened them. People believed it, and still do
to this day, because that's just the way people want to live.

A new doctrine isn't helpful. There's no new gospel to spread, the old gospel
was good enough. The reason you don't see servant leadership everywhere in
business is because people have different priorities and it's really hard to
get them to line up. When priorities don't line up you need a class of people
whose job it is to manage the disconnect and ensure that the people paying the
salaries are getting what they're want, because the mismatch in priorities
means they can't trust the ICs.

Servant leadership, being led by someone who has both your interests in mind,
and who also thinks like you, would flatten the hierarchy so less of that ugly
management business is needed. But the real answer to this dilemma, the other
side of the coin of the rise of Christianity, is that you have to adapt to
your masters. Christianity only became successful because they managed to
become Roman, to embody Roman ideals and engage with Roman people. Only in
this way could the cult of Jesus have spread so far that 400 years after its
inception, it became the official creed of the Roman Empire.

A fact you miss in Sunday School.

------
sheepmullet
Many other types of leadership can work just as well depending on the team.

The biggest downside to servant leaders is, IME, they split their focus and
are often not held accountable.

For example if you prioritize growth as a servant leader are you held
responsible if your team has a higher than average turnover? Are you rewarded
if you have a lower than average turnover?

Is that more important than project success to the business?

Is this clearly defined anywhere for your project?

~~~
20160216
At this point in my career think the problem is always that somewhere in the
chain of command is someone who sets arbitrary deadlines and then keeps
changing the spec.

As an engineer I hated this- we would just get more and more work piled on us,
arbitrary and counter productive of dienright stupid changes. Product managers
who didn’t understand the user and would just throw random ideas in there
without vetting.

When I got up to being CTO, I discovered my CEO didn’t give a flip about any
kind of reality, just demanded more, kept making changes and wasn’t interested
in hearing about how work related to schedule. He literally didn’t care that
he made it impossible to deliver the product, and just blamed development (and
eventually me.). My deal was structured such that I was ok being the fall guy
but the abuse those engineers suffered was pointless.

This is not the only time I’ve seen this. In 20+ years I’ve seen it at
companies like Microsoft and Amazon (from Bezos directly- the most incompetent
CEO ever.) I’ve seen it at many startups too.

It seems non-technical “leaders” don’t give a shit about the fact software
takes time. They think it should be trivial to change anything anytime.

Basically I’ve stopped working for other people because of this.

It’s not that software is hard to manage- it’s that MBA types have sero
respect for the engineering department and just want to abuse engineers.

If you have a good situation it’s because somebody between you and the MBA
asshole is protecting you. Or your CEO is an engineer.

My rule is, no more working for CEOs who aren’t real engineers (had done lie
about that too. No your HTML page in high school without do much as a lick of
JavaScript does not make you “technical.”)

------
vfc1
Much more important than being a servant leader, the leader needs to also be a
developer himself.

Its the only way that the leader is going to understand the needs of
developers in the first place.

Non technical middle managers make awful software development leaders, yet
that is very common scenario in a wide range of companies.

The problem is that executives on top are just not comfortable dealing with
developers directly.

------
normalocity
All work actually requires servant leadership to be maximally effective. This
article does a great job of explaining it in the software domain. My wife
works as a school principal and though the specific jargon would be different,
the lessons are the same, because other than specific idiosyncracies that
engineers have, we're all motivated and burned out by the same fundamental
things. That's the good news - people are people.

The bad news is that if you get burned out by software, changing careers isn't
going to fix anything. As I get older I care less about the specific problems
to be solved by the team, and I care a hell of a lot more about the group of
people I solve them with

Thanks for posting this.

------
djanogo
What the quoted paragraph doesn't show is the hiring process, "servant
leaders" will only work if you hired the right candidates and provided initial
guidance on expectations. Right candidates for the job at hand is _the_
hardest part.

My current workplace hired junior level developers who came through with very
limited coding skill and but talked their way into permanent positions. They
quickly hired consultants to "help" them with projects, and settled to become
requirement gatherers and use the consultants to code all their stuff.

My point is, if you were to walk in as new manager in your group, kicking butt
and firing people, and NOT be a servant leader, might work better.

------
mborch
It's not just software that doesn't "square the very definition of a project
... with our real world experiences". The same happens on the business side.
There's always the other side of the equation: how the system reacts to what
you're trying to do.

Perhaps some component doesn't really gel the way you had hoped for. The same
goes for business opportunities. Sometimes it just doesn't work out and it can
be a real blow to the project. And sometimes the users just aren't there or
don't appreciate what you've done.

Management generally has to be flexible, not just in software, but in a lot of
divisions. Because ... unknowns ... that are discovered as you go.

------
asdfman123
> It’s not because we’re narcissists who need special labels.

Whoa, let's not get carried away here.

~~~
stcredzero
Is there a word for the specific form of narcissism that thrives on getting
ahead by pulling others down?

------
nautilus12
This captures my philosophy on software leadership better than i could have
explicated myself. I was hooked when he started to talk about when we come up
with different names for a project because we are never satisfied with it

------
koliber
There is a difference between a leader and a manager.

We never want servant leaders. We want leaders that embody an idea, have a
vision, provide inspiration, and instill purpose.

We absolutely want servant managers. These are the people who allow those
working for them to just do their job.

The lower on the org chart a person is, the more of a servant manager they
should be and the less of a leader they need to be.

In smaller organizations, you can be both low and high on an org chart, as the
org chart is flat. In such cases its good to embody both the leader and the
servant manager.

------
danielovichdk
I have been working professionally with software for almost 20 years.

And what I defintly can say is that great leaders do exist.

But it takes a certain level of integrity and intellect, IN the company
culture.

It's bullshit that we're better, more bright and what not compared to other
fields. We're absolutely not. We're comfortable being pushed around and then
bitching about it, maybe because we have no integrity and are scared

------
dropit_sphere
"Servant leadership" is just another word for leadership.

Good leadership _is_ a service. It's certainly rare enough.

But what people tend to mean with the phrase is the opposite: that good
leadership _consists of_ and is _defined as_ service. That's just service with
a "leadership" nametag, and is insufficient when actual _leadership_ is
required.

------
s73v3r_
There seems to be this odd sentiment in the comments here that, unless you're
an absolute tyrant, then you must be a weak leader, not directing people and
not holding teams accountable. This concerns me greatly, because thinking that
"strong leaders" have to be tyrants is a big part of what lead to the Maryland
football tragedy.

------
andyidsinga
From this article, IMHO these are the most important for [technical] leaders,
in priority order.

All other things : trust etc - effectively fall out of these, because these
are the things that will enable the business to move forward and encourage
continuous improvement.

1) Have Empathy for the Customer

2) Have Empathy for the Customer

3) Have Empathy for the Customer

4) Drive Uncertainty Out of Requirements

3) Be “Chief Unblocker”

------
wffurr
The easiest way to end up with "servant leaders" is for a worker owned co-op
to hire management, as opposed to the neo-feudalist corporate structure to
common today.

A "servant leader" who just decides to rule^H^H^H^H manage that way out of
their own "enlightened self-interest" is incredibly patronizing to employees.

------
commandlinefan
> Managers shouldn’t “negotiate” with the estimate

Well, the unspoken part of the negotiation process is, "ok, you said it was
going to take two month but how long would it take if you worked 18 hours a
day for the next 4 weeks straight? You are on a salary after all."

------
thewileyone
This can be applied across any job field. A good manager gets obstacles out of
his teams' way so that they can do the best job that they can.

------
D3vMn9r
All good theories go out the door when your dev team is offshore. Read good
detective stories for an inspiration: how to uncover lies, separate truth from
bluff, trust no one. Considering how many projects are done by offshore teams
- this article reads like a ballade to sunshine in the midst of a hurricane

------
gregoriol
While overall the article is interesting, I'm really disgusted by two
sentences: "In software it’s common to have something estimated at a day take
a week instead." and "The inherent inaccuracy of software estimates creates
extra tension that you don’t find in other industries."

Oh, poor thing, you feel so special by being a software engineer?

Have you never heard of construction projects taking many times the estimated
time/budget?

Maybe try digging a tunnel through a mountain, where the kind of rocks and
caveats you find on the way can make you overrun your estimates? Maybe try
sailing a container ship through an ocean, where a storm that appears in the
middle can make your straight trip take a week more because you must go
around? And we are not talking yet about building a subway line under a city,
dealing with legal challenges, ...

Wake up, this is called a project, this is called risk assessment and risk
management. It's maybe not done in your projects, but you don't need a fancy
name for it, it's what has been happening for millennias.

~~~
jdmichal
It also does not help at all that software "estimates" are typically just
sticking a finger in the air and seeing how hard the wind is blowing at the
moment. How many engineers are doing things like using real numbers from
previous work to build models before estimating? Do we really think that every
project is such a unique snowflake that we can't build models? You don't even
need that much data, as long as you're understanding that less data means less
certainty. Which is also why every estimate should be either a range, or a
single number with a confidence. "Previous work shows we can handle a project
of this size in 6 months 85% of the time."

Of course, this is not all on engineers either. I'm sure everyone has seen the
project manager who takes _estimates_ as _commitments_. Cultures that allow
that to happen will see repressing of generally good estimates. (If you use
modeling, you just boost your confidence interval appropriately. 6 months at
85% or 9 months at 95%? Pick which number you give based on your experience
with the PM!)

~~~
repolfx
The conversion of estimates into commitments isn't some exception to the rule,
it _is_ the rule which is why only fools give the business estimates for
things.

Also ...

 _Do we really think that every project is such a unique snowflake that we can
't build models?_

Well, yes. That's inherent to what we do. Every project IS a special
snowflake. If it wasn't we'd just download the software and install it. Oddly
enough, installing and configuring software that is pre-made _is_ very
predictable and such projects rarely overrun. The sort of projects we're
talking about are where pre-existing software won't do and thus, by
definition, what you need is something special.

~~~
jdmichal
Every structure and bridge and road and tunnel project is obviously unique
also. Unique terrain, unique architecture, unique engineering. If the idea is
to look to other engineering to improve this, again, it's not like software is
some kind of special.

~~~
repolfx
They're only unique in trivial ways. Roads are made of the same material
everywhere - they're different only in some strict geometric sense.

Meanwhile even very ambitious tunnelling projects like the Gotthard Base
Tunnel, if you watch documentaries about them, they only hit a very small
number of really unexpected issues even over long periods of time. Tunnelling
is an incredibly predictable business. You buy some TBMs, set them going and
worst case, you hit unexpected rock types or have an unexpected malfunction.
The technology is advanced but rock is the same as rock has always been. Once
the project planning is over requirements don't change. The course you're on
doesn't change. Workers are largely trainable and replaceable - you never find
you're unexpectedly relying on some random worker somewhere deep in the org
chart who is 50x more skilled than their coworkers and who just got poached by
a company that pays 3x as much as you can. The users/customers have no input:
they get what you deliver and a tunnel is such a simple thing talking about
whether they _like_ it or not is a nonsensical question - it's a tunnel.

~~~
jdmichal
As kaspy points out in his, this is just more software engineering hubris
playing out. I took architectural drafting classes in high school, and there
are tons of technical differences and considerations that go into building
design. And I was only dealing with _drawing_ them, forget about having to
have all that in my head and actually being able to make _decisions_ on it.

To make what I hope is an apt analogy back to software, you are basically
saying, "Oh, their job is easy. All they have to do is follow established
design patterns!" But, of course, we also have design patterns... Why don't we
say the same thing about ourselves? Because we know that that's complete
bullshit; there's a lot of thought and wisdom that goes into actually building
stuff around those patterns.

~~~
repolfx
Yes, but architecture isn't the same thing as road building where the same
small set of variables play out repeatedly over centuries. The work an
architect does is much closer to the work software engineers do.

