Live data from Hacker News

Software development requires servant leaders

adl.io

41–50 of 209 posts

Re: Software development requires servant leaders

#41
post #35
post #2

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,…

The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. Do you really believe that? When you're interviewing someone to be your manager, is that what you look for? I don't. I look for communication skills, career development ideas, and evidence that they stay cool under pressure. Software development experience is definitely a plus, but I don't l…

I look for all of these things as well, and they are critical. But none of them have any relevance in a technical domain if the person who has them isn't capable of pulling more weight than anyone else. Management is only approximately a learned and transferable skill. At the end of the day, lack of capacity in the target domain will make any managerial knowhow useless.

Also to be clear, I'm not talking about software development in the mythical man month sense, but systems thinking and a facility with abstractions and math combined with the ability to make such ideas real. Such people have the power to lift everyone up to their level, guide the group along an easy path, and fill in the gaps in ability present in their team.

There is a reason that people learn martial arts from people who have developed skill at them, not those who are good at managing workouts. The latter will only teach you how to manage your workouts. If you want to learn an art, learn from a master. In technical domains the masters are the best leaders, and you learn from them in every sense.

Re: Software development requires servant leaders

#42
post #33

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 estima…

Yeah I don’t think he meant “you don’t find in other industries” as “you don’t find in ANY other industries”. I mean, you’re “disgusted”? Really? Reading all this seriously makes me think you need a vacation or something.

[deleted]

Re: Software development requires servant leaders

#43
post #6

Earlier quoted context omitted.

It depends on what kind of leadership we talk about. Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge. Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team. Human managers: they deal with personal growth and employment. They need eno…

I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if i…

Of course it makes it easier to have all three roles embodied in one person, but these are very, very different skill sets. In asking for one person who's good at all of them, you're talking about a seriously exceptional human being. There just aren't enough to go around.

Re: Software development requires servant leaders

#44

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 estima…

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines.

Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet have scientific support. I think that software his higher uncertainty because it is much less constrained than physical engineering. There are a relatively limited number of ways that one part of a physical system can impact other parts, and those are constrained by the laws of physics. Software systems have no such laws. It's often possible for any component to write to arbitrary locations in memory controlled by any other component. This is kind of like a rusty hinge on a 34th floor bathroom door causing a problem with a doorbell on the third floor. Those kinds of actions at afar just don't happen in the physical world and if they do, they happen via pretty well understood physical mechanisms. To make matters worse, the discipline of software engineering is less than a hundred years old as opposed to thousands of years for physical engineering.

It's not about feeling special. I think there is something fundamentally different about software.

Re: Software development requires servant leaders

#45
post #30

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 estima…

While I agree with you that software projects aren't unique in having difficulty trying to estimate things, I think that emotionally it's different. If you're digging a tunnel and hit a seam of unobtanium you can go to your boss and point at the seam and say 'Look at this big rock - this big rock is very hard, we had no way of knowing it was here but now we know we have a problem". That is very different from going t…

> since most likely the only person with a real understanding of exactly why something is difficult is the person doing the work.

This is often the case in other engineering projects as well.

But there's often less of an incentive to "confirm" that this is the case because if you (claim to) have hired the best people, to have given them the best possible training and working conditions, and every support in doing their job, it rarely makes any sense to go to them and figure out if they're really late because the problem is hard, or because they're just slacking off.

The investigation itself is rarely meaningful. Even if they are slacking off, what exactly do you expect they'll say? Yeah boss, we're just slacking off?

Managers who second-guess perfectly competent teams this way are usually shown the door (if they ever made it to managing something).

Re: Software development requires servant leaders

#46

> 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 onl…

With all due respect to Frederick II, the servant leadership goes back at least to Jesus of the Bible: "...let the greatest among you become as the youngest, and the leader as one who serves." Luke 22:26

Sure. That's correct for the general concept, but I was refering to the actual use of the name for the idea in German, because of the well known quote.

Re: Software development requires servant leaders

#47

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!

Go you.

Re: Software development requires servant leaders

#48

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 estima…

Software is the only discipline that exclusively creates practical results via ideas.

In excavation, you can see the dirt and rocks, and say "This terrain is different than we expected." and someone else can see the same terrain and say, "You are correct. Our assumptions were wrong."

In software, you can't show anyone that the situation is different than your assumptions, because the assumptions themselves are the material that you're working with. Building software is the process of turning assumptions into results.

Re: Software development requires servant leaders

#49

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!

Go you.

This was the only comment you made in 8 months. I feel honored!

Re: Software development requires servant leaders

#50
post #18

Earlier quoted context omitted.

I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if i…

This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they h…

I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a disaster for sick people (i.e. almost everyone).

For example, rarely does a firm just "hire" a lawyer and tell him what to do: they have to at least play along with the fiction that they are "junior partners" in a "partnership". They have professional obligations (to the Bar, for example) that are outside their employment obligations. It's not unreasonably for there to be more "overhead" positions for a practice than there are lawyers, because his time is to incredibly valuable that it makes economic sense for him to hire several paralegals and a secretary, not counting the "junior partners" that are employees in all but name. If lawyers were cheap (i.e. there was no cartel and fewer barriers to practice), the practice of law would look much different, and vice versa.

Post reply on HN