Live data from Hacker News

Software development requires servant leaders

adl.io

121–130 of 209 posts

Re: Software development requires servant leaders

#121
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.

Re: Software development requires servant leaders

#122
post #56

Earlier quoted context omitted.

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account f…

I've been developing CRUD apps for my company's clients for eight years. They're all superficially the same, but every single one of them has had something unique about their schema design, and they all have different business rules (in a general sense and in specific details) that make every project unique. We have a model that gives us ballpark estimates before we get into detailed analysis, but every time a custom…

Estimate higher then.

Re: Software development requires servant leaders

#123
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.

Re: Software development requires servant leaders

#124

Earlier quoted context omitted.

You will never know what you don't know. That doesn't change. The question is, what do you do about it? That tunneling project probably did account encountering different materials, but maybe not for unobtainium. If the area is known for unobtainium, that's obviously a research miss. If this is the first seam ever encountered within 500 miles, that's straight up unexpected findings. Most situations usually lie somewh…

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 have been hole-in-ones on every green, so why can't you do that for this shot? Are you an incompetent golf player? Are there super-competent golf players who can do this on every shot? Why not? This does not seem difficult to me (but then I've never hit a golf ball in my life). Can you explain why you can't do this, but other people have done it before?

Re: Software development requires servant leaders

#125

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

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.”)

Re: Software development requires servant leaders

#126

Earlier quoted context omitted.

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

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?

Re: Software development requires servant leaders

#127

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 efficiency. The difference is akin to why there’s so much work to get CEOs to be more efficient but not that much work to get janitors to be efficient. It’s not a value judgment. It’s just economical reality.

Re: Software development requires servant leaders

#128
post #88

Earlier quoted context omitted.

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

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.

Re: Software development requires servant leaders

#129

Earlier quoted context omitted.

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.

I'm not saying reduce the body count, I'm saying don't specialize. If you have three managers, have them do everything, don't fire two of them and give the third one the work of the other two. If you still disagree then I think we have different intuitions about the difficulty of wearing different hats in management positions. This is somehow analogous to the split on full-stack vs. specialized development. Interesti…

> Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.

I agree with that. The way I think about it is that in web you benefit from thinking about a system holistically. The divide between front vs back end is merely a technical detail, and an organizational structure that mirrors that divide has a strong potential to artificially create friction between two parts of what should be a whole.

Beyond that, I personally feel more empowered to take on responsibility as a full-stack dev, compared to when I was previously focusing on just the backend. For me, I think it’s mostly a psychological shift: I have more confidence to focus on solutions instead of deferring responsibility and thought power to someone else because it’s not my domain.

So, while full-stack may be a generalist (which for some is a pejorative) in a technical sense, I see the general technical acumen as just one aspect of a higher level, more intangible specialization: solving problems and getting shit done.

That sounds a bit lofty but I think it has analog to the bigger conversation here about managing.

Manager with holistic responsibility for a project > manager with isolated responsibility for a single aspect of a project.

Re: Software development requires servant leaders

#130

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

You’ve setup a false dichotomy. Servant leadership can & should be decisive.
Post reply on HN