Valve Software has a similar flat organization structure. You can view their employee handbook on their website[0], which outlines it pretty well(from the inside).
From what I've read[1], scaling of the small development/production groups is the pitfall.
Valve is the one I had in mind. I've read of some challenges they've had scaling. 50 and 150 seem to be magic #s in terms of organization size, and adding formality.
Thanks for your comments.
So just to make it clear, we've introduced this model, as we want to stay relatively small and to avoid second line of management.
Valve's example shows the cons of the model in a really big organization, while we are 20 ppl, friends and family and we know each other really well. Plus being devoted to agile makes us solve problems really efficiently.
I'm not trying to say that the model is perfect and we won't make any mistakes, but for sure we will avoid the biggest problems with scaling.