Teams are just small “societies” of different people coming together to work: And that is A) achieving personal goals and B) achieving the team goals. This is not an easy task. There is one basic project a team should set up: Development of a strong team statement. As I explained in my article “The Jerk is gone” we did this to have a powerful guideline to rely on when we face conflicts. I want to share those rules. They’ll work in IT teams as well as in any other workplace group of people.

1. Team Culture

• We respect each other.
• We try to build personal relationships to each other to foster faith and open communication.
• We value constructive critics and avoid to verbally attack each other.
• We treat other colleagues and the management, and also clients and partners, as if they were team members.
• We strive for celebration of personal and team success.
• As team members we offer help to find solutions even if the context is outside our responsibility.
• A solution or idea which evolved from the discussion of several team members is better then the opinion of just one single person.

2. Meetings

• We have a daily meeting between 10 and 10.15 where every team member has to answer 4 questions: What did I do yesterday? Did I accomplish every task? What will I do today? Do I have any problems?
• Additional meetings can be called to discuss critical aspects and architectural approaches in the team.
• All team members are on time otherwise the person who is late must rework the contents of the meeting and proactively gain and share information. Exceptions: Illness, holidays, meetings with clients or other departments.
• If someone calls a meetings that person is responsible to write the agenda and send it to participants one day in advance.
• No person will receive responsibilities without his / her agreement.
• For extraordinary meetings the team will appoint somebody to take the minutes.
• Solutions are more important then time. We finish any constructive discussion or solution finding process even if the scheduled time frame is exceeded already.

3. Communication and decision making

• At every time there is just ONE person speaking. Interruptions and side discussions are not allowed.
• We focus on facts; emotions and personal bias are ignored as far as possible.
• We respect the time of other team members and the predefined schedules.
• We first seek to understand what others really mean and try to avoid to judge them by subjective positions.
• We aim at distribute speaking time equally among the discussion participants.
• We respect and value the opinion and help of experts especially when they are team members.
• We accept the company’s hierarchy of decision making, given roles and responsibilities.
• We want to become better.
• If a team member identifies a problem he tries to deeply understand the problem and develops a few alternatives to solve it before presenting it to the team.

Those rules sound somewhat strict and some of them seem to be to unspecific. It is hard work to establish those rules within a team, especially when there are team members who find themselves to be restricted by them. But it can be a vital foundation of togetherness to find the best ruleset for the team and having the end in mind.

As Seth Godin, author of several books I would suggest (Tribes, The Dip, The Idea Virus), lately had written in his blog, there is one big danger a company has: A jerk “who knows every technical detail” and who is the only one “who can fix that big machine”. I once made an experience with such an “I am the sytem!” - jerk who almost completely destroyed the positive, innovative culture of a whole company just because he felt insecure and threatened as the team grew and new products needed new technical approaches which blew the scope of the existing system. The fear of loosing some of his control was greater then the fun and motivation every other team member felt when we started to leave the past to build a new future. He is gone! A year ago! But there is still a lot of everyday trouble in handling the system he once “owned”. The lack of documentation and system architecture, the narrowly confined parts other team members worked on in the past and the complexity of the overall system needs a lot of effort for extending the system or reengineering single parts to allow more integration. This effort costs time and money and often leads to frustration within the team. But nevertheless the team tried to make a virtue out of necissity: Every team member became an expert of a part of a system and is responsible for the evolution and also serves as the contact person if anybody has trouble or feature wishes regarding that special part. Additionaly we developed a team statement which contains several rules for open communication, sharing of knowledge and the team based ownership of code. Priciples that never woulod work that great if the team did’t have the experience of working with the jerk.

I think that Passion is one of the vital skills a software developer should possess. Passion for technology, passion for solutions, passion for progress. Mike Peters has pointed at this tellingly precise in his blog aritcle “How to pick a GREAT Software Engineer“. He writes, that passionate developers are characterized by reading DZone or TecCrunch, testing new software, or writing code in their sparetime:

Love what you do and pass that love to everyone you deal with. Always be positive, energetic and make progress, no matter what. What do you do in your spare time? If you’re not writing code, installing a virtual machine, reading TechCrunch/Slashdot/DZone or testing out the latest version of Windows 7, you are not passionate about technology.

I completely aggree with that. Of course there are things much more important then technology (family, friends, health etc.) but I think that passion in this context just means that technology is not just a job but also a hobby, a hobby which serendipously became ones job. And as a hobby it affects the daily life, the character and thinking. Maybe I can express it that way: A triathlet, a football fan and a technologist (to use a name which expresses the passion more then the title software developer) are on beach holidays with their kids and spouses. The triathlet will go on a beach run as soon as his kids are playing in the water and his wife is relaxing in the sun. The football fan will inform himself about the results of his favorite team. And he will buy newspapers, search the internet, call friends at home or ask other tourists until he knows how the match ended. And so is the technologist. He will pleasurably read a book about an interesiting field of technology at the beach (my beach lecture last year in south africa was The Big Switch written by Nicholas Carr). Maybe he actually will have his laptop with him to check his RSS subsrictions in the evening as soon as his family fall asleep; and some will start eclipse to try a  tutorial about the new framework or SDK. Those three guys have one thing in common: While doing their stuff they feel an inner satisfaction which is motivated completely intrinsic. Friends or their partners only have little understanding and will wonder how one can be that passionate about such an apparantly unimportant thing. But this question is not really important to the triathlet, the football fan an the technologist. Especially for the technologist its just a neat sideeffect that he can make a living with his hobby. To come back to the article I mentioned above: I think that its really important to be passionate about what you do when you work as a software developer or engineer. I made experiences that there are a lot of developers who understand their occupation as nothing more as a 9 to 5 job. In a lot of cases this will be enough. A lot of projects will succeed and they will implement some beautiful systems. But at the end of the day there is no fun and little innovative potential. They will mark time without making progress for theirselfs and on the team they are working in.