Software development requires servant leaders

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 things don't necessarily require professional services. They certainly don't require taking time off in the middle of the day to go to an oak-paneled office with potted plants and an anteroom. We could organize our society to give people justice without traditional law practices. We've chosen not to because the benefits accrue to a well-connected minority and the downsides accrue dripwise to the rest of us.

Note that LegalZoom and a few others are indeed trying to do this, but even they are forced to equivocate that they're not really lawyers. It's the legal equivalent of making tobacco companies put diseased lungs on their cigarette packaging, except it's not correcting for an externality, but imposing one. Why do I even need LegalZoom for a will? Shouldn't there be a government website where I can register my will for free? Should I need a lawyer and a judge to give me a no-fault divorce?

The raft metaphor is a good one.

I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs."

I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart".

Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products.

This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos.

If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.

There seems to be this odd sentiment in the comments here that, unless you're an absolute tyrant, then you must be a weak leader, not directing people and not holding teams accountable. This concerns me greatly, because thinking that "strong leaders" have to be tyrants is a big part of what lead to the Maryland football tragedy.

From this article, IMHO these are the most important for [technical] leaders, in priority order.

All other things : trust etc - effectively fall out of these, because these are the things that will enable the business to move forward and encourage continuous improvement.

1) Have Empathy for the Customer

2) Have Empathy for the Customer

3) Have Empathy for the Customer

4) Drive Uncertainty Out of Requirements

3) Be “Chief Unblocker”

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