On my bike ride to work, I pass over railroad tracks that have been inoperative for years. I noticed that the transit buses stop at the tracks, open their door, and look before crossing the track. Of course, the driver need not fear an oncoming train; the only thing he will see is a rickety track sinking beneath overgrown brush.

I thought about this. The driver is required to stop at the track because that's what he is trained to do. If he didn't stop at the tracks, he could probably get fired for not following protocol. But as long as he acts consistently at any railroad track, he reduces potential risk, and his boss will never be confused about what his driver will do when he comes across a railroad track.

However, this has some obvious inefficiencies. There is no reason for a bus to stop at a clearly unused track; this delays the passengers and other traffic behind the bus. And given enough buses with enough routes over this track, someone could probably calculate the maintenance cost that these stops require.

In the transit organization, drivers act according to their training, and bosses can predict how their employees will react in these situations. The transit organization works based on documented practices. But what about an organization that is based on knowledge of ideals instead of strict documentation -- and from these ideas, bosses can still predict how their employees will react, without specifically encoding those reactions in documentation?

I'll call such an organization an intuitive organization. In an intuitive organization, everyone can accurately predict how their teammates will act, without those actions being specifically encoded in a strict document.

Good sports teams are intuitive organizations: players know they can rely on the skills and abilities of their teammates, without knowing precisely how their teammates will execute a particular move (but with a certain degree of professional understanding and knowledge of best practices).

I think a good software team can be an intuitive organization. If I know my team well enough, I can predict how they might design a piece of software, or how they may have addressed particular technical challenges. This is about having confidence in my team and knowledge of how they work; the past is the best predictor of the future. (It should be noted that this isn't about signing up my team for work they can't possibly commit to!)

This is quite powerful. The ability to know how a teammate will act, without explicit communication and without constraint to some particular set of rules, gives an organization a dynamic, agile edge over other teams that are more by-the-book.