Recently, I was having coffee with a friend of mine who has been a successful VP at a mid-size tech company. Let’s call her Carly. Carly had been at the company for over ten years and built a great team that executed well and took great care of customers. Carly’s compensation reflected her success.
However, some challenges still weighed heavily. The Covid pandemic did not impact her company severely as they operated remotely, but it challenged their customers, and her team empathized deeply with them. Now, AI introduced a major shift in how its products work, and clients struggled in different ways to figure out how AI might change the way they work.
I sensed a fatigue in Carly’s stories. The competition, the customer needs, the changing business environment, and internal demands of the company — it all wore on Carly. We both spoke briefly of retirement and what that might be like. Then I thought about this marvelous team Carly had built. They depend on her to guide her key division of the company. What if Carly did get ready to leave? How could she prepare them?
Can we independ as much as we depend on someone?
I’ve had the good fortune to work with and even build great teams and organizations. Some of our first steps were to figure out where skills overlapped and where we could help each other fill gaps. We depended on each other to fill those gaps.
But no team lasts forever. People do come and go. Companies shift priorities and reorganize. So it becomes highly likely that someone on your team who has unique skills will someday be off the team. You can no longer depend on them.
So how can you independ on them?
Yes, I realize “independ” is not a real word in the English language (my spell checker still yells at me), but maybe it should be. Perhaps we need to think about not only how the team learns to work well together, but also how it learns to function without some of its team members. How can we keep the work moving forward?
Three Human Ways to Build More Independence
From my days with agile software development, there are two quick answers. When Extreme Programming first emerged, the practice of pairing became a staple. You have two people at the same computer screen with one person “driving” the keyboard and the other navigating the solution. Occasionally, the pair swaps places. It sounds inefficient to have two people at one keyboard, but it actually saves time by sharing a more complete understanding of the problem, how the code is produced, and any peculiarities. The pair learns and solves problems together. Pairing makes it difficult to have silos of knowledge as you are always pairing with someone else on the team.
I’ve found this practice so valuable that I’ve pair-written both my books. My co-authors and I did not divide up chapters. We actually worked together on every line on every chapter. This allowed us to have deeper discussions about our audience, what knowledge and questions they may have, and explore together on different ways of explaining our concepts.
If pairing with one team member at a time can improve understanding and quality, could you pair with the entire team? This practice became known as mob programming or “mobbing” and is referred to as “ensemble programming.” You literally have the entire team watch a big screen with the code while one team member “drives” the keyboard. Similar to pairing, you occasionally swap drivers. But through this mobbing approach, everyone gains an understanding of more complex software, the different types of problems the software solves, and how to properly deploy the software.
The best way for a non-technical person to understand this practice is by comparing it to the Amish practice of barn-raising. Everyone gathers to build a single structure, everyone sees the progress of the whole, and anyone moves in to drive progress where they are, with the help and advice of others.

The sabbatical represents the third practice that can help build independence within the team. Some companies and remote organizations offer one to three month sabbaticals for staff every five years of their tenure. Most people think the sabbatical just helps the individual reset and avoid burnout by completely unplugging from the organization. But independence grows through the sabbatical as the team adapts to the extended absence of the employee. You might be surprised by some companies that offer sabbaticals.
Pairing, ensemble work, and sabbaticals represent just three practices to build independence in your teams. Identifying the dependencies and finding ways to reduce them become the key motivation.
What Will You Leave Behind?
So, who is dependent on you? Who are you dependent on?
What are some first steps to reduce those dependencies?
Taking a longer-term view, how do you have your leadership remembered for practices established that allowed anyone to depart the team with minimal disruption? Even if it’s you moving on.
Stay human my friends,
Mark
