On Controlling Testing, or Being the Boss

I had a revelation recently that I wish I could have had some time ago, like years.  It may have made me a better employee, and in my forays at boss-dom would have made me a better boss.

While my humble outline here may not be enshrined amongst the great writings on leadership that are available for the betterment of leaders everywhere, it certainly represents the sum of experience and belief demonstrated by many boss-types I have worked for and with.  I therefore submit this for consideration toward your professional success as a controlling boss and the success of the group (we'll call them a team) over which you have control.

1.  Encourage Training.  This is important.  This is really important.  You want your testers (they like being called testers better than being called them peons of serfs) to believe that you want them to get better at what they do.  Make sure they know that training is important to their career development. You want to make sure that the training they get is company sponsored training.  Other stuff like, well, that encourages them to think is to be avoided, discouraged and downplayed.

2.  Discourage Outside, Corrupting Influences. We want the people working for us to only consider the information we present to them as being relevant.  When people express an interest in something they read about, maybe on the web somewhere, let them know that it is important they "get all the facts" before deciding to learn about it.  Have them go looking for examples of companies where these wild, new-fangled ideas have actually worked.  When they come back with some examples, make sure they know that these are not really solid examples because they are from outside the industry you are in, or are multi-national, not multi-continental (other way around works as well!)  or they are in environments that are regulated differently than the environment we are in or... any number of reasons why "that won't work here." 

3.  Encourage Engagement.  This is important, too.  You want them to feel warm-fuzzy thoughts in their tummies when they think of the company.  They want them to think, "Wow. The bosses at TLA* really DO have my best interest at heart when they tell me to do something and I'll be rewarded later.  I hope I get a pony as my reward."  This is particularly effective in large urban areas where the belief that a pony might be the "reward"is a complete impossibility where the large urban area does not permit ponies within the city.  The idea is similar to "A rising tide lifts all boats."  That is true, as long as the boats in question have plenty of slack where they are tied-up or moored.  We want to be certain there is no slack at all for the people doing our bidding team, before the tide starts rising.
*TLA: Three Letter Acronym (thanks to Matt Heusser from whom I blatantly stole that concept.)

4.  Discourage Uncomfortable Questions.  Well, not really discourage them, just redirect them to be discussed "off-line" so people are not side-tracked by "side issues like this."  The beauty is that when people ask questions you don't want asked, you can appear to be concerned with addressing their concerns completely, and at the same time keep those questions, and the discussion around them, from causing discomfort to the rest of the laborers.  This allows the quick-thinking manager to isolate the trouble, and trouble-maker, pat their hand and say "there, there" and reassure them that everything will be fine.  The upside for the manager is the next round of "synergy actions"/"staff rationalization"/ happy-sizing / down-sizing, you already have at least one candidate for "change agent" status.

5.  Encourage "Extra Effort".  Getting people to get things done when most people looking at on schedules that simply can not be achieved at a mere 45 or 50 hours per week per person can be a particular management challenge.  One effective technique is to make the "casual" observation that contracts are tied to these dates and the delivery must be made on time.  Of course, if the delivery cannot be made on time, well, "other options" will need to be considered.  Then, this leaves open the carrot of the "stretch goal" set a week or two ahead of the "mandated goal" - where completing the project early may get recognized with a raise (or at least not a pay cut) IF all the other projects get done on time or early as well.  (Notice the subtle conditional statement slipped in there, its a possibility, not a certainty.)  

6.  Discourage Process Questions.  Yeah, this is kind of a big deal, too.  The Process is sacrosanct.  You are not in a position to suggest improvements to the process until you have moved through it completely, successfully at least once.  Well, maybe twice or three times (because success is a habit, after all.)  If people are having problems working through the process, it is because they are not doing it right.  If they do it right, they have no problems.

7.  Encourage Participation.  This one is important, too.  One way to handle trouble-makers is to get them involved.  If someone asks questions, like a lot of questions, ask if they'd be willing to participate in a study group that has been created to look into that very issue they ask questions about.  It is a great way to get all the people you need to keep an eye on in one place.  Additionally, because this must be done in addition to the project work (see number 5 above) it will be one more way to drain them of extra energy to make trouble.  If they still complain, ask if they have been "participating" with the study group on the issues they are complaining about.  If not, you just transferred blame to them!  That is good leadership.

8.  Discourage Independent Thought.  This is a hard one and it may take all the previous lessons to pull this one off.  You want people who can do decent testing.  That means you may have to hire people from outside the company.  That also means you may need to hire people with some level of experience.  This experience may have given them ideas of their own, or at least carried the lessons they learned from previous jobs with them.  Encourage them to "observe and learn" how things are done at your company.  Then, use the ideas from number 6 above to get them to become fully assimilated into the mindset of the company.  This will, hopefully, keep them from thinking something is wrong with the company by reinforcing the image that the problem is with them (after all, they left their old job because of why?)

Lessons Learned - I've seen these ideas applied often at various shops.  Where two or three are used effectively, the result has been promotion for the manager who did such fine work.  Of course, the fodder complained and whined until they were replaced or learned that complaining led to them "seeking new opportunities" - which pretty sell stopped the complaining.  In public.  Which is as good as stopping complaining altogether.

Remember: Managers are the keepers of the Truth.  The Guardians of the Holy Flame of Knowledge.  Facts can change and shift and using these techniques what the Manager agreed to on Monday, on Tuesday, if you are effective, you can disagree with and explain that the staff misunderstood.  This technique is good for keeping them from ever really understanding what is expected, which is even better because the money set aside for raises and bonuses will go into your pocket.

On Passion, or Be Careful What You Wish For

Recently I was reminded of something that was said several years ago.

The Several Years Ago part: In the middle of a project that was simply not going well, in fact, it was a bit of a train-wreck.  Nah, not a bit.  It was a complete and total train-wreck.  Pick something that would go wrong and it did.  In spades.

Yours truly was QA Lead and was overwhelmed.  A "target rich environment" does not begin to describe what was going on.  Massive effort, huge amounts of overtime to try and control the damage, stop the flooding, stop the bleeding, well, pick a metaphor.

Fact was, the testers were putting in a lot of effort and, frankly not many others were.

So, sitting having an adult beverage, or several, with one of the development managers on the project, he looked at me and said, "Pete, you have a real passion for what you do.  You're better at testing and understand software better than an awful lot of people I've worked with.  You are really passionate about what you do.  That is great.  Be careful though.  If you're too passionate you can burn out."

That struck me as odd, at the time anyway.  How can one be "too passionate"?  Is it possible that one can be too involved? Too close to the work? Too passionate?

After all, we have a lot to do and scads of work and... whoa.  Why is it that some folks are diving in and going full bore and others are, well, sliding by and doing what seems to be the minimum.  Why is it that some people just, well, not as deeply into making the project work as others?

The Reminder part:  So, talking with another tester I know, she was muttering about a project where the developers just did not seem to care, about deadlines, quality of the project, impact on, well, performance reviews, raises, bonuses, and the like.  She looked at me and said "Its like they just don't care!" 

SO,  why is it that some people just, well, are not as deeply into making the project work as others?  I don't know.  Maybe it depends on what is expected, or what the normal approach is for the shop or company or, whatever.  Maybe it depends on the nature of the project leadership.  Are people being managed or controlled, compelled.

While what is often called craftsmanship is something that seems hard to find.these days, in some places (maybe many places, I don't know) I remember hearing many people speak passionately about being, well, passionate - as a tester, as a developer, or as whatever it is that each one of us is.

I got to thinking some more Friday night and generally over the weekend about this.

When looking for places where everyone is passionate about their work, what does that look like?  How do you know when you find it?  I used to think I knew.  I've worked at places where the majority of people were very passionate about what they did.  They wrapped much of their view of their self-worth into their work - so if the project was a success, their efforts were "worth it."

Then, I started wondering what a project that was a success looked like.  I suspect it rather depends on the software development group's target audience.  Are the people who will be using the results of your work all working for the company you are working for?  If so, "market" is a hard concept - unless the results of their work, with the new system, improves so much that the company as a whole performs better because of the many long hours and weekends in the office and ... yeah, you get it.

If the company makes software that will be bought by other companies for use in their business, the combination of sales, licenses, recurring/renewal of contracts around the software and the like will be one measure of how your efforts contributed to a successful project.  Likewise, the customer-companies being able to conduct their business better, more efficiently, is another measure of the success of the project.

And so, what about the other signs?  What about the places where people are not passionate about their work.  What do they look like?

That's easier to find examples...

People use "process" as an excuse to not do something.  "I'd love to do this, but I can't do X until D, F and L are in place.  That is what the process is."  (Whether its true or not does not seem to matter.)

People lock into rituals and stay there.  Arrive 5 minutes after the "start time"; start laptop/desk-top computer; get coffee; drink coffee, eat breakfast; sign on to network; get more coffee; sign on to email (personal)... etc., leave 10 minutes before official "stop time" to "avoid the rush".  Use the, "well, I work a lot of extra hours from home and over the weekend" reasoning.  (Oh, laptop is still in the dock on the desk as they are heading home.)


The appearance of work counts more than actually doing work.  Lots of reports being filed, status reports, progress reports, papers being shuffled up to leads and supervisors and managers and, of course, process management.  This is different than using process as an excuse to not do something.  This is taking the literal process and ignoring the intent.

Heroic Behavior is rewarded  more than steady solid work.  Now, I'm not down on heroes.  I've been in that role, and was recently called a hero as well.  I mean the false-heroes, the ones who dawdle and obfuscate and put things off and delay, and miss interim deadlines and miss delivery deadlines - partly by using the first three behaviors - and then work massive hours the last week of a project to pull things together and deliver something - and let everyone know how hard they worked. to "make this happen."

I bet you can come up with a bunch of other examples.  I stopped there simply because, well, I did.


Now, What to Do?  If you find yourself working at a shop or department or company that you find described above - where it seems you are the only one who cares - what do you do about it?  Ask yourself, "Has it always been this way?"  Maybe something changed recently, or not so recently.  Maybe the change has been gradual.

Sometimes, it takes you being the one to be burned by this behavior to notice it.  Sometimes it has been going on with some people and not others and it is your turn to work with these people and - what a mess.

You can say "Maybe they learned their lesson from this and the next time will be better."

Don't bet on it.  There is likely some other reward system in play that they value more than the rewards workmanship, craftsmanship and passion for doing good quality work can provide.  Ironically, they may get rewarded from their supervisors for being heroes (even though they created the situation that needed heroes) or "preserving the process" or, whatever.

So, back to what to do.

Your choices are limited.


You can try to "change the culture."  This is easier in small companies than in large Borg-like companies that grow by assimilating small companies into the Collective.  I know people who have tried to do this.  Some were successful; those dealing with the Borg Collective were less so.

You can try to "change the environment."  Here I include "process" as well as the nature and flow of the work and communication.  You can ask questions and field inquiries and take part in improvement task forces and, and, and... don't let the project slip.  I know people who have tried this - myself included.  It may work, you may feel more engaged and more aligned with improving the company.  At some point you may look back ans wonder what has been accomplished.

You can stop resisting - Accept it for what it is.  Turn off independent thought and go with the flow.  Collect the paycheck, take the "motivational development" courses and continue to collect the paycheck.

You nuclear option - Leave.  Go somewhere else.  That is what I did with the company in the first part of this post.  I packed it in.  I do not regret it.  My other options seemed so improbable.  I tried them - the engage thing, the culture change thing.  I could not bring myself to stop resisting.

Please, never select to stop resisting.  Never conform that much.  We are testers.  We can not be good testers if we stop questioning.  That is what is required of that option.

On Unintended Consequences or Self-Blindness to Risk

As I write this, it is the early afternoon of Sunday, April 1, 2012. 

I was sipping a cup of very nice coffee, reading student self-reviews for the Foundations Course of BBST that I am an assistant instructor for (this go-round!)  and a story on the news threw me back 1 day shy of 30 years.

On April 2, 1982, military forces of Argentina invaded the British holding of the Falkland Islands.  There had been a long-standing dispute over Argentina gaining/regaining control over this small archipelago that had been a British possession for generations.

There was a large naval battle fought between Germany and Britain in December of 1914, during the First World War.  At the time, it was an important refueling and resupply depot for the Royal Navy - if Germany could seize the island group, it would prove to be a heavy blow to the British, and replace the base the Germans had lost at Tsingtao a short time earlier.  The German squadron could also refuel themselves since coal was in short supply.  The Royal Navy scored a decisive victory there, sinking or capturing six of the eight ships in the German squadron.  The naval victory in 1914 put the Falklands in an almost mystical place in the history of the Royal Navy.

In the midst of growing economic unrest, the military junta ruling Argentina decided that it was time to more aggressively act to raise patriotic sentiment and firmly grasp a nationalist ambition by regaining sovereignty over this small collection of islands off their coast.  It was believed that Britain was unwilling, and possibly unable, to respond militarily to a challenge in the South Atlantic over the Falklands, South Georgia and the South Sandwich Islands.

Remember what the economy was like globally in 1981 and 1982?  Argentina was not the only country that was having economic problems.  They seized a holding of another country that was also having its own economic problems, with a Prime Minister who was not terribly popular at the time.

The small Royal Marine contingent was overwhelmed and surrendered.  Word of the invasion reached London.  There was a furor over the Argentinians attacking/seizing/invading part of the British pantheon of Naval Victories.  The Empire struck back.

A task force was dispatched and the Argentine forces in Port Stanley, the capital of the Falklands, surrendered after a string of British victories.  Yes, there were a series of blows that hurt the British - two destroyers and two frigates were sunk, along with two other ships that were destroyed, and a number of aircraft.  The Argentine forces lost a submarine and a cruiser, a World War Two vintage ship that was sunk by a British submarine, along with scores of aircraft.

Both sides had their operational problems that led to mistakes that led to lives lost and failed operations.  There were some 3,000 people killed or wounded in this brief fight.  There were over 11,000 Argentine military forces captured.

Margaret Thatcher soared in popularity for a time.  The protests against the Argentine junta  increased and it eventually collapsed - the exact opposite of what their planners intended.

Two things stand out in my mind from this that apply to testing:
1. Deluding yourself over the potential for failure can be career (or at least job) ending;
2. Evaluate the real risks involved, honestly.

Know what the risks are.  Know what the likely results are.  Know what the possible results are.  Know that you can not control everything - and sometimes you can control nothing.  Plans are great, as long as you don't expect them to be carried out precisely as they are written.  Planning helps us understand what problems may be encountered.  No plan survives initial contact with the enemy.

Oh.  One positive thing did come out of this.  A really nice pipe tune was written by a bagpiper in the British Army who fought in this campaign.  The Crags of Tumbledown Mountain is a really nice tune on pipes.