alt Hacker News> 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.
Replies
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)
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.
> 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.