Lessons on building resilience in our team.

Problems:

1. We create bottleneck dependencies on individuals when they focus on narrow areas of expertise
2. Engineers don’t feel like they have agency, and don’t feel in control of their work lives

The following is all perfectly debatable, and I’ve taken a position and an approach. Would welcome any arguments to learn and get better.I see the journey from problem to solution as three levels of progression, as follows.

Level 0: “Assignment”

Level 1: Volunteering

Level 2: Radical volunteering

Level 0: “Assignment”

This according to me is the most primitive and least resilient state. It is not even a necessary stage in the progression, but a team may find themselves here due to circumstances. In this kind of team, there is an understanding, tacit or otherwise, that “if there’s an XYZ issue, then ABC should work on it.” XYZ can be a particular part of the stack, some feature, or a class of complexity, etc.The signals to look out for, examples:

1. It is very easy during sprint planning to decide who works on what because everyone knows who is the expert in which area
2. When you (as a manager) are tagged for something -some bug or aforce issue- you tag the first name that comes to your mind, based on your knowledge of individuals expertise in the team
3. Similarly, people in your team tag each other to take up tasks based on max familiarity.

Level 1: Volunteering

This is a reasonably successful experiment in the integrations pod, with admitted downsides.In this level, the engineer volunteers to work on something, after understanding from their environment whether it is an opportunity to learn or expedite things.This looks like, when there’s an aforce issue, you ask on the pod channel “who wants to work on this?“, and engineers volunteer to pick it up based on what they’re going for on that day, or in that sprint.Same pattern for sprint planning. Once the team knows the list of things to work on, they volunteer and pick up what they want to.Challenges and mitigating them:

1. What if no one volunteers, or just one or two people keep volunteering? You can orient the team to why we want to level up, and how we want to work. Set expectations on being proactive in picking up tasks. There may be that odd engineer who never volunteers, and that is an opportunity for a deeper conversation with him/her.
2. It takes time to find the right people, isn’t it faster if I can just assign people? Yes, but also more importantly, no. It takes time at first, but will help the team to move faster in even the medium term. E.g., if I route all backend integration issues to Nilansh, only the assignment is faster. There’s no guarantee that the resolution of the issue itself is faster because I could well be overloading one person.