[and-not-drew]

> It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare.

I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different.

If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday.

I agree that achieving results is still priority #1, but the distance between that and #2 is very different.

[seadan83]

The power balance aspect to me is extremely interesting. On the one hand, there is a lot of power a manager has: - do you get the good assignments? - will your performance review cherry-pick out-of-context a worst sampling of 'goals' that were created in the last few weeks, or will it be a glowing report of what you did?

I think those managers that ask their software engineers to pound sand are generally going to be bad managers. Notably, who should you ask advice from, someone that has designed 10% of the system specs, or the person that designed 90%? (Guess what, software engineers design about 90% of system specs!) Citation needed, but the amount of specifications that engineers have to fill in is quite mind boggling (what happens to this web page if DB is slow? What happens when a user clicks this button while this other thing is still loading, etc..). So while the 90/10 split is an exaggeration, the point remains, software development is a highly collaborative activity, particularly with the engineers. Some have said that a software's engineer main job is to figure out how to achieve 80% of the benefit, with 20% of the work. This aspect is missing from the typical unit-level command and control example, notably the "commanders" in software really don't know what the hell they are talking about unless they engage in actual conversations with the developers and users.

[bumby]

This is a perspective that is bandied about quite a bit, but I don't think it's exactly true (or at least not true to the extent presumed). Personally, I've only heard it come from people who have little actual military experience.

Leadership capital is a perishable resource in the military. Junior troops are not dumb and if you treat them like crap and just use the justification that they signed the contract, you won't be a very effective leader. If I leader has to use that type of tactic (or use their rank, or whatever), it's an indicator they've messed up somewhere along the way. The power dynamic isn't as cut-and-dry as most outside the military think. It's not unheard of for junior troops to get a bad leader fired, and in the absolute worst cases junior troops can put a poor leader's lives in danger. The idea that good military leaders would tell their subordinates to pound sand because they signed a contract is more of a trope than reality.

There's a surprising amount of times when the incentives align for a military subordinate to NOT listen to orders and leaders have to actually rely on the social capital they've accumulated by building trusting relationships with their subordinates.