Software development requires servant leaders • Hacker News Board

Re: Software development requires servant leaders

#141

Post by agentultra » Wed, Aug 15, 2018, 3:46 PM UTC

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.

Re: Software development requires servant leaders

#142

Post by zb » Wed, Aug 15, 2018, 3:52 PM UTC

scarejunba wrote: post #127

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!

Well, because we develop more value than structural engineers faster than they do and have killed far fewer people than they have. Essentially, we’re economically more efficient so a 10% improvement in our performance is huge, while a 10% improvement in structural engineer performance is a waste of time for the cost incurred. Therefore, software engineers get a lot more attention in terms of how to increase efficienc…

A less glib way of putting this is that in structural engineering construction costs dwarf design costs, while in software engineering the reverse is true.

If your construction phase consists of "type 'make' and grab a coffee" and the most expensive part is the coffee, then any efficiencies you can find in the design process will make a big difference to your bottom line.

If your construction phase costs tens of millions of dollars, you'll want to invest in designing more efficient construction methods rather than worry about tweaking the design process.

Re: Software development requires servant leaders

#143

Post by cvoss » Wed, Aug 15, 2018, 3:52 PM UTC

RobertRoberts wrote: post #139

cvoss wrote: post #136

Earlier quoted context omitted.

I think (correct me if wrong) you have interpreted the phrase "servant leader" to mean "a leader of servants". Rather, it's intended meaning is "one who leads by being a servant".

No, I interpreted the implied meaning behind the phrase, it's just as meaningless either way. "One who leads by being a servant" is a non-leader, it's an oxymoron, maybe that should have been my phrasing. Also, it smacks of false humility. No one would call themselves a "servant leader" if they were actually a servant, they would just say "servant". Anyone who calls someone else a "servant leader" is choosing their w…

The paradox in terms is entirely intentional. It is supposed to make you stop and think, "How can this be?", because it pushes back against many qualities often traditionally associated to leaders. So in fact, I stand corrected, and the phrase has done it's job in communicating to you exactly what was intended. It is not meaningless after all!

(Also, I agree that to self-identify as a servant-leader is not a humble thing to do. But that's true of self-identifying with just about any virtue.)

Re: Software development requires servant leaders

#144

Post by 52-6F-62 » Wed, Aug 15, 2018, 3:52 PM UTC

marcus_holmes wrote: post #124

52-6F-62 wrote: post #60

Earlier quoted context omitted.

I wholeheartedly agree. I think it’s however more of an unacceptable problem in non technical industries who hire technical workers. For instance, risk assessment isn’t all that helpful if your deadlines are bumped up by weeks or months and the client or your coworkers or bosses have no concept of why the project “can’t just be done immediately” when you’ve planned for added weeks. Even worse when they don’t understa…

I usually try to explain this using a sporting analogy, because the people who treat this as a "nerd problem" usually understand and relate to sporting analogies. Why can't you hit a hole-in-one on every shot on a golf course? You know exactly where the ball is, where the hole is, how far it is, which way the wind is blowing. All you have to do is hit the ball so it goes in the hole. It's definitely possible, there h…

That's pretty good. Hope you don't mind if I end up using that or a variation in the future.

Re: Software development requires servant leaders

#145

Post by kaspy » Wed, Aug 15, 2018, 3:55 PM UTC

repolfx wrote: post #114

jdmichal wrote: post #111

Earlier quoted context omitted.

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

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

That's about as accurate as saying that software projects are only unique in trivial ways because there's probably already a free library or plugin that can do whatever else you need. It's easy to assume your occupation is much harder than everyone else's but we rarely have deep knowledge of the challenges other people face day to day outside of our own line of work.

As a simplified example, the design of a road, its pavement layers and its foundation is determined by factors like traffic loading characteristics, service requirements (peak capacity), speed limits and visibility, ground conditions, climate and more (see Caltrans' Highway Design Manual at http://www.dot.ca.gov/design/manuals/hdm.html), many of which rely on professionals in entirely other fields.

Re: Software development requires servant leaders

#146

Post by drharby » Wed, Aug 15, 2018, 4:00 PM UTC

agentultra wrote: post #141

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

You can be a servant leader and still take credit for things. Servant leadership is about enabling success, not sacrificing one's self.

Sure there is a notion the time taken to help someone is time taken from helping yourself, but if management doesnt view that as a global optimizing act, you've bigger problems

Re: Software development requires servant leaders

#147

Post by danielovichdk » Wed, Aug 15, 2018, 4:10 PM UTC

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

Re: Software development requires servant leaders

#148

Post by tomc1985 » Wed, Aug 15, 2018, 4:15 PM UTC

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.

Software folks reinventing the wheel is a problem that extends far beyond teambuilding

Re: Software development requires servant leaders

#149

Post by ahayter » Wed, Aug 15, 2018, 4:23 PM UTC

heartbreak wrote: post #133

guelo wrote: post #131

Earlier quoted context omitted.

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done. In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making de…

Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.

This analogy is one of my personal favorites for software development. The machine that is going to be running the software could be considered our building. The hardware of the machine is designed to exacting specifications by people that typically hold university engineering degrees and is much more reliable than software typically is, it has to be or nobody would use it. Failure of the building is catastrophic to the tenants.

A process could maybe be considered a room within that building and adding functionality to that process is akin to adding furniture to a room, or I guess, doing a buildout for a tenant. You add specific furnishings to help you accomplish specific tasks within that room.

This analogy breaks down pretty quickly, but think about the room here. I can now explain to a non-technical person that this software (a single process in this case) is like a broom closet that we've shoved full of old furniture for the last 5 years. Prior engineers have stacked tables to the ceiling, filing cabinets have locks without keys. We don't even know what's in the back of the closet at this point, and getting a peak at what's in the back will require unpacking everything at the front.

On the other hand you could have a different room. It has doors for egress and ingress. It has glass walls so we can see what's happening at all times. We carefully arrange the furnishings for efficiency, and can swap out old furniture for new in a matter of moments. We regularly clean the room, removing unused/aging equipment etc... When people enter that room to work (end users) the workflow is effortless and intuitive.

So as a software developer/engineer or whatever you call yourself, we're more like the contractors that buildout interiors for specific use cases. We equip the rooms for doing specific jobs. You give us the building or even just one room and we'll make it useful.

Re: Software development requires servant leaders

#150

Post by repolfx » Wed, Aug 15, 2018, 4:34 PM UTC

phakding wrote: post #135

repolfx wrote: post #126

Earlier quoted context omitted.

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?

https://www.usatoday.com/story/news/2018/03/16/miami-bridge-... http://www.ejinsight.com/20180406-hk-engineers-raise-concern... 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. Als…

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.