Culture: Competence verses Team

For most of my carreer I have worked in organizations with a competence culture. This is a culture that relies on very good developers who do their job well as an individual. The individual is recognized for their contribution to the organization. I have to admit I have performed well in a competence culture. During my tenure at Texas Instruments I obtained the position of ”Member, Group Technical Staff”. This is Texas Instrument’s first level of recognition of key technical leaders.

The competence culture seems to have served most of the companies I work in well. So what are the downsides of such a culture. Here are some of my observations over the years.

1. Knowledge hoarding
   Knowledge is the key in the competence culture. The more you know and understand the greater the recognition. You do not have time to mentor others because you want to make sure your corner on knowledge is protected.
2. Individual politiics
   It is who you know and can impress. Now no one would admit this directly but we act it out. We make sure we get invited to the right meetings and talk with the right people.
3. Lack of code ownership
   As we move about the company we leave our current projects to work on new better  projects. No one really owns the code. It is left for others to fix the bugs. How do you track down who can work on a bug when no one owns the code? Take a look at some legacy code. How did the code become such a mess? Was any one really proud of the code?
4. Lack of continuity
   No one really understands the legacy code because the individuals are gone who worked on it. There is no shared domain knowledge.

How does this differ in a culture built around teams. Here some of my observations:

1. The team is the priority
   The idividual becomes a contributor on a team that is greater the sum of it individuals. We work first and formost for the team. Other commitments take a lower priority in the company.
2. The team grows individuals
   In participating on the team we become better and more well rounded developers. The individuals share their knowledge with each other. We work on helping each other to enchance their skills.
3. The team respects individuals
   All of us have important contributions to make to the team.  The most junior developer is considered a very important member of the team. We listen to and respect all voices. All of us have blind spots and it takes others on the team to protect us from ourselves.
4. The team become the repository of knowledge
   We as a team take responsibility for the software we are working on. We as a team own the code we work on. If a defect is found in our code we will fix it. It is the teams code not an individual’s code. So if an individual leaves a team others in the company know who to turn to when a defect is found in our code.
5. The team become the champion of quality
   We set our standard of quality. We want our team to be recognized for producing quality products. We know our reputation as a team depends on this and we cannot hide by moving on. We are really proud of our code.

This ideal culture built around teams takes years to build. You cannot be reforming teams every 6 months and expect to create a culture based on teams. Teams need to be in place for years. Sure the members of the team may change but the team itself will live on.

In order to have long lived teams it is best to have 7 members on the team. This way even if two team members move on at the same time you still have enough core team members to move forward and train new team members.