Hacker News Reader

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 healthier, wiser, freer, more autonomous, more likely themselves to become servants?“

Do you think the senior can answer "yes" to this if they just acquiesce to everything?

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

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.

> Software actually is unique in this respect, because it doesn't work if it's not complete.

This is a point that really ought to be more broadly recognized. It's a pervasive issue throughout software development, and while the situation is improving I'm not convinced that's about any kind of improved design. It mostly seems to be a function of delivery mechanisms which can circumvent the problem - internet delivery of patches, automatic updating, and remote hosting of apps have all lowered the bar on "good enough to ship". The most obvious example is almost certainly video game development: planning and labor conditions haven't substantially improved, but the prevalence death-march development has been made much better by the ability to gracefully patch games after release.

"You can't ship a partial product" isn't universally true, of course, but building projects which can be shipped while incomplete requires planning for that option from the beginning, and has real tradeoffs. In general, software planning seems to either ignore this issue entirely and go vastly over schedule, or propose some agile/lean/extreme 'iterative' process without paying any attention to the requirements and costs of that approach.

Imagine telling a construction firm that you want a two-story 'minimum viable building' that you can work in while they add the remaining stories if things run over schedule. If they didn't refuse outright, they'd charge you double and design the entire process around that condition.

Actually, that metaphor seems like a pretty useful one. Both fields involve developing something which can't be delivered at intermediate stages, where iterative never-broken development is slower and more difficult, and where both unforseen (e.g. unmarked water main) and unforseeable (e.g. storm damage) problems can arise throughout development. And, consequently, both have a well-earned reputation for late, overbudget deliveries.

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

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 deep changes. The level of continuos delivery doesn't exist in other fields.

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.

Yeah, but the original teams that designed or built the building are long gone, and in many cases the tenant/remodel work can happen without any of the original blueprints. Buildings are meant to be modified, and this is why we have building codes, subfloors, ceiling tiles, etc. In commercial software, the startup hurdle is so great, that it usually means only a team that is contiguous with the original construction team can economically extend the original in a meaningful way.

Open source requires a different way of thinking about it; not all software can be open source. Not all buildings can be raised like a barn. In fact there is very little in the construction or civil engineering world that matches what happens in open source software.

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.

Except that hardware fails, but software should stay reliably running in the face of that system.

Think of software more as a neighbourhood, or even an entire city. Rebuilding any given building should not impact the running of the city itself.

Software is the creation of the spec.

To a newb just using Postgres should be new and exciting. It's such a rich database I am still learning, even after years using it.

Maybe that was just a bad example. But I don't know, even just using old HTML and CSS to set the page is always interesting to me, because there are always problems to overcome. How do we make everything fit on the page without it being cluttered? How do we let the user do this thing that they want while also not interfering with this other thing that they say they want?

After many years, I like to use old, established pieces, but fitting the pieces together is what I find interesting.

At the same time, when I was first starting out, there was a greater urge to roll my own. I remember rolling my own diff program, in PHP. It was worse at diffing than figuring out how to safely pass the inputs into the shell, and just using good old diff, but it made me happy and it was a useful mental exercise. Newbs need to stretch their wings and see how far they can fly. Their flight is probably much worse than just hopping on the ol' jet. It's a hard problem.

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".

I'm not sure the applying the ideas in the article requires Servant Leaders™ to explain to the people they're leading what Servant Leading™ is. I read it more as, if you're in a leadership position, here are some ideas which might make you more effective.