Janus Part 1: Looking Back 2011

One of the benefits of taking four years of Latin is that you pick up all kinds of interesting things that many other folks may miss.  Then again, an awful lot of people don't worry too much that "i.e." is an abbreviation of "id est" or, "that is".  Just like "etc." is an abbreviation of "et cetera"  - even though they may even SAY et cetera, I wonder how many know what it means?  I'm mean enough to not say here, and say "look it up" - unless you remember your Latin as well.

Janus, for whom the month of January is named, looked both forward and back.  That is a bit of what I want to do with this post and the next.  The post I wrote last night was a precursor to these couple of posts, partly because the things described yesterday laid the foundation for this past year and the year to come.

What I wrote January 1, 2011:

The Road Ahead...

The interesting thing is I've been thinking about the future. Well, not THE future, but what lay ahead for me professionally and how that may impact the family. It would seem there are several items that are possibilities for the coming year. One path would be to look for new work opportunities, either as a contract/consultant or as a full time, permanent employee. Yeah, as if "permanent" means much.

A bunch of folks commented privately, "Dude, pretty gutsy to say you'll be looking for work when you're still employed."  What I could not say then, was that in December, the entire staff of the company I worked for was told, in essence, that the company leadership was negotiating the sale of the company.  We did not know to which other company, nor what the terms would be.  Many of us speculated that the only reason we were told at that point, was because they needed us to sign releases of our stock options in case the sale closed before the end of the year. 

It was not a bold move to make such a prediction - I simply knew there was a likelihood that I'd be looking for work. When one company assimilates, well, acquires, another company, "long term employment" prospects for the staff of the acquired company are not terribly high.

As it was, I was not let go.  I was retained.  One colleague resigned after accepting a new position.  His last day, we had a farewell luncheon for him.  By the end of the next day, myself and another tester were all that remained of  our team.  One other person, a developer, had been transferred from the development staff to testing.  although others on the team

We are continuing, and moving forward.

Community

Another option is to become more involved in the testing community. Actually, I started working on that as well in 2010. What I mean is that reading blogs other folks write is a good way to learn what they're thinking is. Reading and participating in on-line forums is another way to both learn and become involved. Well, doing that as much as I can right now.

Of course, more actively engaging in both of these types of activities is on my list of things to do this coming year. Ya know, the funny thing is, the more I talk with folks about things I learn and have learned, the more I learn myself.

This continues.  I've been writing.  Alot.  STP Magazine and TechTarget's SearchSoftwareQuality both have run articles I've written.   my  more in my blog, and more engaged in forums than ever before. 

I expect this to continue and grow in the coming year.  That would be way cool.
 

Local Testing Groups

Another thing, the local testing group, GR Testers, has been going in fits and starts for a while. Meetings have been sparse of late. The most recent one, December, was kind of fun. There were a bunch of us sitting around a table, lots of wings, good beer and folks talking about testing. Good way to spend an evening. There's another meeting coming up Monday, 3 January. It makes it the first time in quite a while that there were back to back monthly meetings. Normally, they are officially held every other month. It seems that as more people are showing an interest, the meeting frequency will pick up.

I wonder how many other local testing groups are out there that have a meeting schedule based on "whenever" instead of "We meet at this time, and here are the next couple of topics we're focusing on at these meetings..." I believe that the more people know about local groups, the more they are invited to participate and the more information that is available about them, the more active and the stonger the community there is.

I think that pretty well sums up what I'm looking to do with the local group. I believe that getting more people involved and talking about testing is vital to improving not only our individual tradecraft, but the abilities of the local community. Sharing well reasoned ideas can do nothing but good, presuming all are allowed to learn and ask questions

The GR Testers, the local testing group, is up and running strong. The group has met monthly since that January post.  I've made it to most of the meetings. The ones I missed, I was out of town, usually at a conference. Cool.

Personal Development

Now, I realize that any of the above activities can lead to improving any individual participating. What I mean here is something a bit more. I had been signed up for the BBST Foundations course offered by the Association for Software Testing for a session in in the fall of 2010. Things happened and that session was cancelled. I could not take the session offered as an alternative.

The GOOD news, for me, is I am signed up to take the Foundations course this spring. YEAH! I am really looking forward to this. Everyone I know who took the course raves about it. Big-time excited.

I've continued reading blogs and articles and books and talking with people and... everything else. My goal is to continue learning and to continue to share what I learn.

