Reading about Bell Labs and Xerox PARC, both histories emphasize that part of the successful R&D formula is hiring the best minds you can, giving them resources, and then leaving them alone to follow their curiosity wherever it goes. (Expect that they produce something, but not what or when.)

The closing chapters of "Range" by David Epstein echo this as well. Hyper-specialization is a trap. Great results in the lab can be achieved by recognizing promising people, bringing them into your lab, and letting them explore.

Okay, got it.

Does this tell us something about hackathons? They last between 24 hours and a week, and programmers work together on whatever project they want to work on.

My personal experience from doing exactly one, for a previous corporate employer, is that they are fun and build team morale by working together without fear of failure. But they tend to produce software that demos well, but isn't really architecturally sound. It's proof-of-concept at best, and often rewards showmanship more than solid engineering.

I'm skeptical that hackathons produce the great results that peppy LinkedIn posts from recruiters and executives say they do. Really good engineering work comes from understanding the problems and constraints, thinking deeply about them, prototyping a solution, and iterating on it until you find the right set of tradeoffs that make your solution less bad than everything else. That's hard to do in a marathon session.

The question in my mind has always been why would a hackathon unlock great potential that was otherwise untapped during the day-to-day work? (Taking away fear of failure probably contributes.)

But, let's say it's true and hackathons really do produce meaningful innovation. Perhaps the mechanism by which it would happen is the Bell Labs/Xerox PARC effect. Bring in smart people, and give them the freedom to build what sparks their interest.