Team velocity [2] - the mission influences the velocity of the team

 As we have spoke last week, I come again to this subject of team velocity.

This week, more about the relation between the team's mission and velocity of the team members.

You may know that each team suppose to have a mission,  a reason to exist. Some teams are designed to generate new products. Some to run extended projects. Others to do average jobs. Depending on this mission, my opinion is that teams have already different velocities. A team to deliver constantly innovation will certainly have a higher velocity than the one responsible to maintain a plant.
Each team can ensure a broader on limited development path for its team members, without being a better or worse team. A better team is the one who can ensure a great development for a team member, without the need to change roles to often. The team itself can be organized in a way that knowledge is constantly exchanged, new challenges are introduced gradually and experiences are created in order to deliver better the results expected.
Let's take one example: John Smith is an excellent developer, mastering Linux kernel development. The team of John is a small team of 7, working for various platforms. Now, it is introduced Android and there is another good developer (Peter Horn) who has some experience already in porting Android. Of course, Android is based on Linux. What option does it have the team manager? One would be to put Peter in charge and give him some support from a junior developer. Another one to put John in the same position. I would put both in this task and give them complementary tasks. This way, John can increase his experience in Android and avoid some of the traps of porting *nix operating systems. On the other hand, Peter has a fairly good partner and could deliver fast, learn something new and satisfy one of the experts' needs: belonging to an exclusive group.

Team manager has the duty to adjust the velocity of each team member, in order to cope with continuous changes in the business development. Some team members may complain in certain situations and might be the need to change this speed. Other times, the velocity of the team might hinder the individual development. If there is a great talent, some alternatives has to be provided. For the normal persons, it has to be assessed if there is the need for backup immediately or the risk of fluctuation is limited. Discussing often with the team members about their perceived development needs is decreasing the demotivation and gives the manager the opportunity to cope with fluctuation risk. Additionally, he can make internal changes to optimize the results and facilitate the thrive of team members.

Senior team members, even they might be high on the development scale, still expect a progress. The challenge is to find this way.
Some of them look for new challenges in the technical field, other need to make a change to a managerial position, others would like to take more responsibility for an internal research project. There are many items that are perceived as progress and this are regarded differently by each of the team members. The more you can understand what moves ahead the team member, more you can adjust the setup of the team.

Managers have also to communicate their expectations and intentions in the setup of the team. The colleagues have the chance to choose if this enough for them or they need to make a change. They are still committed to the team, but they are showing their unhappiness. Might be contradictory, nevertheless the results are timely delivered and the transition to other team is made smoothly.

The adjustment of roles cannot be easily done. It's always a challenge.
Please remember an older post about choosing to be the "boss", if you think is to complicated.