This sounds a lot like "What we do at startups smaller than 10 people." At least, it's pretty similar to what we did at my last company and a few others I've s

This sounds a lot like "What we do at startups smaller than 10 people." At least, it's pretty similar to what we did at my last company and a few others I've seen. In my single anecdotal experience, we tried to keep this sort of "Everyone is self-directed" mentality as long as we could. As long as everyone could keep pretty much complete knowledge of the system and product needs in their heads, it worked great. Everyone coded, everyone answered support emails, and there were no formal rules. After a while, though, it sort of broke down. One day I looked up fro the subsystem I was working on and realized I had no idea what was being worked on in a couple other areas, and needed to ask people when I wanted to do work that might affect them. One dev found that he was increasingly the person people came to with higher level questions about what other people were doing, and the person to consult with when considering a new project. We also found that important bugs and projects were falling through the cracks because there was no clear person to whom they would fall. So other devs took up that roll. By the time we actually named a few people "Leads" (they were effectively proto-PMs), it was just putting a label on what was defacto happening. That was the first of several aspects of project process and management that arose relatively naturally as we grew.