Posts in Playing Well With Others
Baseball cards and software testers
I remember sitting at a baseball game once with Rob Sabourin. It was a few weeks before he would be giving his talk on "What Baseball Taught Me about Metrics." He of course, was excited to talk about his thoughts on the subject, seeing as we were at a ball game and the material was fresh in his mind. He asked me, if software testers had baseball trading cards, what stats would be on the back of them?

I love that question. I think it's particularly telling of how an individual thinks about what stats make someone valuable as a tester. It's also challenging, because there are a lot of valuable things testers do that you can't easily put stats on.

Take two minutes and think about it. If you're particularly brave, respond to this post in a comment on what stats you might find interesting. If more than five people respond, I'll respond with my answer. If ten people respond, I'll even try to get the other three authors to respond with their answers. If twenty people respond, I'll email Rob Sab and try to get him to post a comment or two as well.
Put a post-it on your monitor for something you want to practice
When I was learning MCOASTER, I put this graphic on a post-in and put it on the bottom of my monitor. I then asked people to randomly quiz me on my test status throughout the day. People would walk up and say, "Hey Mike, can you give me a quick update on what you're testing?" I'd look at the post-it and quickly walk through each of the elements as I outlined my testing.

You can do this with any testing heuristic, technique, or idea you want to learn better. Find a way to sumarize it, write it down, and then ask people to help you use it. If you only put the post-it note there, you'll eventually stop seeing the post-it note. It will just blend it. You also need people willing to help you practice.
Try smaller lunch and learn topics
Most people are familiar with the concept of lunch and learns. They are also sometimes referred to as brown-bag sessions. It's where a group gets together over lunch and someone presents a topic to the group. I like lunch and learns a lot, they are a cheap way to get people thinking and talking about testing concepts.

Another alternative to having one person present for the entire period is to have everyone bring something small to the table. Give each person five to fifteen minutes (depending on the size of your team) where they present a test tool, project artifact, test technique, software development idea, or new application functionality.

This is a good way to shake things up. Sometimes it's difficult to get someone to want to present on a topic for an entire lunch session. Here the commitment is much lower.
Know when to turn off the phone
It's nice to be in constant communication with people you care about. It's nice to know what's going on. It's nice to stay on top of email. It's nice that modern technology puts all of this in your pocket.

It's not nice if it detracts from your human-to-human communication. For example, if you're a manager talking to one of your testers, turn off your phone. Don't pick it up if it rings, don't check it if you get a text message. Let the person you're talking with know that they are more important than the phone.

It's also not nice if it detracts from your down time. Sometimes you need to be available - especially if your in a leadership position or on-call. But when you don't need to be plugged in, un-plug. Constant connection can sap your energy over time. You don't always have to un-plug, but don't be afraid to do it when it makes sense.
Sometimes, you have to be willing to sweep the floors
When you're a member of a team, sometimes you need to be willing to do work that no one else wants to do in order for the team to be successful. You might not like this work. You might hate this work. But if it means the success of the team (and it doesn't compromise your moral or ethical principles), sometimes you need to suck it up and do it.

I try to model this when I can, doing work no one else wants to do. But it's not always easy to model. Sometimes I don't have the training needed, or the time, or some other reason. But if I can, I'll do it.

Need someone to pound out hours of uninteresting code? Need someone to do a large code review? Need someone to draw a bunch of diagrams for a client presentation tomorrow AM? Need your trash taken out? Need a computer (or a rack of computers) moved? Need notes taken? Need someone to get you coffee? Need someone to sweep the floor? I've done all of those (many of them multiple times) as a manager. It's part of being a manager.

As a team player, sometimes you need to step up and do the work you don't want to do. That doesn't mean all the time. It doesn't mean every day. But it does mean some days you won't go home as happy as you might have otherwise.