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