Posts in Playing Well With Others
CoE's might need sales people too
Yesterday I read this article by Jill Konrath on 7 Sales Mistakes Guaranteed to Make Your New Service Fail. It reminded me on when I was working to build out a centralized testing group in a large organization. In many ways, I was the business developer for my team within the organization. We may have been a Center of Excellence (CoE), but we weren't really required to be used. We had to earn our business.

The tips in the article that resonated with me the most were:

Setting up meetings to update customers about the new product or service can lead to trouble. Arranging the meeting isn't the mistake—just its premise. If sales reps tell customers they're bringing information about the new product or service, that's exactly what customers expect the meeting to be about. Sellers then find it exceedingly difficult to switch into a questioning mode—an essential step for determining valid business and financial reasons for changing. Instead they're expected to talk, talk, talk—and boy, do they ever!


and

If salespeople don't have a clearly defined next step implanted in their brains prior to the call, they are doomed. Just sharing exciting new product information gets sellers nowhere. Unless they have a clearly defined objective before the call and are ready to offer logical next steps, they'll be left sitting by the phone waiting for it to ring.


We "sold" automation and performance testing "products" to project teams. Getting teams to use us, and getting them to pay for enhancements to the products we provided, was in every way a sales call. Good advice - read the entire article.
Staying out of testing ruts
I'm invoking the pirate heuristic today and stealing from David Christiansen. Dave wrote a great set of tips on how to recognize when you're testing might be in a rut. In the post he identifies the following test-fatigue-symptoms:

  • Randomly pounding the keyboard for data entry.

  • Not taking good notes.

  • Chasing esoteric bugs when you don’t have time.

  • Not bothering to isolate bugs.

  • An inability to think of any error scenarios to test.


Read his post for some tips on how he breaks out of a rut when he recognizes he's in one.

What ruts do you find you fall into? His "asdf" rut resonates with me, I know what one well...
Deliver difficult feedback
I recently had a couple people who work for me provide me with difficult feedback. Difficult for me to hear, and I'm sure it was difficult for them to say. If someone you work with needs feedback, even if it's difficult, be willing to provide it.

If you're not sure how to do that, I recommend starting with Crucial Conversations. It's the first step in becoming an Influencer, but it's also an important step in building the team you want to work in. You need to be willing and able to talk with your boss and peers about difficult topics.

Note, those two books are written by the same authors. I'm a fan of their work, and I've read "Crucial Conversations" around five times now. They've also written a book called Crucial Confrontations. I'm less of a fan of that book, but I only think that's because it seems like it's only a specific application of the general principles laid out in "Crucial Conversations."
Share articles, blog posts, and podcasts
One thing that happens at my current company that hasn't ever really happened in the past is that we share a lot of media. There is rarely a week where there isn't a flurry of emails forwarding an article, blog posts, or podcasts on tops related to the technologies we work with, programming or agile, or some other aspect of development. It's great. Not only do I get insight into what others are reading (and where they get their news and insights), but I also get to share topics that are important to me.

If you read something you think is profound (like all the content in this blog of course) or excites you (like a new tool or an idea from a podcast), pass it along to a group of your co-workers.
Stock prices and software testers
Similar to Friday's post on baseball cards, I have another interesting metric I think about. It's my stock price (also known is some circles as "street-cred"). It works like this, I think everyone on a team has a fluctuation stock-price. It represents how attractive they are to work with at any given time, encompassing both their perceived productivity and personability. If someone severely flubs up a project or is simply a jerk to work with, their stock price goes down. If they are particularly strong at a skill in high demand, their price goes up.

Think of it like this, if five managers were building teams from a pool 100 candidates, and they each had fixed and equal "budgets" and could choose team members from the pool, what would they be willing to pay for any given candidate? The price of any given member would reflect the "future earnings" (or project value) of the person being brought onto the team.

Editorial comment: It's a thought experiment... It's not perfect, roll with it. I'm not saying this would be a good idea for a company, I am saying it's a neat thought experiment for the following reason.

If you're a software tester (and I have to assume you are if you're reading QuickTestingTips), think about what might affect your stock price. What are the factors that you think generate "street-cred" and make you a more valuable team player (and thus a higher-value team commodity)? If you had to issue quarterly and annual (testing) reports, what would be in them? How would you position yourself so you could demand a higher price?

Similar to the Friday post, if five people respond, I'll post my answer. The more people respond past that, I'll try to get the other authors on this blog to post their thoughts as well.