Five Lessons from the QA Trenches: Creating a Culture of Sharing

I’m sure you’ve heard the expression “sharing is caring.” Jokes aside, the idea couldn’t be truer, especially in the field of software. During the course of your career, though, you’re likely to work for more than one employer, meaning you will amass a wealth of knowledge only to walk out the door with said knowledge at some point. Worse, you often times leave with that knowledge locked away in your head… and nowhere else.

This problem became apparent to me a few months back, after I published a blog post about QA being a shared responsibility, titled QA is Everyone’s Job. I was fortunate enough to give a talk on that subject during an inspiring offsite engineering conference with 200 of my New Relic colleagues. Throughout our awesome vetting and preparation process, I got consistent feedback that what made the presentation work were insights from my previous QA jobs where we got it all wrong. The stories I told shared a common theme: the apparent lack of a culture of sharing.


A QA army of one

My first job out of school was with a fairly small development shop, where I was a QA army of one. Eager to make a name for myself, I dug in and spent three years creating an elaborate automated testing system. The test count numbered in the thousands—it took more than two days to run, but had a tremendous amount of coverage that saved our rears on several occasions. But one problem stood out: I did a horrible job of sharing information with my colleagues. I’d done nearly all of this work in isolation, in a so-called “silo.” In fact, I actually went out of my way to make sure that QA was not everyone’s job.

Lesson #1: If you silo yourself from the get go, you’ll have sealed your knowledge’s fate before ever leaving the building.

When my time with this group came to an abrupt end in the form of a layoff during the economic downturn, I was the only one who had in-depth knowledge of our testing system. No one else on the team knew how to kick off a test run, or what the testing process was when it came time for a release. I had thought that by keeping the “keys” to our system and process to myself I was simply taking pride in my work and responsibilities. In retrospect, that impulse was born from immaturity, foolishness, and insecurity.

At the time, I thought that getting laid off was the worst part of the scenario. I was wrong. The biggest kick in the gut was finding out that a just a few months after I was gone, the vast majority of my work had fallen into disrepair and disuse. I was furious that my former co-workers had tossed my work aside like yesterday’s trash! But as I had time to reflect, I slowly redirected that anger at myself. I had left my coworkers high and dry, with no documentation, no sharing of knowledge, and no chance to succeed.

Education is a two-way street

My next job started off great. As part of a much larger team, I was no longer a QA army of one. Our team was made up of experts representing all aspects of software development. Perhaps most important, the core of our development team fostered an excellent culture of sharing. Though people specialized in certain areas, very little was siloed in one person or team. I was confident history would not repeat itself!

Lesson #2: Lead by taking an active role in creating a culture of sharing.

But change, as we all know, is inevitable. For us, change came in the form of an acquisition, followed by a slow but steady exodus of talent. I began to notice a disturbing trend: the people were leaving happened to be the chief contributors to this culture of sharing. As people left the company, this small pool of individuals assumed their responsibilities and domain knowledge. As time went on, more and more information was becoming siloed amongst this ever-shrinking group.

When the time came for me too to pursue other opportunities, I realized that not only did I hold the keys to our testing systems, but by then I also held the keys to our build, deployment, and change management systems as well. I spent the last few weeks in daily meetings with what remained of the team, desperately attempting to pass on the knowledge I had inherited. Unfortunately, the ‘pool’ of those willing to learn had all but disappeared, and I was met with blank, uninterested faces.

Lesson #3: It’s one thing to put the information out there. Those on the receiving end must to be ready and willing to learn.

The here and now

When I arrived at New Relic, one of my first challenges was to investigate a testing tool that had been created by individuals no longer with the company. Much like the aftermath of my first job, this system had quickly fallen into disuse and disrepair. The majority of the tests were failing and no one knew where to begin. A tool designed to help qualify releases was actually serving as a roadblock to releasing software.

I thought to myself, “Huh… This seems familiar. I’ve been the direct cause of a situation like this before!” Long story short, I did my best to channel my inner MacGyver and with some investigation, a lot of trial and error, and a few late nights I was able to get it working again. Two years later it’s still in use by our team.

This story has a happy ending, but it’s another great example of the importance of sharing. After I succeeded in resurrecting this testing tool, taking notes as I tried this and tried that, I realized that:

Lesson #4: In many cases, a lot of person hours and frustration can been avoided with a page or two of text in a document or wiki.

Final lessons learned

Much of the onus for sharing information falls on the shoulders of the keepers of said knowledge. But others also are responsible for being willing and active participants in the exchange of information. If you know of information critical to your professional survival, it is on you to seek out the keepers of that knowledge. And you have to do this before they give their two-week’s notice.

Lesson #5: Leave nothing to chance— change often happens slowly, but can also occur in the blink of an eye.

Take a few minutes to think about your day-to-day activities and what, if anything, you’re considered the go-to-person for. Now imagine that you are gone and someone else needs to fill that role. Do they have the information they need? Do they even know where to look?

Now, pick someone else on your team and apply the process in reverse. If they were to disappear tomorrow and you had to fill the gap, what would you do? Where would you begin?

This isn’t always easy. Even if you think you are sharing enough, chances are you can do better. I’ll be the first to admit that I don’t always follow all my own lessons. But keep working at it—the worst feeling is the knowledge that you didn’t do enough.

Lonely Island image courtesy

Matt Sneeden is a QA Developer at New Relic. He supports the .NET Agent team, specializing in building continuous integration and automated testing systems. When not wired in, he can be found exploring the outdoors of southern Wisconsin. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!