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.