From Lone Wolf to Tribal Elder

There are periods in our lives where we as individuals tend to be loners. Not all of us, of course, but there are times where it is advantageous for us to make our way and see what we know on our own. We pit ourselves, our wits, and our energies and drives towards the various challenges that we face. We tend to learn a lot, often orders of magnitude beyond what we think that we can. At times, this state of affairs can be indefinite,  but at other times,  we can find ourselves either reaching the edge of what we know, or discovering that we have reached the level of our own incompetence (the famous “Peter Principle”). In these times, we might want to seek an opportunity with a team of software testers, and work to share knowledge and experiences.

I mention the above example because that is exactly what I went through about six months ago. For the better part of my career, I have been a Lone Tester, either by project or by company. As such, my opportunities to mentor others were limited to experiences outside of my company. I wasn’t mentoring other within my own organization, and possibly worse, I was not being given opportunities to be mentored. It was partly due to this combination of factors that I took a chance to move to an organization where there would be a test team with multiple testers (at the moment, our test team has four active software testers, one contractor who focuses primarily on automation and one college intern). In this environment, with the exception of my Director, I am the longest tenured tester in the group. Make no mistake, that does not mean I am the best tester, or even the most knowledgeable tester. It just means I’ve been in the game longer than most of my team.

Some people might think that they have to be experts in something to mentor others, or that they need to be the team lead or manager to be in the position to mentor others. This is false, and it is also detrimental to the health of the team. Everyone has a talent or specialty they bring to their team. It may be experience with operating systems and scripting. It may be deep database administration or design knowledge. It may be front end web programming chops. It may be Exploratory Testing skills. It may be aptitude with a broad range of test techniques. It may be a focus on mobile applications. It may be security or performance knowledge. Whatever it is, everyone has a strength. Leverage that strength, and be willing to cross train others on your team to learn and develop that strength.

I can hear some of you thinking to yourselves “but Michael, if I do that, then I will lose my value proposition in my organization”. Yes, I’m familiar with this argument, and yes, I’ve seen people actually operate like this. The attitude of “my knowledge is unique and precious, and therefore I am going to guard it” is very normal to our competitive human natures. It’s also detrimental to both our organizations and ourselves. When we hoard knowledge, or we protect our niche areas to all inquiry, we are in effect cutting off our nose to spite our face. Yes, willfully making ourselves into silos is a spiteful act. I’ve said it. Sure, we may be guarding and protecting a key component of our knowledge, but are we really adding a greater value to our team by doing that? I’d say no. In my own personal experience, my willingness to share from my knowledge, experiences, and mistakes helps me not just share information and learning with others on my team. It also helps me ensure that I really know what I think I know. Often, the process of mentoring others helps me see where I have holes in my own understanding.

Each member of our team comes from a slightly different place, and each member has slight different experience levels. I know a fair bit about Linux and command line interactions. Because of this, I’ve gravitated towards learning about and working with the virtual environments that we use to set up our development environments and our test stations. Other of my coworkers have familiarity with mobile application, as well as with automation frameworks, using Jenkins to parallelize tests, focusing on security aspects of our application, etc. None of us have everything in the above list to a super proficient level, but we are all proficient to advanced in at least one of them. By mentoring each other in our areas of expertise, we share the load, and we learn more in the process. Sharing our knowledge is not a zero sum game; very often we will learn more from what we do to mentor others than we would if we were just to do it ourselves and keep it to ourselves.

Beyond the technical, there is also a practical aspect of this. A team that consistently learns and develops off of each other can draw energy from the whole group of participants. One person’s enthusiasm for an aspect of what we do can help be a catalyst to help us blast off from where we are at and go much farther, or to get us out of ruts we may have put ourselves in. Instead of hoarding what we know, and being stagnant, our act of mentoring others helps to ensure that our knowledge and understanding do not grow stagnant. Teach your strengths, and encourage others to teach you in the areas where you want to improve. Ideally, find someone whose strength is in an area where you have a current weakness. Very often those make for the best arrangements.

Going from a loner to being a tribal elder may feel strange for some, but the point of being a tribal elder is that you have years of experience and wisdom to share. If that is the case, go and do so. As they say, good choices come from Wisdom, and wisdom comes from making possibly bad choices in the past and learning from them. We won’t be able to prevent people from repeating some of our mistakes, but we may be able to help them learn from, and thus prevent, repeating so many of them. Ultimately, that might prove to be a great outcome.