Was Steve Jobs a servant leader during the development of the original Macintosh?
Software development requires servant leaders
21–30 of 209 posts
Re: Software development requires servant leaders
#22> 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…
Pretty sure that the word servant had its origins from Latin (servus).
Obviously I meant the idea of a leader as a servant, not the word.
Re: Software development requires servant leaders
#23In 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. Technical and programming skills have very little overlap with successful team management skills. It's the very essence of the Peter Principle.
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.
Re: Software development requires servant leaders
#24> 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…
It's also similar to how the pope & bishops refers to themselves during liturgy. All Masses include a prayer for the bishop(s) and pope; when the bishop is the celebrant, he refers to himself as God's "unworthy servant", and if it's the pope that formula morphs to "your most unworthy servant".
Re: Software development requires servant leaders
#25Re: Software development requires servant leaders
#26While 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.
Re: Software development requires servant leaders
#27> 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
Re: Software development requires servant leaders
#28> 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
One can trace it back to ancient China and ancient Greece too:
Re: Software development requires servant leaders
#29While 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…
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!)
Re: Software development requires servant leaders
#30While 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 to your boss and saying "You know I was working on X, well X is harder than I thought, it's going to take longer". Well - is X harder? Or are you just slacking off? Or maybe you just took a stupid approach?
It's much more difficult to actually confirm that the cause of the delay is an external factor, rather than a reflection of the person doing the work since most likely the only person with a real understanding of exactly why something is difficult is the person doing the work. So there's a stigma attached that isn't present in other professions.