[Aerolfos]

> But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.

Very common pattern you see in literature about military strategy, actually. The answer is delegation, heavy use of NCOs, and in general explaining the plan all the way down to the individual soldier. Under the western school it all falls under "initiative".

Notably, a lot of non-western militaries are terrible at it, and a number of military failings in africa, the middle east, and the soviet union (*cough*russia*cough*) are viewed as failures in flexibility with very low initiative, as well as lacking/unskilled NCO corps.

Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.

[swiftcoder]

> Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.

The most successful engagements I've had with contracting firms have been when we've shelled out for a team manager and a software architect (in addition to the number of straight developers we want).

The software architect builds a solid understanding of our solution space, and from then on helps translate requirements into terms their engineers are familiar with, and provides code reviews to ensure their contributions are in line with the project goals. The team manager knows how to handle the day-to-day reporting, making sure everyone is on task, escalates blockers over the fence to our engineers and managment, etc.

Without those two roles from the contracting firm's side, I find that timezones and cultural mismatches (engineering culture, that is) pretty much erase the impact of the additional engineering headcount when adding contractors.

[kjellsbells]

Army manual FM 22-100 is a very good read on this topic. The impact of giving NCOs both freedom amd guardrails is immense.

link here (ironically, on a blog that critiques it)

https://armyoe.com/army-leadership-doctrinal-manuals/

[actionfromafar]

Explaining the plan to the individual soldier also works better when the individual soldier is expected to care at all about the overall goal. (Such as believing in the mission of defending the home country.) When the soldier only has extrinsic motivation such as money, top-down command and control and treating soldiers solely as equipment to be spent makes more "sense", in a terrible way.

Maybe that applies to software orgs too, somehow.

[bluGill]

IT also only works if the soldier is well trained in the things he can do. I can teach you to shoot a machine gun in a couple hours - and half of that time will be figuring out how to shoot and clean it myself (I've used hunting rifles and have enough mechanical knowledge that I think I can figure out the rest - but someone who knows that gun can likely find something I would not figure out). That will be enough for "spray and pray" which is a large part of what a machine gun is used for.

However in a real war you need to figure out what direction to point the gun, and need to know when to fire and when to not. I don't know how the army handles "we are advancing now so don't shoot", or "we are crawling along the ground so make sure you shoot high": someone else needs to give anyone I train those orders. The army trains their machine gun operators better so they can figure a lot of that out without being told.

[Aerolfos]

Good leadership means getting the individuals to care. That's no different in software

And yes, good leadership is very hard, and many managers aren't any good at it