Building teams in a risk managed culture.

Once we have identified the teams we need to deliver value, the next step is to create the teams. As always, the way we reduce the risk in a system is to increase liquidity by creating options.

We started with an organisation like this:

And we want to move to an organisation like this where the each team has five to nine members:

The teams start by creating a skills matrix for the current situation. For the input team, that might look as follows:

This simple exercise is itself quite revealing. We can see that there are three areas of the input team. Whereas Sue appears to share her knowledge, Attilla and Walt look to be hoarding their knowledge. At this point we invite the Jabe Bloom observation… “We use the data as an invitation to go to the Gemba” rather than to make decisions. In one organisation with a failure culture, the leadership did not believe the results and decided to dig deeper. They discovered that some people were key man dependencies and wanted to hide the fact for job security reasons, either by hiding their knowledge or encouraging others to overstate their knowledge using Dunning Kruger Fu.

Attilla and Walt may have acquired their knowledge when the system was originally built and have acquired their position by “knowing where the bodies are buried. The testing framework is clearly not valued as it reduces the dependency on them, the only knowledge being how to disable tests written in the original build when they fail. Neither Attilla or Walt should be considered for a leadership role even though they are currently regarded highly by their failureship and the business for their ability to resolve crises that they have created.

Sue has apparently shared her knowledge through out the team which can easily be tested by asking Kevin and Paul to perform a refactoring without her assistance. Sue clearly values automated testing which is reinforced by the teams knowledge of the build process. Sue would make an ideal leader even though Sue is not so well known by the failureship and the business because her area of responsibility generates little or no crises.

When forming the new teams Attilla and Walt should not be allowed to do any work on the areas where they are a key man dependency. They should only be allowed to pair with others learning the area, or be instantly available to assist others. In particular they should be prevented from fixing any production issues which gives them credibility with business users. The “Walt” at one organisation was given the quarter end goal to train two other people. “Walt” ignored the goal and continued to fix production issues without showing anyone else what he was doing. Eventually he was locked out of the production system and his access to production issues was revoked. Kevin and Paul might be better candidates to work with Attilla and Walt as they are familiar with the practices involved in sharing knowledge from someone, whereas Tor, Sven, Hamdi and Joy might continue to work in the same manner.

The logic team might look as follows:

Although this might look a bit far fetched, this is exactly the structure for many analytics teams in investment banks where each quant is a specialist in each particular flavour of financial product.

The output team might have a skills matrix with at least three people with a “3” skill level for each component and task.

What this shows is that each team may have a different culture, and that in the case of the input team there is a failure culture and a risk managed culture within the same team. These cultures often clash with the result that the members of the risk averse culture leaving to go to an organisation where they are valued.

Who is in each team?

In the case of this system, poor risk management of key dependency risk means that it will be difficult to form teams of five to nine immediately. There will need to be an intermediary period of time where teams need to be larger to facilitate the transfer of skills. There will be a lot of pairing, and people who are key man dependencies will not be assigned tasks so that they are instantly available to support and coach others in their area of expertise.

Although the product owners and technical leads might have determined the teams needed to work on the backlog, the preferred approach is for the team members to work out which teams they would like to be on. There may be someone that a person wants to work with, or someone they want to avoid. The teams can use the skills matrix to identify gaps in their current capability. Team members can volunteer to fill those gaps by acquiring new skills. Once the longer term teams are established, the team members can work out who needs to be in the temporary larger team to effect skills transfer. This is a collaborative process across the new teams, for example Brie and Nate in the logic team commit to cross train each other on their respective specialist areas. If there is not enough business demand on the backlog to cover the appropriate areas, they might clean up some technical debt and perform some refactoring and writing of tests to get to know it well enough.

Once the team members know enough, they can split into the target teams.

Scaling Up / Scaling Down

When we want to increase capacity by adding a team, we get the team members to identify the new team structure which might mean creating a brand new team or forming a new team from existing team members. The new team members are added to the existing teams until they are up to speed at which point the existing teams split into the new team structure.

When we want to reduce capacity, we simply remove a team and redeploy it to a place where it is more valuable. Once again, the team members can come together using the skills matrix to work out who wants to stay and who wants to go.

The skills matrix normally partially exists in the head of at least one person in a failure culture. Using a physical version allows team members to collaborate in creating teams that deliver in a sustainable way because they have more fun.