Design consensus - the Apache way

The ways to lead the team

There are basically two extreme ways of leading the team of software engineers.

• Supervision. You control people in your team. You tell them what to do. You make a decisions for them, which you order to execute.
• Democracy. You are equal to the others engineers in your team. Your voice in design and architectural issues is equal to the voices of the others in the team.

As we well know, the bad team leads supervise their team. Good team leads serve their team and help them to perform.

The flaws of democracy

Let's face it - democracy is not always the best option.

Democracy in a team is good as long as all the team members are equally motivated, experienced and mature software professionals.

And what about new team members? They don't know the culture of your team yet. They need time to learn how people in the team works and what are the standards within in.

What about the responsibility? Your team works for somebody. Who should take the responsibility in the front of the business holder in the case of the failure? Who approves the critical decisions and takes responsibility for them?

The Apache way to lead the team

In Apache, all design decisions are based on the consensus between team members (committers). Voices of the project leaders (PMCs) are stronger than votes of regular committers.

However PMCs don't give the orders to the committers. They work with the committers on regular basis instead.  But in the case of design or architectural disagreement, PMCs are the ones who decide.

In order to become a committer, you need to work with the project team as a contributor. While being a one, you got no decision voice in the discussion. The is the time you learn the project and the way the Apache works.

I like to think of the good team as of the little Apache project. With a tech lead being the PMC, regular team members being the committers and team newcomers being the contributors.