For conferences, I'll be attending and presenting at STPCon in March in Nashville. I bought myself a birthday present and renewed my AST membership in October. If I can work it out, I'll be attending CAST in August in Seatle.

This happened beyond my wildest dreams.  I took and passed the BBST Foundations course.  Then, even though the schedule did not permit me to take the Bug Advocacy course - that is on the list for next year for me.  I also took the Instructor's Course from AST.  We'll see how the schedule works out this coming year.

Conferences.  I presented at STPCon (Spring) in Nashville.  I gave a joint presentation with my (then) boss, Kristin Dukic, as well as a presentation and lightning talk on my own.  I then was flattered, and honored, to attend and participate in CAST.   With Matt Heusser, I helped organize the Emerging Topics track, where a self-organized group selected topics submitted via a wiki - then ran for 20 minutes, every 25 minutes.  It was astounding.

After CAST, I had the opportunity to present at STPCon Fall in Dallas.  Matt Heusser and I did a day-long workshop (excerpts are on the Software Test Professionals site, under Podcasts) - then a joint track session on "Complete Testing".  THAT was a lot of fun. I also presented a track session on my own as well as a lightning talk.  Matt just gave a keynote.

Then since I was not busy enough, I presented at TesTrek in Toronto in November. 

Whew.

Other Stuff

Scads of people have encouraged me this year.  Among them, Matt Heusser, who put me in contact with the folks at TechTarget, and made the case that he could not do Emerging Topics at CAST on his own - which is how I got in.  Cool, heh?  THEN - Matt had so much fun with that, he asked if I'd be interested in doing a joint workshop in Dallas.  Oh yeah.  The interesting thing is that he's really a nice guy - as the folks who know him will attest. 

Also - Fiona Charles is supportive and encouraging.  She is really an amazing person who is willing to offer suggestions and ideas on how to improve articles, presentations, whatever.  She also is way cool.  She was one of the very first people that I consider a "Name" in testing, to ask for comments on a paper - the list me in the acknowledgements.  Humbling. 

Catherine Powell whom I met in person at STPCon in Nashville always has encouragement and good suggestions.  Michael Larson is a great guy.  He's got a great outlook on life and testing.  His blog is inspiring.  Doug Hoffman was the Head Instructor for the BBST Foundations course.  What a smart guy.  Nice as the day is long.  We had several very nice chats both at CAST or at STPCon Fall.  If you get a chance to see him present - DO.  Cem Kaner - yes DOCTOR Kaner - the drive behind the BBST Courses.  An ongoing inspiration.

There are more - Michael Bolton, Lynn McKee, Griffin Jones, Nancy Kelln, and many more.  These are the people I look to for inspiration and mental reinvigoration.

And of course, my lady-wife, Connie. 

I do not know what the future will bring.  I will discuss what I hope for the future in the next post. 

Rising From the Ashes or Finding Motivation in Disaster

This has been an interesting year.  There have been many fantastic things happen this year that at times it seemed like I was an observer, and not the one participating.  I've presented at more conferences this year than I attended any year before this.  People write emails asking questions, looking for insight or help with a sticky problem, as if I'm an expert. 

I've written before about not feeling like an expert.  This is not about that. 

While preparing for STPCon this past October I had an interesting in a couple of thoughts.  While working on the presentation, and a couple of papers, I mentioned one of these thoughts to a fellow member of the GR Testers group.  We chatted (cyberly) for a moment on how failure can be a great motivator.  We talked about people who had overcome problems and adversity to rise to great things.

Of course, there are also many examples of people who break under adversity.

I don't know what the differences are in those scenarios.  I don't know why some people crumble, others recover and come back to where they were and others rise to greater success than they have ever known.  The last group, to me, resembles space capsules, like the old Apollo capsules, that would whip around the moon to accelerate even faster than they were going.  Yeah, in Star Trek Kirk did the same thing with the Enterprise around the Sun.  Cool, no?

The second group, I kind of think of as being a bit like a rubber ball.  Not a fancy "Super Ball" that used to be sold with the assurance that it would bounce higher than where it was dropped from (and rarely did as far as I know) but a plain bouncing ball.  Comes back to where it was, but somehow not quite the same.

The first group, like I said.  I don't know why people fail to recover.  The just don't for a variety of reasons. 

