I read a blog post titled “Where is the Foreman?” by Robert C. “Uncle Bob” Martin. In his post Uncle Bob suggests that software projects, like construction sites, need a role of Foreman. He describes Foreman as someone who is responsible for making sure projects is done as it should, essentially signing off everybody’s work.
I assume that the idea of a Foreman is to avoid the problem of shared responsibility. There is a saying that shared responsibility means no responsibility. Shared responsibility allows one to deflect responsibility as it is implicitly somebody else's problem. However assigning responsibilities allows one to deflect responsibilities that are not assigned to them, as they are explicitly somebody else's problem. If members of the team are trying to deflect responsibility, it is probably a sign of dysfunction within the team or the system around it. Trying to fix it with a rigid role means trying to treat a symptom not the cause. Having a Foreman in a team is saying other members are not professional enough to do their job without someone overseeing it. It is saying that they cannot solve their problems as a team. It removes need for all members to take responsibility and inhibits their engagement to the project.
What does Uncle Bob suggest a Foreman does in a software project? He reviews all the code, making sure it is of good quality before it is committed to repository. I agree completely that all code should be reviewed. But why should one person do all the reviewing? Pair-programming is done because two brains is more than one and because that way knowledge of the codebase is spread. Rotating code review duties can help spread knowledge and increase code ownership.
A true team does not consist of group of workers and an overseer trying to make sure that workers do not slack of from their duties. A true team is group of professionals working toward a common goal. Our profession does not need Foremen, we need professionalism and a culture that encourages leadership from everyone when needed.