philipp's blog

Use Staff Liquidity for Team Growth

It's a typical complaint from any Engineering Team: We are too small, we need more people to deliver high quality software faster. From the team leadership perspective, things get complicated fast: What kind of roles do we need to fill? (Don't forget to [take into account that there is more to consider than just the job title!]({% post_url 2020-10-21-focus-on-the-right-roles %})) How high is the risk that this role will eventually run out of work, since there is a bottleneck elsewhere in our team, or because customer demand changes? And perhaps most critically, does the new person arrive on time? Adding new people to the team means, even if we lived in a world where a recruitment process would nonexistent, that we have to invest time of other team members to ramp up the new hire. For the first few months, we will be investing more time and effort than we will be getting out of it.

Staff Liquidity can help address these issues, by approaching the problem from the perspective of knowledge sharing and dependency reduction within a team. The excellent book "Commitment" explains the basics of this in great detail, and in this post, I want to highlight how to use this in an engineering team.

Staff Liquidity requires the following three steps:

Assessing the risk

The first step to put Staff Liquidity into action is to find out what you are up against. Make a list of all the different steps in your development workflow, from start to finish - for example:

Of course, you can go into much further detail if needed. You could, for instance, ask about different facets of testing, such as TDD, exploratory testing and test automation, or about different aspects of development, such as different languages and frameworks used by the team.

Then ask every team member to rate their own expertise in each area. Don't worry too much about people being too optimistic or unrealistic about themselves - things will even out on average. Make sure that you provide the team with enough options to choose from - a scale of 1-3, for example, would lead many people to assess themselves as "2", because even if they think they are good, they might have doubts if they are good enough for the highest possible grade.
The easiest way is to ask the team to rate themselves on a scale of 1-10, where 1 means "I have no idea how to do this", and 10 means "This holds no secrets to me".

Where Do You Want to Grow Today?

The second question to ask is, for each area, whether or not that person is interested in diving deeper to learn more in that area. It's a difference between being able and willing to learn anything and everything, and being actually interested in and intrigued by a specific area, so the answers to this question will help you a lot with the next step.

Identifying and Prioritizing Improvement Areas

Whatever scale you use, when evaluating the results, you should treat someone who has given themselves a ranking from the top third of the spectrum an Expert. For a scale of 1-10, this means that everyone who rated themselves 7 or higher would be an expert.

Then you simply count the number of experts in each area, and you classify the risk at follows:

We will combine this with the results of the second question, to ask ourselves: Do we have enough people who would be willing to become experts in these areas?

This gives us the following matrix, where an "Expert" is someone with a high enough self assessment, and a "Learner" is someone who is not an expert, but interested in growing and diving deeper in that area. We say that we don't have enough learners if not enough people are interested in learning to generate enough experts.

Enough Learners Not Enough Learners
Enough experts Green Zone Green Zone
Not Enough Experts Yellow Zone Red Zone
No Experts Orange Zone Red Zone

The Green Zone: Nothing to do Here!

Areas in which we have at least three experts are considered the Green Zone. The risk for bottlenecks is low, so is the so-called truck factor, which indicates how messed up your project is, should a key person be run over by a truck (You can also call it the Lottery Factor, in which case it would indicate the risk if a key person wins the lottery and leaves the company).

Yellow and Orange Zones: Build Up Those Experts!

The Yellow Zone has less than three experts, the Orange Zone has no expert at all. On the other hand, there are enough people interested in becoming experts to fill those gaps. All we have to do is make room for learning - depending on the zone, people will either learn from existing experts, or need to get some external training or learning to become an expert in the area. We will look into how to make room for learning below.

Generally speaking, the Orange Zone should be tackled first, since having no experts for a certain area is generally worse than having not enough experts.

Red Zone: Houston, We Have a Problem

The highest risk for any team is a red zone, where experts are needed, but not enough people are willing or able to fill in this role. For all practical reasons it doesn't matter whether or not we already have one or two experts for the area - the stress that lands on their shoulders by being the bottleneck all the time will soon drive them away.

It's important to fill these gaps as quickly as possible, and if really no one in the team volunteers to step up and fill the gap, there is no other choice but to look for help from outside of the team.

How to Make it Happen

The previous steps of this assessment has resulted in a prioritized list of areas that need improvement. Now, how do we best build up experts in the area that we need?

Teams usually make the mistake of letting Seniors do the stuff they are experts in. After all, they are the ones who are most efficient in solving the issue! While this might be true, this also prevents the learning and knowledge sharing that needs to happen.

So instead, by default, every aspiring expert should try to get their hands on an issue of their future area of expertise. They should work with it as best as they can, and rely on feedback from existing experts to learn.

In the beginning, Pair Programming between experts and learners helps establishing a baseline of knowledge within the learner. Once both the learner and the expert are confident enough, the learner can start working on their own (depending, of course, on the team's way of working), and frequently pull in the expert for opinions.

Another piece of advise is to see features as learning opportunities instead of some work that needs to be ticket off some To Do List. That way, items which are already done and shipped can still be passed to the expert for review. This doesn't block the release of said feature, and it's obviously not the goal to introduce late changes to the code, but it creates an opportunity for the expert to share more knowledge with the learner.