Hacker News Reader

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

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

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.

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.

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

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/

> the time zones are killer, and this can't be ignored

100% agree, especially when there is minimal overlap during normal office hours. I was managing a dev team in India from the US and it was a real challenge. The company ended up moving team to the US, relocating most of my team. Despite all the people being the same, management became much easier.

Since then I've done US and EU, and EU and IN, and those have all worked fine because we had sufficient overlap during business hours.

If you needed 8 hour overlap you were micromanaging?

Was that because of the above cultural differences?

He didn't need 8 hours, but zero didn't work. The us and india are about 12 hours apart (there are 4 times zones in the us, day light savings time, and india is offset half an hour, but it rounds out to 12 hours for discussion)

> If you needed 8 hour overlap you were micromanaging?

...ok. I didn't need 8 hours of overlap.

As I mentioned in my first comment, I've also now done US/EU and EU/IN. Both of which have only partial overlap and things have gone well.

With US West Coast and India, I was often doing meetings at 7AM and my devs were doing meetings at 9 or 10PM. That was challenging, irrespective of any cultural differences.

> Contractors on any continent are a whole different story.

Having spent the last ~7 years working for different startups before pivoting, my advice to any founder is this: do not hire overseas consultants. They're good, competent people, but you and your company do not have the tools or the culture to actualize them.