Above and beyond any specific policy areas such as coding standards, seniority mixes and son on, the biggest and most important thing to manage is the overall software development culture. If you can energise the culture, and inspire people to believe in the mission, to fight for it like their own flesh and blood, as well as to honour each other's diversity of perspectives, you will achieve far more than by drawing policy lines in the sand. Keep it fun. Make the crew feel special. Give them a feeling that their futures are within their control.
This said, I would also recommend frequent peer code reviews - this will inspire better work, knowing that people are accountable to their peers. Also, be on the lookout for single-sourcing, and fight it off like the plague, even if it has a productivity cost. Yes, Natalie is brilliant with the middleware. But what if she gets hit by a bus, or leaves to have a kid? Defend in advance by ensuring there are others who can instantly step in and take over from her.
Again - an energised culture with a strong team spirit - a deep and powerful soul - will optimise the workplace far better than any arbitrary standards.
The Nations that have Ebola, have governments that want bribes and kicks back just so that non-profits can operate and help. Then even when they get there, more mafia style extortion occurs. Is there some way to change this behavior?
Give this man a big white pointy hat with eye-holes
Example - 10 keepers chosen, 4 in UK, 1 in Iceland, 2 in Australia, 1 in USA, 1 in Uruguay and 1 in Morocco. Policy chosen so that the cooperation of 7 is required to decrypt. Each keeper then is thus issued 84 strings. 1 agent dies, another agent gets busted, and a third agent becomes opposed to the decryption. This leaves 7 agents. They each send their key packages in to the time capsule curator, who decrypts each package, identifies which string within each package is need to form the key, XORs these strings, then arrives at a final decryption key. Even if an intelligence organisation manages to extract keys from 6 of the agents, they won't be able to decrypt. If on the other hand, they kill up to 3 of the agents and stop them returning their keys, the decryption can still go ahead. Ideally, you would want to set n and m according to perceived risk, plus the size of the data set. For example, 36 agents and 20 required would produce a key set which would fit into a cheap 8GB USB stick.
If I had some plant that was failing at 3:15am and costing me a fortune, I know which I would prefer to have on site.
It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.