How to Make an Impact on Your Testing Team: An Interview with Michael Sowers

Josiah: Today, I'm joined here with Michael Sowers of Software Quality Engineering. Michael, I appreciate your time.

Michael: Good morning, Josiah. It's great to be here.

Josiah: If we could, let's start if off with a brief description of your extensive experience in the industry.

Michael: Yeah, sure. I've been very blessed, I think, with an extremely rewarding career, thanks to a lot of mentors and coaches along the way and, of course, several mistakes, I'm sure. I guess we call those learning opportunities.

I began my career as a co-op student, actually, in the Midwest at NCR Corporation right out of school. Then from there, joined Digital Equipment Corporation up in the Northeast as their Director of Testing and also led a configuration management team there for the VMS operating system. Then I went to a company called Cadence Design Systems, which produces electronic design automation software, and was their vice president of QA and test for a global team that was actually based in India and other places around the world.

After building that experience, I thought I might know enough to share my wisdom with other people and went off to do some consulting for six years with a small team. We did what was called test transformation engagements. We had the privilege of working with Fortune 500 companies in all parts of the world, transforming their software engineering and test methodologies, tools, installing teams, and so forth.

From that, I decided to get off the road and join Fidelity Investments where I had the opportunity to lead a team of about 400 people, again globally, software test, QA, configuration management, those types of services that support software engineering. Then left there to try my hand at CIO, so I sat in the CIO seat over in Tampa for a forensic engineering firm for roughly four years. Now I'm here at SQE in that same role.

Josiah: A lot of your talk that will be at the upcoming STARWEST presentation is about speaking like a test manager. What do you see as the first and the often most common mistakes someone makes when trying to communicate with a higher-up in a business?

Michael: Yeah. Probably for more years than I care to admit, Josiah, I actually thought that those above me were interested in the details of my job and actually what my team did. I don't mean that negatively, but it did take me awhile to understand that senior execs held different perspectives and were accountable for many different goals, of course, than what I was. Looking back now, that seems obvious, but certainly it didn't seem so obvious. I guess I was just a slow learner.

Back to your question, what's that first and most common mistake. I think it's not framing your message from the receiver's point of view. I wanted to tell my management all about those bugs that we had found, all about the test that we had automated, all the tools that we had purchased and installed, all the code we had cleansed or migrated, those types of things. But senior managers weren't interested in that. They were interested in contributions to the business, which normally translate to how are you making things faster, better, and cheaper for me or for the customer.

Josiah: Now in order to kind of change your mindset on that, you often have to change your communication style, which is something you're going to be talking about during the discussion.

Michael: Mm-hmm (affirmative).

Josiah: Do you think it's easy to change your communication style without changing the actual content of your message? Or do you think you have to kind of restructure the content in order to get your point across to a higher-up?

Michael: Yeah, that's a great question. In my experience, and it took me awhile to learn this, there's really two parts to communication. There is the content, what you want to say, and then there is the style. I think you've got to work most of those, both of those at once, and they've both got to be planned for important communications, practiced, and then be well executed. Style is really about how you communicate, and content is about what you communicate. Also remember that most of us have learned along the way that one-third of our communication is non-verbal. We need to look at people; we want to watch our body language, our tone of voice. I found out oftentimes the hard way that communicating is more effective when both of these dimensions are aligned and then put in the context of the listener's mental models, the goals, the challenges, the accountability, the language of the receiver.

Josiah: What do you see as the best method for gaining respect from a test manager, from a higher-up without coming off as too bull-headed or unreasonable? Being able to communicate with someone at a higher level, you need to be able to gain their respect, gain their trust, but I can see that being difficult without coming off too strong. How do you do that with … being able to gain respect without coming off too strong?

Michael: I think that's a tough job for probably any of us in any role in the software engineering profession. Certainly in the QA and test role, whether you're an individual contributor, a team leader, a senior manager, a vice president, we've all got this thing called the sphere of influence. What we say does matter, and then when and how we say it and the opportunities we seize or miss do have an impact on the way others perceive us. Some say that's unfair, but I think we all do it. In the QA and test profession, we're often accountable for what I say is telling someone their baby is ugly with a smile on your face.

