4 ms·

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

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?

mooreds 8y ago
I think GPs point was that building cohesive teams is a known art and yet software folks keep trying to reinvent the wheel.
- marcus_holmes 8y ago
  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 :)
  - angersock 8y ago
    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.
    - Bartweiss 8y ago
      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.
- tomc1985 8y ago
  Software folks reinventing the wheel is a problem that extends far beyond teambuilding
deleted 8y ago
[deleted]

mooreds 8y ago

I think GPs point was that building cohesive teams is a known art and yet software folks keep trying to reinvent the wheel.

marcus_holmes 8y ago
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 :)
- angersock 8y ago
  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.
  - Bartweiss 8y ago
    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.
tomc1985 8y ago
Software folks reinventing the wheel is a problem that extends far beyond teambuilding

deleted 8y ago

[deleted]