If done right, building redundancies within a team can increase its resilience to change.
What is redundancy?
Redundancy is an intentional duplication of efforts, to make sure your team does not fail or fall behind. It can increase the ability of your team to reliably complete its workload. In some situations, redundancy can augment performance.
You should not consider it in the same vein as unintentional redundancy. Corporate parlance has given the word “redundant” a certain connotation. That a person, tool or set of activities are no longer useful for any particular purpose.
Computer engineers have built redundancy into their work for decades. Think about the Internet itself. It rarely goes down despite ongoing hazards. That’s because redundancy’s at play.
Technology authors like Minda Zetlin have noted the irony that IT managers are “quick to create redundancies around potential failure points in their [computer] networks, but not around potential failure points on their teams”
Reasons to create redundancy in your team
Increase resilience to team member exits
Teams tend to hire specialists or eventually turn people with all-rounder abilities into a specialist at something. That’s not always the case, but it happens often enough for me to know it does. It strikes me as a habit of Taylorism.
Trouble brews when said specialist leaves the team – either by leaving the company or moving on to another team. The result of this event is a temporary productivity loss -from the departure of abilities and experiential knowledge.
When this happens, the team relies on remaining members to pick up the pieces and get-to-speed. It’s either that or wait for a new hire to arrive. How fast either party gets-to-speed depends on the complexity of work and how capable the replacement is.
Nonetheless, it is downtime your team may not be able to afford.
One issue does arise from having redundancy in place. We have to consider reliable crossover. From a design perspective, how do you switch from Item A (which is somehow broken) to Item B without losing data or meaning?
In the team context, how do you transition from a team member exiting (breakage of workflow) to another taking over their work with minimal loss of productivity? There are a few ways you could achieve this:
- Shadowing. Assign a replacement team member to follow your exiting team member well before the departure date. Get them to understand the nuances of the work. They should work out highly nuanced matters like customer quirks.
- Assignment rotation. Get team members with skills or activities in common to swap task assignments, customers they service etc at regular intervals so one knows (mostly) how the other one works.
Build capacity for an increase in workload
Let’s say you are planning to increase efforts in Activity A. Your team has Person 1 currently doing Activity A, but your company wants to double down on that work. You’d be in a good position to have 1 or more other people acquainted with Activity A.
Person 2, 3 or 4 doesn’t necessarily have to mirror the role of the original person responsible for Activity A. They could have a majorly different role but have the shared ability to do Activity A (I’ll show a diagram of the overlap later).
Then again, you could mirror Person 1’s role to an exact match if the others could serve different customers, markets etc. When a priority set of customers or markets need extra servicing with Activity A, you should be able to round-up extra help fast because of that Activity A redundancy.
Prepare multiple unique solutions to a problem
Analogous to a bake-off. Multiple members of your team with similar abilities are given the exact same problem to solve. Participants are not to work together but rather in parallel, each coming up with their own solution simultaneously.
This is different from the serial approach where you start the process again, but only after someone fails to produce results.
This approach works better for problems with a lesser defined pathway to completion rather than rote tasks with a defined path. Likewise, it’s better reserved for high-stakes situations versus less severe issues.
If you have 1 person doing the task, the outcome is 100% dependent on that person. This is your single point of failure. If you put 2 people on the task, you decrease your risk. Assign 5 people and even if 3 of them fail to produce, you still have 2 solutions to work with.
Redundancy considers variability in output. While all participants have similar skills and opportunity in this situation, their capability will vary. That’s dependent on their experience, personal values and motivation at the time of the activity.
In technical efforts, you can expect similar results with minor variation – still useful for amalgamating into a foolproof solution considering all the angles that all participants have taken. In creative efforts, you can expect greater variability – assuming the participants don’t collaborate with each other too extensively.
When is redundancy most beneficial?
Creating redundancy of skills and ability makes the most sense in these situations:
- Core activities of the team that drive business value
- High operational risk work i.e. complex and/or long timeline work
- “Mission-critical” tasks that must always be manned
Types of redundancy within the team
- Skill redundancy – a select skill that multiple team members share in common’
- Multi-skill redundancy – cherrypicked skills which are high-priority for the team
- Role redundancy – mirror-image of entire “job description” of a team member
How to plan and orchestrate redundancy
- For mission-critical tasks and activities, recommended having more than 2 people in a team with knowledge of that work.
- Suggest job rotation in that situation on a weekly, monthly basis
- Timing should depend on the cycle of the work
- Assign to peers at the same level ideally
- Otherwise, if one lower, turn it into a mini-apprentice modality – plays well into a “sponsoring leader” approach for the person of lower skill grade
Issues to watch out for
Internal turf wars
Turf wars can arise within the team if redundant roles/skills are not clearly delineated. This is especially the case if two or more people of the same role are located in the same physical location at the same time.
Complacency to act
Complacency can occur from having visible redundancy within the team. A conversation like this is possible, “I know I’ve dealt with that customer before. But I thought Bill would have done the job. After all, he’s chummier with them than I am!”
In more critical situations, it can mean life-or-death. Scott Snook’s book, Friendly Fire, recounts one such moment:
In 1994, during a peacekeeping mission, 19 crew members aboard an Airborne Warning and Control Systems (AWACS) aircraft in Iraq knew that two U.S. helicopters were flying through the so-called no-fly zone, but not one of them intervened when an F-15 pilot below them announced that he was going to shoot down two supposedly hostile helicopters.Quoted from Snooks, S. Friendly Fire (2000)
Diffusion of responsibility meant that everyone, and therefore no one, was responsible for doing the job. They all assumed somebody else would take care of it, most likely someone with better qualifications and proximity to the issue.
As it is with preventing turf wars, delineating responsibility to high specificity can cut the risk of complacency. Each team member must feel they’re accountable for very clear outcomes and eventualities.
Rodney Evans and Aaron Dignan of the Brave New Work podcast brought up an idea that might help with this. According to them, high performing teams tend to be clear about how they share responsibility. They have “explicit working agreements”.
3 key areas of teamwork can benefit from such agreements:
- Meeting dynamics: when do we meet, for what purpose, what format, who leads?
- Decision-making: when to seek advice, consensus, consent etc.
- Tools environment: how will we use tools and who has to look after each?
Teams that don’t have these labour under a lot of assumptions and illusions. The kind that can result in passing the buck (shifting accountability) and as a result, dropping the ball (failing to achieve the desired outcome).
- Redundancy (engineering) – Wikipedia. wikipedia.com. Accessed 2019-12-08
- Minda Zetlin (2014-04-28). Build redundancy into your team as well as your technology. enterprisersproject.com. Accessed 2019-12-10
- High Availability – What does Crossover mean in this context? – Stack Overflow
- Scott D. Sagan (March 2004). “Learning from Normal Accidents” (PDF). Organization & Environment. Archived from the original (PDF) on 2004-07-14.
- Aaron Dignan & Rodney Evans (2019-12-02). A way, for now, to try. Brave New Work Podcast. Accessed 2019-12-11