Further, even if it may not be written in our job description anywhere, we often are expected to make improvements, that is, be change agents in the software engineering life cycle. Then finally, we're called to be an objective voice; does it work, doesn't work, what are the risks, is it ready to release. That second pair of eyes for validation. That's quite a lot to think about beyond the technical aspects of our job.

I think the best method for gaining respect is simply building relationships. If real estate is about location, location, location, then in my experience gaining respect and credibility and having a rapport with either one individual or a team is all about relationship, relationship, relationship. It's much easier to have a conversation with someone, with a developer, about an issue or a bug if you've had lunch with them, if you've had coffee with them, if you played basketball with them, whatever.

Secondly, I think speak to facts. We don't have to speak with emotion; we just lay the facts on the table. Then third, answer the what's-in-it-for-me question. Because people always want to know, okay, if I respond in this way or I do this or that, what's the benefit for me. Then finally, I think the best way to make sure you've got that credibility and respect is not to go it alone. As a QA and test person, I had to learn that I shouldn't be the gatekeeper. I should input data and bring information to the table about release decisions, but I should involve others in that decision as well, the product owner, developers, customers, and so forth.

Josiah: I think you kind of answered a lot of my next question with what you said there, because I wanted to kind of know, do you believe that facts on their face are enough to kind of convey your message to the test manager? I think some people would argue facts are important and facts are where to make steps, but you also need to do the what's-in-it-for-me, what's going to help the business. Is that correct?

Michael: Yeah, absolutely. Facts are important; they support the content of what you're trying to say, but I'd use caution in the approach of trying to prove your point, if you will. Instead, step back and ask yourself what's your desired outcome or outcomes for this particular interaction, this particular communication, whether that be a one-on-one situation, a team, or a larger audience. Then think about how those outcomes are going to be seen by the one or more people that you're speaking with. What are their mental models? What's going through their head? What are some of their struggles? What are they dealing with? That whole answering of what's-in-it-for-me question, as you said.

Josiah: I was a communication major. I recently graduated. I think what I realized the kind of deeper I got into the program was I was never really taught proper business communication, proper workforce communication, through elementary school, through high school, and I really only got some of those skills toward the tail end of college. Do you think students could see benefits when entering the workforce if proper business communication were introduced at an early age and kind of know what they're getting into right away?

Michael: Yeah, absolutely. I think you're right on, right on mark there. You probably learned a lot more about communications and so forth than I did when I was in school. That was really never mentioned; it was all about more the technical skills and your abilities and your knowledge and so forth. The sooner somebody learns the fundamentals, the more opportunity they have to apply and then learn them. But, of course, it's never one size fits all. I've learned that you do have to plan your communication; you've got to practice that communication; and then you've got to execute on your message. It's all about plan, practice, and execute. I'm talking about important communications where you're getting in front of a senior manager, a boss, an executive, someone or more than one person that you need to get decision from, you need to change their opinion. You want to think through those things.

In my experience, where message delivery failure occurs is in that plan and practice area. I might have the fundamental skills, but what tends to happen along the way is as I develop my technical skills and ability in whatever role I'm in, in this case software engineer, tester, whatever, I believe I can rely on those technical skills to also then be a good communicator. Of course people would want to listen to what I had to say. Of course they would be receptive to my message because I'm a technical expert. I think to your point, being a technical expert doesn't necessarily make you a great communicator unless you plan it, practice it, and think about it from your audience's perspective.

Josiah: Absolutely. I really appreciate your time, Michael. I'm looking forward to the discussion at STARWEST. Thank you. Thanks again.

Michael: Okay, Josiah. Have a great day. Thank you.

Josiah: You too.

Mike Sowers has more than twenty-five years of practical experience as a global quality and test leader of internationally distributed test teams across multiple industries. Mike is a senior consultant, skilled in working with both large and small organizations to improve their software development, testing, and delivery approaches. He has worked with companies including Fidelity Investments, PepsiCo, FedEx, Southwest Airlines, Wells Fargo, ADP, and Lockheed to improve software quality, reduce time to market, and decrease costs. With his passion for helping teams deliver software faster, better, and cheaper, Mike has mentored and coached senior software leaders, small teams, and direct contributors worldwide.