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.

Choose your weapon - wiki tools

So you feel bad about not using wiki, as you ought to? You wanna change it? You need a recommendation for the great wiki tools? I can recommend two of them.

• Google Sites - free wiki from Google. Perfect choice if you need to save some money and can keep your data in the cloud (people in corporations not always can).
• Confluence - great product from the great company named Atlassian. We use it at the Apache Camel. Can can host private instance of Confluence starting from 10$ per year (or pay Atlassian 10$ per month to use their cloud).

I've also worked with Alfresco and JSP Wiki, however I don't recommend them. Too complicated and unintuitive comparing to the Google Sites and Confluence.

I'm curious about your experiences with wiki tools. Any feedback will be highly appreciated. :)

Team hive mind

I'm always surprised how many developers don't got the habit of using company wiki. Wiki is a must-have for any development team that wants to be productive in the long run.

• If you don't share the details of your system's architecture on the wiki, how can you expect your team to understand the application they are working on?
• If you don't share the description of your development process, how can you expect your team to follow it?
• If you don't describe your coding practices and standards on shared wiki page, how can you expect your team to apply them?
• If you don't document the results of the research that took you a week, how can you expect your team not to loose another week on reinventing the wheel?
• If you don't share your knowledge and keep it in a single place, how can you even think about leaving the company for a week of a holiday?

Whenever somebody within your team asks you a project-related question, ask yourself why this information is not documented in the wiki in the first place.

Team bootstrap

As some of you may know, recently I changed my employer. I decided to start working for the pretty large american corporation - Pitney Bowes. We specialize in hardware and software solutions for automation and monitoring of postal processes and surroundings (printing, packaging, delivery and so forth).

I'm responsible for setting up and leading engineering team for Java development center emerging here in Poland (Bielsko-Biała). This is the very first Polish team outsourcing the US Pitney Bowes Global Technology Center. This is pretty exciting opportunity as I've been granted much freedom in shaping the form of the team being created here on the Polish site.

As I'd like to summarize my existing team leading experiences and confront them with the best practices of others, I decided to create this blog tag - team bootstrap. I plan to publish here my thoughts on building the efficient Java team with the strong engineering culture.

BTW If you...

• are available to work in the office in Bielsko-Biała (Poland)
• know Java
• would like to work on the challenging messaging-related project
• would like to work in the team with engineering culture certified by my humble person

...then you should drop me a line :) .