Me.  Hah.  I was moving up.  I had left one company where I was simply unhappy, and joined another company as a Test Lead.  There were "issues" there.  I was hired to improve testing and change the way testing was being done.  Well, things were not working out.  I had a series of "those meetings" and the last one was handing me a package and me walking out the door.  (I'll be happy to give more details over adult beverages sometime, if you really want to know.)

So, I went home, popped in a video, cracked an adult beverage and said "What happens next?" 

Short term, I knew what had to happen - I needed to get ready to teach drum lessons that evening.  So, I had a single beer, watched a movie, fried some bacon and eggs and felt sorry for myself for 3 hours.  Then I made a strong pot of tea because I had work to do. 

I made a list of what I was good at and what I was not good at (no PC here, not right then.)  I went through the list of what I was good at that and highlighted those I liked to do and those I wanted to get better at doing. 

I then went through the list of what I was not good at. I split that list into "so what?", "consider improving" and "fix it".  I then considered a list of things I had read about and had done very little with or knew very little about.  I also made a list of things I knew nothing about, but I'd seen mentioned in articles and blog posts and said "this might be worth looking into." 

I then went on and read what I could, learned what I could and did some serious soul-searching on what I really wanted to do.  I then looked at how I would fix the stuff I really needed to fix.  This was hard - really, really hard.

This led me to the next step - Updating the resume, looking at what I wanted to do and where I wanted to do it.  I knew that (at the time) West Michigan was not a hot-bed for top-flite testing jobs, project management jobs and my development experience was not in technology that was in demand.  On top of that, the economy was beginning its downward slide.  So, I figured it would be a good likelihood that I would need to relocate. 

I looked and I looked... and I looked some more.  One month, I applied to 158 jobs. All over the US, Scotland, Ireland and Australia.

I learned a lot.  I've been applying those lessons ever since.

First - Be involved.  Online, locally, within the company, within the team.  Look for ways to learn and improve.  If someone looks for advice, guidance or a sympathetic ear - do what you can.  If something sounds familiar to a situation you were in, talk with them about your experience.

Second - Share.  Now, in some ways, this is similar to the first lesson.  Write.  Blogs, forum posts, responses to posts or online articles.

Third - Learn.  Keep learning, keep reading, keep thinking.

Four - Dare.

Five - Repeat.

Four years ago, the foundations for these really, really simple ideas were where I started.  I landed a job after a stack of interviews.  Some I knew would not be a good fit.  Others, well, they decided it would not fit.  I was ok with that.  When I landed the gig I landed, I talked with people. I learned.  I learned their applications, their methods and their personalities.  I learned how they worked and did things. 

I shared ideas and experiences. I contributed when I could and asked questions when I did not understand. 

Then people began asking me questions - How can we learn more about... Have you ever run into...

As a result of one series of these conversations, I landed at TesTrek in Toronto, where I met Fiona Charles and Michael Bolton in person, for the first time.  I also met a whole slew of people I had never met before, Nancy Kelln, Lynn McKee and slew of other bright folks. 

That week in Toronto resulted in me getting more involved, helping revitalize/reinvigorate the GR Testers, then scrap my drumming blog and move to writing on testing.  That helped with presenting at conferences... and that led to, well, this most astounding year.

Where did this come from?  Getting fired.

You don't need to get fired/sacked/down-sized/happy-sized/whatever to do the same.  If you want to grow, then do it.  If you want to get involved, do it.

The fact is, doing these things may not make you a leader or a superstar or being called an expert.  But, if the world comes tumbling down around you, if you have been doing these things, others can step up and help.  If you have established connections and a reliable cadre of people, they can help just as you can help them.

On Patterns and Blinking and Puzzles and Expectation

Our family has a lot of traditions around the winter holidays, Christmas and New Year.  One tradition is working on a massive 1,000+ piece jigsaw puzzle.  We see it as beneficial in many ways.  When the kids or grandkids are around, for them to participate ("become engaged") this thing that we are doing, they need to slow down.  I've yet to take any pleasure from assembling a puzzle that can be whipped through in an hour or two.

Our puzzles tend to take a week or more to be completed.  We'll start them one evening, then each day tinker a bit as each person has a few moments.  In the evening, we try and set aside 30 or 40 minutes to work on the puzzle together.  We've found it a great extension of "dinner table conversation" where we get caught up with each others' day. 

Oh, we both like doing puzzles too, which is perhaps the biggest reason why we do them.

So, this year's puzzle was a photograph of a Scottish castle, no I don't know which one, with hills and mountains and things in the background, a bit of water near the castle (hard to tell if it is a river or a loch or merely a fair sized pond.)  Like a lot of the better, or harder, puzzles, there were many bits that, well, looked a lot like other bits. 

In sorting out which bits are which, you need to look for subtle differences - small changes or variances in the overall image.  So, this last week, I had a portion that I was sure were part of the castle's battlements - the tops of the walls or towers.  Then I noticed another piece - JUST like the one I had in my hand. but a little different.  There was a small line in the piece I had that was not in this new piece.

I blinked.  Literally.

The portion I was working on was indeed part of the battlements - but the reflection of the battlements in the water - not the actual "top of the wall" stuff.  I was reminded of a defect I had spent time trying to track down on a recent project. 

I had a set of expected results and behavior, my "oracles" - and the results - what I was actually seeing, were really really similar, but not quite what I was expecting.  It looked right, but something did not feel right.  What I was expecting, based on the described behaviors and expected results, was generally what I was seeing. But something did not feel right.

It was kind of like the puzzle pieces.  One looked like what I expected it to look like.  The other was, well, different. 

That got me thinking about other things. 

How many times are we certain that what we expect is really what we should expect?  Is it not possible that the expectations are the "bugs"?  What is it that makes the "expected results" "right"?  Even when you are the one who created the "expected" results, how well do you really understand the software?  Do you have a certain understanding as to what the changes will result in? 

In my case, my "expected results" were what was at fault - both in the puzzle and the testing. 

Once I realized my mistake in the testing, it became much easier to move forward.  I will never know about the puzzle, I'm afraid.  The orange tomcat who lives in the house with us decided that he had enough of us assembling the puzzle.

I believe, but am not certain, that we found all the pieces after he scattered them from the table.

Should we try and put that puzzle together in the future, I expect we'll find out about any missing pieces.

Coaching and Learning and Opportunity to do Both

My last post was fairly short, well, for me anyway.  This one will be, too.  No more rambling oddities that may, or may not, have anything to do with testing.  Just kind of too the point. 

My last post was on the Call for Participation being open for CAST 2012.  It turns out that the weekend before CAST,  July 14 and 15, there is another learning opportunity - Test Coach Camp.  I'm pretty excited about this. 

Test Coach Camp will be held at the same hotel where CAST will be held. 

Matt Heusser wrote about it here.  The official AST release and Call for Participation can be found here.

These folks said it better than I can. 

If you are interesting in helping testers do their testing better, which is what Test Coaching is all about, right?  Then I suggest you dive in to this.

Its going to be good. 

CAST 2012, The Thinking Tester - Do You Know the Way to San Jose?

This may well be the shortest blog post I've published in some time.  There may be some rambling, but less than what I normally have.  Don't look for a deep, thought-provoking idea buried in an apparently pointless story.  Its not there.

So, here's the point.  If you are a Thinking Tester then you need to know about CAST 2012.  The Conference for the Association for Software Testing is scheduled for July 16 through 18 in San Jose, California. 

The Call For Participation is up (here).  There are three basic types of presentations:

1. Interactive Workshops (140 minutes);
2. Regular Track Sessions (70 minutes with at least 25 minutes for discussion);
3. Emerging Topics (20 minutes with at least 5 minutes for discussion);

The deadline for Regular Tracks and  Workshops is January 16. 

The information you need to know about submitting proposals is on the website at the link above. 

If you are a Thinking Tester, I encourage you to consider attending CAST.  If you are interested in telling people about your ideas, I encourage you to consider submitting a proposal.

On Improvement, Or Teams and Process

I sometimes find it funny.  I mean writing a blog and posting ideas and getting comments or seeing who agrees or disagrees via twitter and other "networking" sites.

My last post, on team building, had a reasonable number of hits from unique locations, garnered a few tweets/re-tweets and one public comment. I also got a couple of emails from people I know that essentially said (paraphrasing) "We need to assign people to jobs they want to do? What if we end up with three people on one function and functions with no one assigned to them?  That's crazy! You can't operate that way!"

I kind of blinked and thought to myself, "Is that what I said?"  So I reread that post and thought about it.  I can see where someone might take that away as my point.  And still, I don't really think that was what I said.

Consider this.

When talking about process improvement, particularly test process improvement, I say flat out that no cookie-cutter model will work in every shop and then will rarely work for every project in the same shop.  To be able for a team to test effectively, someone must have a decent understanding of what the individuals on the team are capable of doing, what they are good at and how well they work together with other individuals on the team.

When you have some idea about the individuals, and you can look at the overall team's work (essentially looking at what the team as a whole is good at) then you can look for ways to optimize the strengths.  If you can off-set weaknesses with strengths and make the areas of less-than-optimal performance a little closer to where you'd like them to be, you can free more time and resouces (like money and training/reading material, not people) to grow your whole team's capabilities.

Pairing testers where one is stronger in certain areas than another and allowing them to learn and develop skills while doing them, is one way to spread the workload and allow testers to experiment with mentoring other testers.  It can also help develop a closer sense of teamwork and encourage people to turn to other testers for help, if they are not doing that already.

I have found no way to do those things without getting to know what the team members like to do, want to do and are good at doing. 

I know we can't always get the fun tasks - the ones we really like doing.  We can, however, learn about other things, or maybe find ways to improve and get better at the un-fun tasks.  I know for me, some of the things I really find un-fun are the tasks I feel less than comfortable with.  Yet as I learn more, those un-fun, scary, frightening things, the ones where I am an absolute novice at, are also the ones that as I learn more, and become better at, become more fun than un-fun.

I think that is the key right there.  If we want to get better, sometimes we need to work on the un-fun things and learn about them.  The team leader (manager, whatever) may have some idea of what the "fun" tasks are, but if each individual on the team has a different idea of what those fun tasks are, it is almost certainly going to lead to an un-fun experience.

Team leaders, I suspect that if you look, ask, talk and communicate with your team members, you'll find their idea of fun tasks and what they like doing and what they are good at will tend to be the same things.  I exoect the same thing will be true with the the un-fun tasks, what they don't like doing and what they are not very good at will probably be the same.

By making the pool of un-fun tasks small for the individuals and the team, by getting the team members to expand their skills, I believe your core testing wull improve.  I likewise believe your core team work and cooperation will improve.  Finally, I believe your team's morale and sense of working together, their joint craftsmanship, will improve. 

Those things will tend to improve the testing your team does.  Then everyone will have more fun.

Team Building Or Putting the Fun Back in Dysfunctional

We've all seen these annoying "team building exercises" where someone dreams up something "fun" that will help everyone "learn to work together." 

They can range from the "trust building" thing where one person, blind-folded, follows the directions of someone to get them to a goal.  Then there is the slightly more dangerous (hence fun to watch when things go pear-shaped... and they are almost certainly going to go pear-shaped) version where the blind-folded person crosses their arms and falls backward to be caught by another person. 

Now, upper body strength may play a role in the success of this version.  As does, well, paying attention and at least a rudimentary understanding of physics... and gravity.  Usually things combine into a series of "oh my" type moments.  Sometimes, well, they end with a little bump on the noggin.  (Once in a while its a big bump.)

Then there is the version of "ice-breaker/team-building" thing where two people sit on the ground, back to back with their arms linked.  Then, they work together to stand up.  The idea is they support each other while using their legs to stand up.  Things work just fine as long as both people apply equal pressure at the same rate.  If they don't, well one stands up and the other gets dragged along for the ride.  Or there's the fun alternative - where they mostly push against each other and end in a heap.

The thing is, most of these efforts strike me as artificial.  Translated, they may "work" in some form or other.  Most of the time, I see people l go through the motions because the boss told them to, or HR or, someone.  They don't see the point.

Sometimes , when teams are "created" or "formed" or "built" or, whatever, you see the same kind of exercises.  In these cases, they are even more artificial.  People will go through the motions because if they don't, they figure they'll be fired.  Fear is a great motivator, at least on some level.

What I don't understand is why so many people think it works. 

Its like, oh, I don't know, boss-types throw people together and expect it to work by magic.  Well, maybe not magic.  I think maybe they expect it to work like a high school chemistry "experiment."  You know the type - combine certain items in specific amounts in a specific sequence - POOF!  Stuff Happens!

Well - Humans don't act that way.  But, when you consider people as "resources" it strikes me as, well, demeaning at best.  So, why, when we expect/need people to work together, do we act as if it will just "work."

Most of us will try and work it out and do the "team" thing.  Its part of being a grown-up, mature, professional - right?  We kind of expect it - and they kind of expect us to do it.  So we do the whole storming-forming-norming thing and figure out what we need to do to do the job. 

Then, how many times have people seen this?

About the time we sort out how to tolerate each other and actually work and get stuff done - GOOD stuff, not just the bare minimum - someone waves a wand and reorganizes the company (or department or whatever) and expects things to work at the same peak performance as before the change.

Then there is the "optimizing resources" version of that.  Most of us have seen or heard of that version of the reorg game.

Someone looks at two departments or divisions or, for the "major league" players of that game, subsidiaries, and says "look at the cost savings we can get by combining X with Y!" 

There may be real savings, as in total net savings when the dust settles.  How long it takes the dust to settle is, in my mind, the question.  This is a variation on the "team building games" but instead of a handful of people, its a bunch of people who may very well know little or nothing about what the other people do. 

When this game gets played, I am afraid it is usually for a short-term gain - something to impact the financial statements this quarter or next quarter, with the promise of "real savings/benefits" five quarters in the future.

Then there is the really high-stakes version of the game: Borg, Inc assimilates Minuscule, Ltd.

Well, OK, that may be a slight overstatement.  And, to be fair, I've worked for companies playing both parts.  Still, for those in the company being acquired, the uncertainty of what is coming can be a bit unnerving.  When questions get asked up-stream in the new "organization" and there is no response, then a couple of messages are being sent:  1) We're too busy to respond to your meaningless request for information; 2) Your future is your own (and it probably won't be here). 

Now, those may not be what is intended to be sent, but usually that is what gets received by the "non-response."

What I see happen in those situations is a large-scale version of those team building exercise-games I was on about.  I usually see a mix that has some posturing, some maneuvering, some "hoping for the best" and some resigned to fate.  In the end, there may likely be "staff realignment" actions - meaning some folks get assigned to new groups and others get assigned to "pursuing new interests". 

And the game starts again.

So, the hard part is, how do you make that tolerable, if not palatable?  Can the people who are still there get by without gritting their teeth and going just a tad crazy?  Can the people making the decisions over what the teams, either reorganized or made from those who survived the staff reduction/realignment? 

Maybe, to both.

First, the players in the game - the rank and file folks like I have been for most of my working life - YOU are a crucial part of the mix.  YOU can directly impact how the game gets played.

Here are some thoughts around what I mean. 

People on other teams, groups, departments, whatever are probably not villains in their own mind.  They may well be trying their best in circumstances they find challenging, at the least.  They may very well see you as the villain.

How can you find out about that?  Can you see if they are really villains?  Can you see if they are as clueless as you have been told or come to believe? 

Maybe.  I can't be certain if you ever will.  However, if they work in the same building or general location as you do, try this simple thing:  Walk up and introduce yourself.  :"Hi I'm Pete (well, only say that if your name is "Pete" - try putting your name in there instead) I work in department X.  Can I join you?"

Talk with them.  See what makes them tick.  It may take many conversations, but it is worth a start.  After all, you may also be able to dispel the myth that you have horns, a tail and cloven hooves for feet. 

If they have a similar job function that you do, try talking with them about the problems they run into and how they get over/around them.  Oh, and be willing to share what you are encountering as well.  Make it a mutual learning experience. 

Pretty simple, eh?  I found it works pretty well.  Not all the time and not 100% - but generally, it helps people see that other folks are, well, people too.  It may also give you some insights as to why Tezm Z can't seem to turn out anything your team can work with.  And the folks on Team Z may find out that you don't really mean to be a butt-head.

Things kind of work both ways like that. 

Managers, Leaders, Bosses - you can play a role in this, too.  Before "realigning" groups, have a thought to what the people in those groups are good at.  Find strengths that complement other people's strengths.  Combine them when you can.

I know - most of you believe you are giving it your best effort.  A fair number of you do.

Others, admit it, if only to yourself, are looking to hit the target for head-count or "employee expense" (payroll) or "employee cost-reductions" (sacking high-paid folks) that you were told to hit.  Wel,, you, boss, or whoever set those targets, is a boss too.  Talk to them about this.  Try anyway.  Don't whine,

I call that the "penny-wise/pound-foolish" managenment style. Sure Jane makes a pile more money than these three people - what skills does she have, what knowledge does she have - do the others have those skills or knowledge?  Do they together?  What is the impact to the product (hence customers, hence sales, hence bottom line) if we sack her and leave them?  What if we sack her and one of the other three?

Of course its not easy.  Back when I was in school, the argument was that managers, directors and bosses were paid a pile more money than other folks because they could and would make "hard decisions."  HELLO!  That concept constitutes a "hard decision."  Going with the simple "she makes more than the others, get rid of her" is not a "hard decision."  If that is how you are operating, stop!  Really.

OK, now a scary point.  This is for line managers and staff - rank and file folks like me.

When you get "reorganized" you have an option.  Agree to the terms or pack it in and find another gig.  Simple.  "But the economy is bad!  Things are really tight!  I just did my nails!" 

It is your career and your life.  Manage it.  If you wait for other people to tell you what you can do, you may well be waiting a long time.  If you don't like the terms or what you'll be doing after the reorg, update the resume and get it on the street.  Sooner rather than later.  It weill be better for everyone.

Line managers and leads.  This is for you. 

Find out what your people like to do.  What makes them tick.  I know that you generally try.  The thing is, asking them flat out may be the least efficient way of finding out!  These are people who are testers, right? They analyze and think about things, right?  That means nothing is ever what it seems to them - RIGHT?  So don't be surprised if the answer they give to the question about what they like doing or what they want to be doing in X years/months/whatever, is what they think YOU want to hear and not what they really would answer if talking about this over a beverage with teammates.

Work with your people to learn what they are like.  I know, it can be really hard when you work hundreds (or more) of miles away from people who are supposed to be "direct reports".  Still, make the effort to learn them - not just about them, but learn what they are like, how they respond and how they handle different forms of pressure. 

I saw a really good example of this a couple of weeks ago.  Ironically enough it was at a "team building"exercise.  Some two dozen people were having an outing.  They all worked in the same office and "knew" each other enough to generally associate a face with the corresponding name - at least first name.  After lunch they had some games.

They were divided into two teams, very diplomatically.  They reached into a bag and pulled out a necklace of plastic beads.  Whatever color beads they pulled out, that was what team they were on.

The games they were to play were essentially children's games - some skill, some memory, some, a little of both.  OK, there were some basic rules - some games took 2 people from each team, some took 1.  No single person could play more than 2 games.  Everyone had to play at least 1 game.  After the teams were identified, they had 15 minutes to sort out who would do what games.

One team got together and debated on a name - what are they going to call themselves.  That took several minutes.  Then one person said "I'm really good at X and Y, but not so good at Z. So, I'll do X, I'll be the "partner" for Y, but (pointing at someone else) you do Z."  He then assigned other people to other games.  People just kind of blinked and did not really argue.

The other team took a different approach.  The first question was "Who is good at what games?"  Several people were good at multiple games, some were not sure, some said "Its been so long since I've done any of these, I just don't know."  So, they tried the games.  Yeah, they looked to see who was really the best players for each of the challenges. 

After finding people for the hardest "skill" games, they were sorting out who would do the memory games and who would be the second players on the mutliple player games.  The interesting thing was, those who had a game selected/assigned stayed by that game to make it easier for everyone else to see what games still needed people assigned to them. 

About this time, the FIRST team realized what they were doing and declated it "cheating".  Alas, it was time for the first challenge.  Team 1 had a hard time remembering who was to do that game/challenge.  They took a few minutes to get that sorted.  Then they decided that writing down who would do what was a good idea. so, they began writing things down.

After being trounced in the first game/challenge, Team 1 had, concerns over who was to do the second challenge.  It seems they had people assigned to three challenges and some people were not assigned to any.  One brave soul stepped up for the second challenge (a 1 player game) and was likewise trounced by the Team 2 player. 

This pattern continued.  In one memory game, Team 1 took advantage of a mistake by the Team 2 player and won that game.  In Jenga, Team 1 got very lucky when the Team 2 player bumped the table slightly when moving a pieve, sending the tower of blocks down.  These were the only 2 "wins:" Team 1 had. 

The other games all went to Team 2 - convincingly. 

How does this apply to real work?  I see an awful lot of knee-jerk reactions to situations - kind of like the Team 1 approach in general.  Don't do that if at all possible,  Really.

Find out what your people are good at, and find out what they like doing.  If at all possible, accomodate those skills and preferences.  If there are people who are willing to learn new skills, encourage them - let them practice the "game" the have an interest in.  Encourage others to practice "games" as well.  If there are skills that people don't have, and are needed to do what your group is assigned - ask the people who would be willing to learn the new skill - the new "game".  Give them the option first.

Encourage your people and encourage them to help and support each other,

The next time the "sides" get chosen for the next game, they may not end up in the same Team 1 or Team 2 that they were on this time.  Give them skills to move forward and make their new team better. 

Put the fun back in what we do.