This is a guest post by Matthew Heusser.
Testers destroy things. We tear things apart.
Sure, every now and again, some expert will point out that the thing was already broken, we just discovered it. That’s fine, such as it goes. Still, I would hold that on some level, the tester’s attitude is destructive.
The project manager says “we are going to go live today at 5PM”, and the tester replies “oh you think so, do you?” then gathers information to invalidate that assumption.
Sometimes, we don’t have many friends. In fact, often we make enemies. By getting the deliverable to wait a day or a week, we spoil one person’s annual review and another’s bonus.
Unless we are really careful, that won’t develop influence, it will destroy it.
The “Team Player” Argument
I’ve never been a fan of being a “team player” as a tester. The term itself implies a sacrifice of personal achievement for the benefit of the team. In business, it might mean working longer hours for no clear reward. In testing, it could mean not finding bugs, or not making a fuss, in order to hit a deadline. While that might make you some friends, I suspect those would be fair-weather friends — and, again, that is sort of the opposite of influence. We want, or at least I’d hope we want, influence in order to get to some better result. “Go along to get along” reinforces the wrong result.
Yet that is my first piece of advice. In order to develop influence, help other people accomplish their goals. Before you build your coalition to get your change to happen, help them accomplish what they need. Invest just a few minutes in finding out what other people want. Sometimes, they just want someone to listen. Matt Barcomb is one of my most successful and respected colleagues. He came from roughly the same place as I did, with a similar background to any of my peers. Indeed, Matt enlisted in the military to get money for college, starting out disadvantaged compared to friends who jumped into college that mom and dad paid for. Yet Matt’s career advancement has been swift and sure. Yes, Matt has insights. Yes, Matt is smart. The single biggest distinguishing feature for Matt is just that he listens to people. I know when I have a challenge, he will figure out a time to take my call. Deep down I know that he takes a lot of calls. A great number of people want his time. He cannot support all of us. Knowing that he will take my call is in itself a bit of a compliment.
Who do you support? That’s less of a rhetorical question and more of an actual one. Think about how you support at work. Who leans on you. Or think about the people at work. Do you even know what they need?
If you don’t know what they need, how can you expect them to support you?
This is being a team player in the best sense of the term.
Consistency: Another Key To Trust
A few years ago I was mentoring a tester who had just become a test lead. He was working on a product that spanned three continents and at least three companies. His team was the integration team. He pointed out that nothing worked and the specifications were inconsistent and written in different languages. What was going to happen?
I told him “that’s easy. The software is going to be late and it is going to be buggy.”
Of course, on some level, he already knew this. He telegraphed the information to me. What he was not ready to do was to admit it. I helped him face it, predicted the future, and I was right.
I’ve probably written tens or hundreds of thousands of words about how predicting the future is not possible. Sometimes though, the information is already out there. Predict the future enough times in a row, be right about it, and people will start to listen to you.
Deliver Value With Your Information
A few years ago at a conference, some testers were sitting around talking about the conceptual limits of testing. “We cannot say this works”, was the argument. “Instead, we can say this did not demonstrate any flaws, at this specific point in time, with this specific build, under these specific conditions.”
Great.
While incredibly precise, I have to wonder how that goes over in a job interview. Think about that as an answer to the question “Is the software ready yet?”
Most of the time, we are not interviewed. People are simply stuck with us.
Take a step back, and frame your answers so they solve the problem of the person asking. Don’t create more problems for them.
Today I offered a few musings about building influence; it feels like I just scratched the surface. This may have to become a series, with examples. Would you like it if I did that?
Matthew Heusser is the Managing Director of Excelon Development, with expertise in project management, development, writing, and systems improvement. And yes, he does software testing too.
