This is a collection of essays on software project management, first published in 1975. It's fascinating how much of the insights, opinions and troubles recounted in the book are still relevant today. Equally as fascinating are the constraints engineers had to worry about not too long ago, that are near irrelevant today.
In one of the essays on programming team structure and hierarchy, he describes a team that looks like that of a medical surgery. One engineer serves as the lead programmer and designer: they would write most of the code and be the final arbitor on design decisions. The other engineers take on supporting roles such a developer experience engineer for building helper tools, or a second-in-command that acts as an advisor to the lead on design decisions and where to make trade-offs when necessary.
Perhaps this still exists in some form on smaller (less than 6 engineers) teams today. I haven't been in the industry for long to know for certain. Why this was so enlightening to me was moreso the author's arguments for why this team structure is better than the "democractic" model where every engineer gets assigned a separate part of the system -- the setup I've seen most often in today's companies.
The author argues that this setup results in a system that has more integrity due to the design decisions returning to a single arbitor. Even when some ideas might be lost becausethe other engineers aren't participating in the core work, the author argues that the consistency in assumptions and design decisions across system components averages out to a better overall product. Even the speed of code output from such a team is not hampered, because the added overhead in communication and organization that would be required when multiple engineers are working on the same system would slow them down enough to cancel out the benefits of parallelizing the work.
This approach doesn't scale with more than 10 engineers working on a project, and it might not fit well for all kinds of projects, but it's an interesting analogy nonetheless.
If that sounded interesting to you, give it a read!