The Often Missed Team Building Activity – An Organizational Growth Strategy: Part 3

Next Up We Have Team Progression

This is another organizational growth strategy. In times of hyperscaling this adds unnecessary tension but if your organization is growing slowly and organically this may create the internal movement you need to unleash creativity and knowledge sharing that bumps up everyones game.

Team Progression works as follows: new hires (always or often) start in one and the same team (A). Whenever someone joins that team, someone leaves that team to team B and someone from team B leaves for team C. Deciding who moves once someone new joins can be decided through a pre-defined process or on a case-by-case basis. Both require different preparations.

The benefits

1. This organizational growth strategy provides a structured approach to internal movement and over time spreads knowledge of teams, customers, and technology. This helps build an informal network and improves feedback loops over time.

2. If this is based on volunteering, the person moving often gets an increased sense of purpose and motivation which can energize the team they’re joining.

3. If you have some level of predictability and a reasonable rate of growth, you can coach and train your team’s abilities to integrate new hires better. Such practices include making the internal mobility process explicit, creating a culture of frequent appreciation and celebration, and creating structures around knowledge sharing such as mob programming, getting a buddy, weekly show and tell, etc. (though these structures are valuable regardless).

The drawbacks

1. Instead of just affecting the dynamics of one team, one person joining the company affects the team dynamics of *all* teams. Sometimes for the better, but also for the worse (at least temporarily). That is especially true if you haven’t actively worked with improving the team’s ability to integrate new team members which again reduces psychological safety.

2. If you don’t actively and effectively work with knowledge transfer and collective ownership of code, a person leaving a team may create a new dependency. For example, she may have specific knowledge about features or may even be responsible for features or applications. If the team member brings the ownership with her to the new team, she’d dilute the different teams missions and will not be able to fully focus on the new mission. Neither case scales.

3. You may want or need to get managers or HR involved in defining the rules around career progression to ensure that it’s objective/fair and isn’t only based on the manager’s own discretion. So, more time spent in meetings.

Countermeasures

1. Facilitate relationship building between different teams through both formal and informal ceremonies.

2. Actively work to reduce personal dependencies by inventorying people’s skills and knowledge sharing around critical knowledge or systems.

3. Make your decision-making process as well as the prioritization process explicit as early as possible. If you reuse them between teams, transitioning becomes easier (though be aware of potential downsides if you do decide to centralize this aspect).

Do you want to get to know further organizational growth strategies? Read part 1 and part 2 here.