The way I interpreted larrik's comment, he meant things like interfacing with other layers in the company, interfacing with other managers about the team's capa

The way I interpreted larrik's comment, he meant things like interfacing with other layers in the company, interfacing with other managers about the team's capacity for support, etc. Most of the things you mention I would include in "development". What you seem to call development I would specifically call implementation. Although, it can be beneficial to have different people for a lot of the things you mention, especially as a project grows in size and scope. And you need at least two people if you include review; reviewing one's own work is far less effective. Same with testing. Plenty of great devs are not great or don't like presenting, etc. If you do go the route of splitting responsibilities, you're going to be more efficient if you have someone coordinating their efforts, reducing the communication overhead for the whole team by being a central point of synchronization. That's one of the responsibilities of a good manager.