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

171–180 of 209 posts

Re: Software development requires servant leaders

#171

Post by s73v3r_ »

CamTin wrote: post #161
Tyrek wrote: post #154

Earlier quoted context omitted.

Any sort of consulting work is effectively a bespoke product - I don't see how you can get to the point where you can 'mass manufacture' professional services.

But people don't want "professional services" at all: they want justice for the vendor who ripped them off and skipped town. They want a divorce. They want to make sure that, when they die, their daughter gets the house. They want a partnership agreement for their hot dog truck business. Later on, they might want to make sure that their partner doesn't skip town with the truck and stick him with the debts. These thin…

To be perfectly honest, a lot of your complaints sound like, "Why do I need someone who is an expert in plumbing to fix my pipes?" "Why do I need someone who is an expert in medicine to diagnose my illness?" "Why do I need someone who is an expert in development to develop my software?" And the answer almost always comes down to, because they've been doing this a lot longer than you have; they've been studying it more, and they know more about the pitfalls and potential issues than you do.

Re: Software development requires servant leaders

#172

Post by iamcasen »

jbell0385 wrote: post #93

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…

I agree with your point entirely. In practice, the software industry seems to be rife with a cult-like worship of humility and team consensus. So much so that consensus and humility have lost all meaning! Leaders should naturally rise for valid reasons, and their decisions and opinions should also naturally have more weight to them.

I'm all for letting the little guy get a seat at the table, and I'm all for hearing out people's ideas, but at the end of the day, someone has to make the call. That should be the leader's role. The leader will ultimately take the fall if their choice was incorrect, so the team should trust them.

The best companies I've worked for have had decisive leaders who cut through the nonsense ideas coming from their team (respectfully of course).

Re: Software development requires servant leaders

#173

Post by JimboOmega »

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

It's all I've ever wanted to do since I first heard about it in Joel in Software many years ago. The people side of Software Engineering is immensely more rewarding for me than the technical one. It's so satisfying to watch new hires in particular grow and get comfortable. Sadly, I don't often get to do it, and am usually pushed into more pure IC roles.

It's also really rare among companies I've worked at. Turnover is high and impressing people with flashy technology is key. Writing code that impresses is definitely the path to management. Those who sit back and try to understand the whole picture are viewed as uninterested. I've been consciously trying to get into more technical arguments because it seems to earn respect to have strong opinions rather than seeing both sides of the coin. Management (especially at the first level) is viewed as the person who evaluates other people's code and makes the best technical decisions.

The engineering side of that sort of environment burns me out more, especially as I get older. When I was in high school, sure, I loved to code, I loved the new tech, I loved experimenting with linux kernels and assembly and all of it. These days, it's just not nearly as meaningful to me as working with those around me. I know I'll never make better solutions as an individual than I would with a team around me. If I only get acknowledged for coming up with a way to run tests 90% faster or solve the weird rare bug nobody else could understand, my work life just feels incomplete.

However, engineering team management is chosen more on who can solve the problems the best, not who is the most interested in helping people. When I have expressed interest in management this is a very consistent message. Do you write the best code on your team? No? Then focus on that. This requires me to focus on the work I find less fulfilling - and be directly competitive with my peers. The exact opposite of what I want to do.

Maybe other people are getting credit for implementing the new flashiness in Clojure, but if they appreciate you clearing the obstacles to make it happen, isn't that satisfying? You get acknowledged more from below than above, and that's okay.

What I really want to know is, what's the suffering part of it? I've heard so many managers complain of not getting to write code any more - and been jealous and wanted to trade positions with them. You should get acknowledged from below, and honestly, if your next level management is good, they should see what you're doing as well. A lack of acknowledgement will always burn people out, but servant leadership shouldn't automatically mean that.

Re: Software development requires servant leaders

#174

Post by Bartweiss »

angersock wrote: post #128
marcus_holmes wrote: post #117

Earlier quoted context omitted.

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.

This is true, but it doesn't mean software can be delivered at any point in the development process.

Something like a novel is (hopefully) shipment-ready at most points from the first draft on. A full rewrite might happen at some point, but much of the development process happens after the first draft and can be interrupted with minimal cleanup. If you've only copy-edited half of chapter one, you can still finalize those changes and ship without trouble. And, you're unlikely to get 95% of the way through writing and discover an issue in Chapter 10 that invalidates chapters 2-6. (This does happen, especially with mystery novels, but it's not the standards outcome. It's much more likely to just hit a problem that makes you want to rewrite, rather than actually breaking the piece.)

A lot of software has a high percentage of work happen ahead of the MVP, and even if progress past the MVP is done while maintaining a working state, the individual tasks don't tend to be interrupt-able. If that shipping system is instructed to handle bulk-loading of 50,000 orders, fixing the manual zip code issue is probably still an all-or-nothing task. And, of course, there's a high chance of invalidating past work. If a contract comes in that requires multi-user ownership of orders, that might break invariants across the entire database while still looking to the buyer like "just adding another user to my order".

Pretty much any field has some minimum unit of work to move between acceptable states. You might print a novel mid-editing, but not while a sentence is half reworked. You can launch a new car model with fewer units finished than you'd like, but not (easily) with contracts for dealers that will be unfulfilled, and certainly not if you find a problem with the airbags.

Software development frequently gets planned like creative or social work which generally has small minimum increments and few catastrophic surprises, but ends up playing out more like construction or physical manufacturing where unexpected failures are likely and shippable states are noticeably far apart. Hence death marches, outright broken releases, and a lot of the other issues the field is infamous for.

Re: Software development requires servant leaders

#175

Post by devingoldfish »

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!

Hey man, as someone who also formerly worked in a different industry, thank you for raising this question. The longer I'm in software development (six years now) the more confident I am that all the varying rationalizations for this stuff are complete BS.

Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.

Re: Software development requires servant leaders

#178

Post by PeterFBell »

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

Maybe I've been lucky, but I've always found these principles to just be an effective way to enjoy life, build a great team and maximize business value.

Every day, I get to check in on my team and figure out how I can help them to be happier while also delivering more value to the business. And I find the longer I do it the more great surprises I get and the less I actually need to do to build and manage the org.

Re: Software development requires servant leaders

#179

Post by i6mi6 »

jbell0385 wrote: post #93

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…

Totally agree. I think the problem is that servant leaders can (in practice) easily get dominated by "the mob" and become even more servant to an extend where all respect is lost.

Re: Software development requires servant leaders

#180

Post by commandlinefan »

> Managers shouldn’t “negotiate” with the estimate

Well, the unspoken part of the negotiation process is, "ok, you said it was going to take two month but how long would it take if you worked 18 hours a day for the next 4 weeks straight? You are on a salary after all."

Post reply on HN