Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development requires servant leaders

adl.io

Post reply on HN
Print view View original

111–120 of 209 posts

Re: Software development requires servant leaders

#111

Post by jdmichal »

repolfx wrote: post #91
jdmichal wrote: post #29

Earlier quoted context omitted.

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

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

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.

Re: Software development requires servant leaders

#112

Post by repolfx »

phakding wrote: post #32

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!

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.

Re: Software development requires servant leaders

#113

Post by kjeetgill »

jonstokes wrote: post #57

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

A little bit beside your point but I like your example and agree with it.

In the example the Senior IS the Newb at whatever team/managerial issue is part of their new frontier. Unless they have experience to run those ideas by they don't have anyone to point them to "postgres".

Re: Software development requires servant leaders

#114

Post by repolfx »

jdmichal wrote: post #111
repolfx wrote: post #91

Earlier quoted context omitted.

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

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.

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.

Re: Software development requires servant leaders

#115

Post by bradstewart »

brlewis wrote: post #35
eggie wrote: 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…

Being able to "write (either code or ideas)" is critically important to communication.

Re: Software development requires servant leaders

#116

Post by gwbas1c »

ptero wrote: post #67

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

There's a big difference between developing yet another e-commerce storefront versus something that requires legitimate research and development.

Far too many confuse the two, and the discipline and flexibility needed for both.

Re: Software development requires servant leaders

#117

Post by marcus_holmes »

mooreds wrote: post #88
groby_b wrote: post #81

Earlier quoted context omitted.

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…

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

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 :)

Re: Software development requires servant leaders

#118

Post by phakding »

repolfx wrote: post #112
phakding wrote: post #32

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!

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

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.

Re: Software development requires servant leaders

#119

Post by 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.

Re: Software development requires servant leaders

#120

Post by ken »

patrickg_zill wrote: post #21

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

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.

Post reply on HN