Comment by kqr

Excellent article. I'm going to pull out one point out of many that made me think:

> Project competence. You want to aim for something like a NASA mission control vibe

Having read a little about early Apollo-era (and earlier) mission control this was a fun comparison. The astronauts and flight controllers had no idea what they were doing! There was no textbook – they were performing a human first. They were generally young and very cocky people hired out of university, but were successful anyway, for some reasons, including:

1. They were further culled through harsh adversarial simulation training. This made sure only those that could cut it came out the other end.

2. They approached each new mission phase with a trial mission, each time extending the envelope in a controlled manner. (The cowboy moon touchdown on Apollo 11? It's often described as the first moon landing, but it really wasn't. It was just a test to see if they could reach the surface and get back up. The real first precision landing came on Apollo 12. Oh, but that was also just a rehearsal for the first scientific mission on Apollo 14, etc.)

3. They were fluid in how they organised themselves, and allowed mission needs to dictate which positions existed, rather than trying to impose a hierarchy onto a mission.

Going back to shipping, we can squint and look at this as:

1. Fake it, either until you make it or get tossed out.

2. Prefer to ship many smaller things than one big thing. This builds confidence in your abilities, gets you experience shipping things, and allows you more feedback to adjust to what the real project is.

3. Build coalitions across department boundaries, and draw on their support to ship.

Analogies are like scissors: more fun when you run with them.