Archive for the ‘Management’ Category

Top 10 Ways To Ensure Your Best People Will Quit

Tuesday, April 28th, 2015 by The Director has the Top 10 Ways To Ensure Your People Quit.

I’ve hit some of these themes here before.

This list talks about active retention strategy and dedicates a couple of bullet points to it.

However, I’d swap out those for a couple of other ideas, such as:

  • Keep the employees doing the same things for a long period of time. The tedium of a couple of videos during orientation is nothing compared to doing the same tasks over and over again for years.
  • Don’t demonstrate the employee’s impact or meaning to the company effort. Especially in the auxiliary jobs–like QA–where employees might not see how their efforts are helping the company. Employees who feel forgotten, who feel as though they don’t matter, or feel as though they’re taken for granted are not employees for long.
  • Don’t succeed as a company. If your employee doesn’t see the company as a long-term success, the employee will look for one that is.
  • Build a corporate culture catering to one lifestyle. The stereotypical startup involves coding all night fueled by energy drinks and pizza, having crazy outings as a company, and funky office space with video games, a bar, and/or foosball/pool/bubble hockey tables. This is all well and good for a certain kind of employee–one fresh out of college or the parents’ basement, but if the culture favors only on those employees (especially if the culture is supposed to make up for lesser pay, longer hours, or other shortcomings), employees who move out of that phase of their lives will go look for a grown up company to work for.

That would bring the number up to more than ten, though.

The song says there are fifty ways to leave your lover (although the song itself does not enumerate them all, and Paul Simon marked that defect Resolved (Won’t Fix)). There are probably that many ways to lose your worker, too.

My Kind of Manager, Too

Friday, January 31st, 2014 by The Director

Bill Gates sez:

An essential quality of a good manager is the desire to seek bad news rather than deny it. An effective manager wants to hear about what’s going wrong before he or she hears about what’s going right. You can’t react appropriately to disappointing news if it doesn’t reach you soon enough.

You concentrate on bad news in order to get started on the solution quickly.

That’s my philosophy, too. And I share bad news willingly.

Management Lessons From My Bad Bosses (Part V)

Monday, February 25th, 2013 by The Director

(Part I, Part II, Part III, Part IV)

Brad, the Middle Manager
I eventually moved on from the blue collar world (and, if we’re counting, the pink collar world, since that’s the color sometimes assigned to retail work) into the white collar world, although by the time I got there, business casual was the norm and the collars were not often white. Now, in many places, the collars at all are optional. I made a couple of moves from technical writing into software quality assurance, back into technical writing, and then onto Brad’s team as a Quality Assurance Analyst I.

Brad managed a team of Quality Assurance Analysts working on a chemical modeling and lab benchtop software suite for a large pharmaceutical firm. By the time I got into my cubicle, the project was late and on the verge of losing money, but that was beyond my purview. That was in Brad’s world, as it were.

I don’t know Brad’s background, but I do know that it was not anywhere in the technical realm of software. He did have an MBA, though, and when the company was hoping to move from a product-based business model (you build it, you sell it, people buy it) to a project-based business model (you promise to build it if someone promises to pay for it), it staffed up its ranks, including its management team. The org chart featured a vice president in charge of projects, a director in charge of projects, a bunch of managers in charge of teams on the projects (at this time, the plural form of project was still only anticipated, and the only actual project, as I mentioned, was in trouble), a set of leads on each team, and then team members. That’s three tiers of management where technical skill was optional, and in Brad’s case was sorely lacking (although his hiring of me proved his keen insight into the matters of personnel).

As far as I could tell, Brad’s main job duties included sitting in meetings with other managers and sometimes team leads (but not the actual meetings with technical staff—the team lead took care of that and assigning roles and day-to-day duties). I am pretty sure he made some PowerPoint presentations and reports of some sort, along with annual goals for the team and individual reviews of his team. But he pushed paper and handled the Parkinson duties of the team.

An anecdote into interacting with Brad: I wanted to buy a $35 text editor that I’d used before to help edit the various and sundry text files a Quality Assurance Analyst I would edit during the course of the day, such as configuration files, batch files, and the special files used by chemical modeling software import features. I told Brad I’d like it. He put it into his process and workflow, and he wanted a business case for it. So I wrote a document that included a comparison between the installed text editors, Microsoft Word and Microsoft Notepad, the advantages of the text editor I wanted (IDM Software’s UltraEdit—since I’ve named its competitors already loaded onto my workstation at the firm, I might was well offer an unsolicited testimonial to it). The document identified all the text files I’d edit with it as well as future uses for it (including the buzzword XML, which would prove important although not relevant at the time).

After reviewing the document, Brad called a meeting of the Quality Assurance Analysis team to discuss it. Before that meeting, though, the team lead called a pre-meeting to discuss it. The four QA team members gathered in a meeting room to discuss what a text editor was and why QA might need it. The importance of editing the data files we’d need to test or reviewing log files was a bit lost, but I mentioned XML, the buzzabbreviation took off. Although the product did not use eXtensible Markup Language now, someday it might. The buzzword traveled up the food chain, and Brad turned the either approved or got approved the purchase.

The process to approve the purchase cost more than the purchase itself, but it was the sort of thing that filled Brad’s day. Until the company, trimming its headcount to stave off the disastrous consequences of its altered business model, cut Brad during a set of layoffs. After that time, the QA Team Lead reported directly to the Director or the Vice President with no productivity loss.

Unlike Ron, Brad was not lost in the trappings of being a successful businessman; Brad was lost in the trappings of being a manager. Brad illustrated to me that managing people doing a task works best if you understand the task at hand and don’t get yourself into a situation where your only skill is holding meetings, preparing papers, doing group projects, and doing the sorts of things that earn you an MBA or used to suffice when you reached a certain level within a very large corporation.

In today’s fluid, lean business world, you have to make sure that you grok the thing you manage and that you can improve the efficiencies and add value to those under you. I kept this in mind when I reached the executive level and spent my time helping my people solve the problems they found in their jobs and increasing the company’s efficiency by boosting the employees’ efficiencies. If I didn’t call enough meetings, so be it. The point of the job was to do the job, not to talk about it.

You can read a hundred books about good business practices, but the lessons within them will only be the abstract knowledge distilled from a cavalcade of someone else’s success. The stories and ideas within them might slide from your consciousness like raindrops from a freshly washed (with the deluxe package including the clear-coat sealant) car. Even when you look back to the good bosses you’ve known personally and have worked under will seem translucent in the pleasurable glow you had from working with them and succeeding in your position therein.

But the lessons you learned from your bad bosses are distinct because they were painful. If you, with enough therapy, can look to them to understand why your bad bosses were bad bosses, you can be a better boss yourself. I’m not talking about studying the psychological motivations or getting in touch with them emotionally to understand what compelled them to behave as they did; I’m talking about understanding why what they did was ineffective as a manager or leader.

Besides, they took a little bit of your soul in those brief hours/days/weeks/months/years you worked for them. Shouldn’t you take a little something back?

Management Lessons From My Bad Bosses (Part IV)

Friday, February 22nd, 2013 by The Director

(Part I, Part II, Part III)

Lee, the Purchaser
The art supply store hired me as a shipping/receiving clerk, which was mostly checking in the supplies as they came off the truck to make sure that Koh-i-noor had sent us the number of pens they said they did and the number of pens we had actually ordered. The store catered to the business community who needed foam board for presentations and to students who needed specific pads of paper for their art classes. In addition to clerks, commercial inside sales people, and a shipping/receiving clerk who was also responsible for custodial duties, small computer administration, and miscellaneous electrical repairs, the store had a dedicated purchaser, an employee whose full-time endeavor was to map the sales of individual products and to order enough to meet anticipated demand. Her name was Lee.

In the early 1990s, personal computer usage was in its infancy, and the store’s inventory was maintained on a minicomputer with thin client terminals. Lee printed out reams of product lists to use as she checked the back stock and the items on the shelf to make her predictions, which were more astrological than based on past sales.

In the late summer, as the store was preparing for the back-to-school rush that produced much of the annual sales, a truck arrived with pallets of paper products, from notepads to 4’ by 6’ boxes of heavy cardstock. The receiving room of the store could handle about 3 pallets of product comfortably. This particular load comprised 14 pallets, including two double-sized pallets containing bins of foam board. The truck driver mercifully left his trailer at the exterior loading dock for a half hour lunch to give the receiving clerk the chance to restack and rearrange pallets to fit six pallets uncomfortably into the warehouse.

“Why so many?” Lee asked, incredulous. She carried a printout of the expected order. The receiving clerk took the papers from her and pointed out how the four on this line translated into so many cubic feet, how the ten on this line translated to so many more cubic feet, and so on. The order matched the delivery.

Fairly often, we worry that someone has forgotten to take the customer into account when making plans or acting. However, Lee, working with numbers in the abstract and little ticks on lines on sheets of paper, became divorced from the realities of the product. The concrete products that filled the warehouse and many backaching hours for the receiving clerk as he somehow fit these products into slots and shelves to make the warehouse navigable.

Lee taught me to remember the customer and the product. In too many instances, particularly in the software industry, the customer-facing professionals keep the customers too much in mind and have little understanding of the technologies of the product or even the things for which the customers will use the software. Instead, their focus remains on pleasing the people who place the orders, and they might find themselves promising more than their teams can deliver. Much like Lee might.

(Part V)

Management Lessons From My Bad Bosses (Part III)

Thursday, February 21st, 2013 by The Director

(Part I, Part II)

Ron, “I Own the Business”
Ron was an older gentleman operating a computer assembly and sales business from a converted shotgun shack in the southwest corner of St. Louis. The living room was what you might call the commercial sales division with three desks and tables piled with papers and unopened mail. Ron was not very organized. The dining room was a retail sales floor of sorts with a number of custom assembled machines on display to, generally, nobody. The old kitchen held the bookkeeper and the woman whose sole job was filing return material authorization requests for the cut-rate components that Ron favored. An addition and shed that filled the former back yard held a number of young technicians assembling computers and slightly older technicians repairing computers. The one car garage facing the alley was the loading dock, with a desk for the receiving clerk to check in and label individual components to make it easier for the RMA lady to process when they came back and steel shelves that held a number of broken bits of computers Ron accepted in trade. Piles of boxes littered the floor, since the receiving clerk discarded packing material over his shoulder as he worked. Ron hired me to be a clerk Friday, which meant to do whatever he wanted. In my three months there, this included filing copies of invoices from years past, acting as accounts receivable by calling, without training in the niceties or legalities of bill collection, numbers printed on inches of fan-folded, pin-fed, green-and-white lined paper, receiving (and receiving a tongue-lashing for wasting time in cleaning up the loading dock), computer delivery or pick-up in the far-flung suburbs of St. Louis, and ultimately as a computer assembler when one left in a fit of apoplectic pique.

Ron was the worst boss you could imagine: His self-importance and scattered brain combined to provide moments where he would cross from the front office through the showroom to the accounting room to get the accountant to get “that guy” (the clerk Friday) to come to place a telephone call for him. Instead of coming to get “that guy,” the accountant instead made the call from her phone to ask the call recipient to hold for Ron. Another time, Ron came up to me as I was stocking parts, and led with a noun of direct address to address me directly: “Mark,” he said, gesturing at me. “Brian,” I corrected. “Mark,” he continued, wondering what the gag was. Ron fired me, essentially, by telling me that I would not be needed after Christmas when I told him I was taking the week of Christmas off to have dinner with my father 400 miles away. My father was in a brief remission from cancer that would prove terminal, and my brother had leave from the Marine Corps. I took Ron seriously, unlike one of the sales people who brought in doughnuts every time Ron fired her—and Ron’s wife assured her that she was not fired. But on the Monday of the week after Christmas, Ron called me at home the first work day after Christmas to find out where I was. After I could not convince him that he fired me, I quit over the phone. “Without any warning?” he asked.

I’m sorry to go on so long about Ron, but he is a treasure trove of stories that seem parablic, but actually happened.

Ron’s business stayed afloat not because of Ron’s business acumen, but because of dedicated employees led by Ron’s wife who kept the business going and managed its transition from a business forms printer into a computer dealer in the early 1990s as the business world was rapidly transitioning to desktop computers. The core of loyal employees kept the business a going concern, so some amount of bluster and possible incompetence at the top might not be fatal for a business, but it does make a difference. Ron also reminds me that too much in the trappings of success and importance—spend four minutes to get that guy to dial a telephone—impede progress and efficiency. One really has to gauge whether additional staff and whatnot actually improve efficiency or whether they merely prove Parkinson’s Law.

(Part IV to come)

Management Lessons From My Bad Bosses (Part II)

Wednesday, February 20th, 2013 by The Director

(Part I.)

Mike, the Telemarketing Manager
Part-time telemarketing fundraising is a tough gig. Wearing a headset, one sits at a table with a computer monitor and keyboard. A mainframe or server somewhere dials a stream of telephone numbers, and when someone answers, the monitor displays information about the person along with the approved script for the fundraising customer. One then tries to sound as fresh and chipper to this potential mark, I mean “donor,” as one did when one started the shift ten and a half hours earlier. Success ebbs and recedes—one gets a couple of the voices on the line to agree to joining the society or supporting the law-enforcement fraternal organization, and one gets confidence that translates into further sign-ups, or one gets a string of hang-ups and angry voices whose ire deflates one’s confidence, which breeds further lack of success. After darkness falls, the calls stop, and the person with the lowest total for the day empties the trash cans. It’s low-rent Glengarry Glen Ross with less swearing and less individual opportunity.

Mike, the manager of the roomful of twenty or so twenty somethings happy to be working outside of retail, was missing his front teeth. A homemade tattoo of his prison number colored the inside of his wrist. The tattoo, he told us, was so that when he got angry in his car, if he reached for the illegal gun under his dashboard, he would see the tattoo and think twice. He boasted that the only two things he had not been to jail for were rape and murder.

Colorful nature aside, Mike was not actually a bad boss. He was a boss in a bad workplace, a workplace that suffered enough turnover that the newspaper carried a running ad for telemarketing fundraisers, and the shop had new interviews—and empty chairs—daily.

Mike, though, was good at the job. His deep, resonant telephone voice bred success as a telemarketing fundraiser. Eventually, he worked his way up from the interchangeable tables through the PCs (previous contributors list, a special phone list of people who had given to the campaign in other years and were expected to be easier marks, I mean “donors,” in successive years) to managing the stable.

Mike demonstrated that one’s past is not necessarily relevant to one’s ability to perform in a position. The right confluence of talents and drive can lead to success regardless of other less savory incidents or experiences. When looking for someone to fill a position, or whether judging someone’s abilities at one’s current job, one must focus on the present and not the past.

(Part III)

Management Lessons From My Bad Bosses (Part I)

Tuesday, February 19th, 2013 by The Director

Leo Tolstoy said that happy families are all alike, but dysfunctional families are all unhappy in their own particular way. Management lessons you receive from your mentors are pretty much the same, too. They reflect the best practices and some gleanings of a lifetime of achievement and success. They can seem a little plain, clichéd, or easily forgettable. Or maybe I just didn’t pay attention when things are working. Therefore, the things I learned from my inspirational bosses blurred together, but the lessons from bad bosses I’ve endured remain stark and memorable.

After college, I put my English degree to use in various low-wage jobs where I quoted Shakespeare and Melville to unimpressed co-workers. I worked in retail, I worked in warehouses, I worked in a plant operating a piece of machinery that could have removed my arm, and I worked in a pseudo-office environments for a variety of bosses and foremen. Some showed me the right way to do things specific to that job. Others, though, taught me the wrong way to do anything.

Donny, the Produce Manager
I put myself through college working in a grocery store as a bagger, a checker, and eventually, a produce clerk. After the ownership changed, the new owners brought in managers from their other stores to run ours, their new flagship store. They replaced a thoroughly professional produce manager, who showed his keen insight into management by bringing me aboard, with a younger, less expensive manager. Donny had managed the produce department at the new owners’ first grocery store and felt he had a special relationship with one of the owners in particular. This special relationship did not prevent Donny from assigning denigrating nicknames to the owners, and Donny loved to share them with other employees.

Donny’s tenure lasted about a year with the store, during which time he did the minimum work required to keep his employment, relying on his employee to carry the burden of bringing the department’s appearance to standard. Donny spent his days reading the newspaper in the store’s break room and, when he was on the sales floor, regaling me with stories of his satyrical youth and attempts at a satyrical present. Possibly a step ahead of termination, Donny secured an assistant manager position at a larger chain’s store, ironically one owned by the store’s previous owners. Donny closed out his tenure by spending even more time in the break room and making a show of how little he was doing and cared.

Strangely, Donny’s new job and its expectations of effort and professionalism did not suit him. He approached my store’s ownership and management for a position with our store again. He was rebuffed, and not in the fun way his satyrical tastes preferred.

Donny taught me a couple things about workplace relationships. First and foremost, a special affinity or cordiality with someone further up the org chart will not necessarily provide any extra benefits if one is not a productive employee. Don’t mistake a kind word now and then, some bawdy humor shared with a smirk, or other fraternity with professional esteem.

Secondly, Donny emphasized that burning bridges can very often work against your long-term best interests. Remember all the “It’s not you, it’s me” speeches your friends have gotten when they’ve broken up? Use that template for your exit interviews, because someday you might find yourself in another situation in a position to accept work or consulting projects from the very organization or people you cannot stand now. After all, you’re really looking to leave an entire situation, not just a company or some people. Remain diplomatic, and you’ll keep your options open.

Thirdly requires another anecdote. Donny found a contest in one of the monthly produce periodicals. A fruit grower urged produce managers to celebrate National Pear Month by creating an elaborate display of the grower’s pears. Contest participants could send pictures of their creations to win fabulous prizes with the grower’s logo on them. Donny ordered several cases of exotic pears that the customers of our bread-and-butter small grocery would never actually buy, created a simple display on a simple table, photographed his child eating a pear by it, and won something from the contest.

The story offers many counter-examples to what one should do: squandering company resources for personal advancement, for example. But Donny had his eyes open for a small opportunity, an esoteric chance, and he put effort toward it, yielding success. In the course of our day-to-day work life, it’s far too easy to get bogged down in the forest, looking at the trees, and miss a very interesting and potentially beneficial vine or shrub growing amid the trees. Even bad managers can provide good lessons, so don’t dismiss everything they do or say. Just most of it.

(Part II)

Work on the Former, Then on the Latter

Tuesday, November 27th, 2012 by The Director

How to Be Brilliant Without Pissing People Off.

Unfortunately, the article doesn’t spend a lot of time on self-assessment to discover whether one is brilliant or not or if one is just a jack.

The Unleveling Wind

Tuesday, October 2nd, 2012 by The Director

In a stunning turn of events, flat corporate structures might not be the optimal solution:

Disenchanted with the corporate world, many entrepreneurs strive to keep their organizations as flat as possible. But a recent study suggests that, in some cases, office hierarchies help employees get more done. And that too many dominant personalities could jam up the works.

The Findings

The study, conducted by researchers from the business schools at Columbia University and Northwestern and the University of Queensland, Australia, found that when there are tasks that require teamwork, people get more done when there are defined leaders and followers.

I once worked at a place that moved from a hierarchy to a flatter structure. Although this sort of structure is often promoted as egalitarian and allowing everyone to take a stake in the outcome, the result is often less Utopian. Sometimes, when everyone takes a stake, nobody takes responsibility, and when things go wrong the blame–if blame is due–is diffused. It can always be somebody else’s fault.

In other situations, flat hierarchy projects end up with the people who think it’s most important making the most effort and carrying along other extraneous people who hope to share in the success of the project or at least appear busy enough to continue drawing a paycheck.

Frankly, I favor an open communication hierarchy where members of the hierarchy have good relationships not only with their peers in the org chart but also with members of other levels of the hierarchy, mostly but not limited to people above and below you directly.

In that case, you know how to escalate things when things need to be escalated. In a team of equals, you get a chasing-the-rabbit-around-the-racetrack sort of effect, where someone can pass you off to someone else until you eventually find someone who wants to fix it or someone who cannot think of someone else to pass you to.

Mind Traps That Aren’t Deadly, But Are Disruptive

Monday, August 6th, 2012 by The Director

Psychology Today has an interesting article called “Deadly Mind Traps: Simple cognitive errors can have disastrous consequences—unless you know how to watch out for them” that describes a number of, well, cognitive errors that have caused people to make mistakes that lead to their doom.

Although we’re not really working with literal doom on a daily basis in software development (although, increasingly, the errors we introduce, uncover, and/or do not discover in software do lead to literal doom), the same mental errors can lead to problems within software development projects and within the quality assurance within them.

So let’s look at the traps listed in Psychology Today:


Hall [a mountaineer who summitted Mount Everest but died on the descent] fell victim to a simple but insidious cognitive error common to many types of high-pressure undertakings. I call it “redlining.” Anytime we plan a mission that requires us to set a safety parameter, there’s a risk that in the heat of the moment we’ll be tempted to overstep it. Divers see an interesting wreck or coral formation just beyond the maximum limit of their dive tables. Airplane pilots descend through clouds to their minimum safe altitude, fail to see the runway, and decide to go just a little bit lower.

You see a lot of this sort of behavior on timelines, where close to milestones or the end of cycles, someone introduces changes or whatnot. Sometimes you see this when someone wants to use some unproven, misunderstood piece of technology to solve a problem, but the learning curve proves too steep to get things done on time, or someone has to kludge a solution to meet the need at the last minute.

You know how to fix this? Understand and adhere to limits.

The Domino Effect

Similar tragedies play out time and again when people try to rescue companions. A teen jumps from a dangerous waterfall and disappears; his buddies follow, one after the other, until they all drown. A firefighter goes into a burning building to rescue a comrade; another goes in after him, then another.

In each case, the domino effect results from a deep-seated emotion: the need to help others. Altruism offers an evolutionary advantage but can compel us to throw our lives away for little purpose. “In stressful situations, you see a failure in the working memory, which is involved in inhibiting impulses,” says Sian Beilock, a psychology professor at the University of Chicago. “People lose the ability to think about the long-term consequences of their actions.”

You see this in software development in many cases: When something’s going badly, the management throws more people at it, and they do something badly, only less efficiently (see also Parkinson’s Law). Or a company chases features that other companies put into their software or chase some small bit that competitors or the industry press follows.

You see this, too, when too much effort is put into one channel of testing, where one expends a lot of effort in automated testing and continues pursuing that goal to the exclusion of other, more relevant exploratory testing or whatnot.

To keep from being another domino to fall, the article warns you not to leap instinctively into the manure machinery (truly, that’s what it suggests), but that you take a step back and consider alternative actions if you see cascading failure before you. The saying attributed to Einstein, that insanity is doing the same thing over and over again and expecting different results, applies. So does your mother’s “If everyone else jumped off the bridge, would you jump off the bridge, too?”

When you see something fail, don’t try it again. Try it again, differently.

Situational Blindness

As GPS units and satellite navigation apps have flourished over the past few years, there’s been a spate of similar cases, in which travelers follow their devices blindly and wind up getting badly lost. In each case, the underlying mistake is not merely technological but perceptual: the failure to remain aware of one’s environment, what aviation psychologists call situational awareness, or SA. People have always had difficulties maintaining SA, psychologists say, but the proliferation of electronics, and our blind faith that it will keep us safe, has led to an epidemic of absentmindedness.

“A big element in SA is paying attention to cues,” says Jason Kring, president of The Society for Human Performance in Extreme Environments. “If you’re focusing just on that GPS unit, and you see that little icon moving down the road, and say to yourself, OK, I know where I am, technically, that can be a big problem, because you’re not looking at the world passing by your windshield.”

Full situational awareness requires incorporating outside information into a model of your environment, and using that model to predict how the situation might change.

You can lose situational awareness in many ways in software development and testing. You can narrow your focus only to the problems in your niche of the process, your set of features, or what have you. You focus on the trees, and you can’t see the Christmas tree lot.

So to combat this, you need to pay attention to higher level considerations. You need to know as much as you can about the industry, the customers, and your organization as you can, and to factor as much as you can into your decisions as to how to proceed. If you know what your customers, that is, your users, really need and really do over the course of the day, you can weight your testing to cover those needs more than the features your business analyst forced onto the software because your customer’s VP, hired from outside the industry, wanted them.

Double or nothing

The runaway-balloon problem is a manifestation of our irrational assessment of risks and rewards. As Daniel Kahneman and Amos Tversky first pointed out back in 1979, we tend to avoid risk when contemplating potential gains but seek risk to avoid losses. For instance, if you offer people a choice between a certain loss of $1,000 and a 50-50 chance of losing $2,500, the majority will opt for the riskier option, to avoid a definite financial hit. From the perspective of someone dangling 20 feet in the air, the gamble that they might be able to ride the gondola safely back down to the ground seems preferable to a guaranteed pair of broken legs. But in the moment, they can’t factor in the price they’ll pay if they lose.

We see this in software development when someone takes a flier because he or she thinks he or she has nothing to lose. A developer doesn’t like the way the code works or encounters some difficulty with it, so he spends all weekend rewriting several weeks worth of several developers’ work before the Monday client meeting instead of just putting a little rouge on the hog and acting from the insight gleaned at the client meeting. Or a company rushes headlong into a move to a new technology or new cloud strategy against the reluctance of its clients. And so on.

To combat this risky frame of mind, you’ve got to, again, establish limits and procedures to make sure that people know when they can take risks on their own–and when they can’t.

Bending the map

Such errors of overconfidence are due to a phenomenon psychologists call confirmation bias. “When trying to solve a problem or troubleshoot a problem, we get fixated on a specific option or hypothesis,” explains Kring, “and ignore contradictory evidence and other information that could help us make a better decision.”

Confirmation bias is very common in our field. Technological fanboys think that their favored language or framework is the best, and that all evidence points in that direction. The whole sales, marketing, and company magazine teams live just to provide this confirmation bias about how well your organization is doing and how everything is going swimmingly.

To combat confirmation bias, you’ve got to learn to distrust yourself. You’re not that smart. The way you think something is going isn’t the way it is going. Well, maybe it is. You’re not even lucky enough to get it wrong 100% of the time. When you encounter a new piece of evidence or information, don’t just try to fit it into your gestalt or dismiss it. You’d better figure out why that little strange thing happened, and what it can mean for your whole endeavor.

(Link seen in Reader’s Digest, where the things are given in a different order, perhaps to better track Internet content thieves. And, yes, I do read Reader’s Digest. I am an old man.)

If You Thought Time Sheets Were Fun….

Tuesday, July 10th, 2012 by The Director

I used to work for a company obsessed with time sheet metrics. It went through three or four iterations of time sheet solutions while I was there, from Excel spreadsheets to a roll-your-own solution built from the ground-up to an off-the-shelf solution that required a bunch of customization before launch. Maybe that didn’t even actually launch when I was there. Maybe, instead, it launched after I was gone and then was replaced shortly thereafter with something else.

Yes, I understand the impulse to track as much as possible down to the minute, but when you’re in a multiple-customer, multiple-project environment where you’re switching between the clients and projects many, many times in a single day, you get a lot of signal loss in spending a couple minutes a day entering information into a time sheet for a couple minutes’ worth of actual work. Suddenly, you’re billing as long for time sheet entry as actual work. Or you’re filling up some non=billable catch-all bucket called “Administration” or “Non-Project” with minutes. Worse yet, if you’re switching tasks from crisis to crisis (sorry, I meant opportunity to opportunity) and you get to the end of the week with a time sheet that says you were only on the job twelve hours that week, you have to go all TSI on it, and forensically guess whether you spent six minutes or twelve minutes on that project on Tuesday.

Fortunately, or unfortunately, technology is bringing new solutions to bear:

Imagine how much better workers could do their jobs if they knew exactly how they spend their day.

Suppose they could get a breakdown of how much time they spend actually working on their computer, as opposed to surfing the Web. Suppose they could tell how much an afternoon workout boosts their productivity, or how much a stressful meeting raises their heart rate.

Thanks to a new wave of technologies called auto-analytics, they can do just that. These devices—from computer software and smartphone apps to gadgets that you wear—let users gather data about what they do at work, analyze that information and use it to do their job better. They give workers a fascinating window into the unseen, unconscious little things that can make such a big difference in their daily work lives. And by encouraging workers to start tracking their own activities—something many already are doing on their own—companies can end up with big improvements in job performance, satisfaction and possibly even well-being.

Frankly, that could be helpful, I suppose. Or it could be maddening from the point of view of the actual worker.

The key word here is encouragement. It is not the same as insistence. Bosses should be careful to stay out of workers’ way, letting employees experiment at their own pace and find their own solutions. They should offer them plenty of privacy safeguards along the way. Too much managerial interference could make the programs seem like Big Brother and dissuade workers from signing on. There’s a big difference between employees wanting to measure themselves, and bosses demanding it.

So which do you think it might fall out in most places?

Yeah, me, too.

Other Leadership Lessons from Another Sector

Monday, June 4th, 2012 by The Director

Here at QAHY, we have touched upon testing lessons from Genghis Khan, management lessons from Attila the Hun, and have alluded to some leadership secrets from the founder of SEAL Team Six, but there’s one place we’ve not looked for inspiration until now.

The Banana Man.

You’ll have to go to the Wall Street Journal‘s Five Lessons from the Banana Man, an article derived from the forthcoming book The Fish That Ate the Whale: The Life and Times of America’s Banana King, for that.

The Rutger Hauer School of Software Testing

Wednesday, March 14th, 2012 by The Director

As I mentioned on Twitter, I’m a member of the Rutger Hauer school of software testing. The Rutger Hauer school of software testing (RHSoST) focuses less on processes and procedures and more on how to wreak havoc using a varied set of tools upon a system or application regardless of its plot, I mean, its business rules.

But here are some of the primary texts of the school:

  • Introduction:
    Beyond Justice. The basic primer in software testing describes how to create user scenarios to test systems, how to understand and work within and without established processes and procedures, and how to turn erstwhile enemies into allies.
  • Exploratory Testing, Basic:
    Blind Fury. Even when you lack basic knowledge about a system or insight into the business rules or considerations, you can still cause damage find defects with your sword basic set of test cases that apply to any application.
  • Exploratory Testing, Advanced:
    Blade Runner. As your knowledge of applications grows, you can find more complexity and higher levels of business rules to test until the final deadline.
  • Load Testing:
    Escape from Sobibor. Learn how careful planning and execution of load tests can find the weaknesses in and actually crash the most rigid set of rules and constraints in an application.
  • Career Planning: Working in a Large Corporation:
    Deadlock. Learn how to find a payoff even when constrained by an explosive device bolted to your neck, figuratively speaking (and literally).
  • Career Planning: Working as a Test Consultant:
    Hobo with a Shotgun. This text deals with the itinerant tester and the challenges he/she faces with each new engagement, including how one fits in–or does not fit in–with the existing culture and how one can test effectively and efficiently on the run.

Rutger Hauer on the end of a project and the knowledge lost when a test consultant or team member moves on:

These are some of my favorite texts in the RHSoST. Undoubtedly, some of my fellow school members have their own. Don’t be afraid to share in the comments.

The Only Management Lesson You’ll Ever Need

Monday, March 12th, 2012 by The Director

Five Management Lessons From James T. Kirk

In your QA circles, you’ve got your Picard leaders, who confront a problem by calling a meeting, and you’ve got your Kirk leaders, who confront a problem by besting it in combat that somehow leaves the Kirk leader’s uniform torn.

Book Report: Rogue Warrior by Richard Marcinko with John Weisman (1992)

Wednesday, March 7th, 2012 by The Director

Book coverThis book is the autobiography of Richard Marcinko, the man who organized SEAL Team Six. It recounts his history from his days as a lowly enlisted man in the United States Navy and his rise through the ranks as he becomes an officer, a leader, and commander.

So what? you might ask. I’ve read a bunch of books about testing, I’ve read a couple of books about managing, but I’ve never really read a book that captures a career path that mimics the one in software testing.

You start out bucking the system, complaining about the Man, and fighting hard to get quality. Eventually, if you get promoted to team lead and beyond, you have to subvert that fighting instinct to recognize the new environment and to work within its limitations to further your goals and missions.

Marcinko goes from a platoon leader who goes around the leadership he doesn’t like to being a ramrod straight commander of a SEAL team. He was to play the political game a bit and know how things are done in the Navy. When he gets an opportunity, he gets to form his own team, SEAL Team Six, in his own vision–which is closer to snake-eating SEAL grunt than ship-driver (that is, a commander that comes from a different milieu). Marcinko ends up training with his men even when he’s a high-level executive.

Definitely some interesting lessons in this book, but as it is his autobiography and it’s written from the point-of-view of a long time military man, the language is pretty vulgar and the outlook a bit crude. However, Marcinko has written two books that have his picture on the cover in suits and probably don’t have quite as many f-bombs: Leadership Secrets of the Rogue Warrior and The Rogue Warrior’s Strategy for Success.

Or, if you want some more sedate reading, you could pick a book off of James Bach’s recent list, but there’s probably not as much shooting in them.

Books mentioned in this review:

But That’s Not Why QA Hates You

Wednesday, February 1st, 2012 by The Director

Over at, Susannah Breslin posts This Is Why Your Employees Hate You.

Basically, here three order list points boil down to 1)You’re hired into a new company and don’t get the lay of the land before you start making a mess, 2) You’re unlikeable, and 3) You are not a leader.

As you might know, I think #1 is very important, and I’ve harped on it on occasion here. When you’re hired in as a manager, you have (or have convinced someone that you have) skill and ideas applicable to leading people in doing whatever you’re managing. You might have led a team in some other industry doing something similar, or you might even have been working within the same industry for a competitor or some related organization. Be that as it may, you don’t know how things are done in your new organization, and until you do, you should probably avoid upsetting the apple cart with your new ideas and processes which are really only old ideas and processes that might have worked at your last employer. At your new posting, some things are done that way because they’ve always been done that way, but some things are done that way because they work for your new employer and new employees. Until you can tell them apart, you don’t know where your new ideas are improvements or impediments.

As to number 2, remember, lads and lasses, there’s a fine line between being a jerk and being confident and right. Regardless of which side of that line you’re on, people who don’t like you or what you’re saying will think and say you’re a jerk. So be professional, but be confident and tell people the hard truths. Clearly. Dare I say, bluntly? I DARE.

And for number 3, we’ve seen QA managers like this, haven’t we? Just glad to be sitting at the big table and unafraid to rock the boat. You’re not going to add anything dodging that responsibility, and when it comes time to trim budget, if nobody remembers you saying anything about anything, especially not saying anything that stuck up for anything, they’re going to wonder why you’re on the payroll in the first place.

So do what Ms. Breslin says. Or the opposite of what she says. You’ll be a better manager for it.

But know these are not the reasons QA hates you. QA hates you because QA hates everybody.

Management Lessons from Attila the Hun

Tuesday, December 20th, 2011 by The Director

If you’re looking to improve your management chops, emphasis on the chops, you can take some lessons from one of the legendary leaders of history: Attila the Hun.

I recently completed Attila: King of the Huns: The Man and the Myth, and that book offers these lessons from the reign of the warrior-king:

  • Build a team of diverse talents.

    As a ruler, Attila was an originator, in some respects a revolutionary. He clearly perceived that if the Huns were to become a great power, as he intended them to be, they must learn from other more advanced peoples. His own intimate circle of advisers, in consequence, consisted largely of foreigners.

    If you hire and promote only people who’ve worked in your business line or only in your particular methodology, you’re going to be bound to only insights and knowledge of those. If you hire from outside them, though, the foreigners might teach you something about what you’re doing that someone of your tribe would not innovate.

  • Let the farmers farm.

    When the Huns occupied a new territory large numbers of people fled before them, but the numbers of those who remained were larger still. Many of those who stayed were agriculturalists, and the Huns not only allowed them to continue to till the land, but encouraged them to do so.

    When you take on a new assignment or position, some turnover might occur as people leave to follow their mentors or because they feel that they, not you, should be the barbarian king of the tribe. Accept that. Those who stay have a lot of experience in the field. Don’t immediately overturn everything they do to conform to your new methods which might be informed and learned, but might not apply. Let those workers show you how they do things, and you can learn from them and, if appropriate, gradually increase the taxes introduce your improvements. Otherwise, more will fly, and you’ll lost a lot of knowledge with them.

  • Avoid the trappings of the title.

    ‘While sumptuous food, served on silver plates,’ he [Priscus] wrote, ‘had been prepared for the other barbarians and for us, for Attila there was nothing but meat on a wooden platter. He showed himself temperate in all other ways, too, for gold and silver goblets were offered to the men at the feast, but his mug was of wood.’

    In dress and general appearance also Attila was noticeably different from the others present. ‘His dress was plain, having care for nothing other than to be clean, nor was the sword by his side, nor the clasps of his barbarian boots, nor the bridle of his horse, like those of the Scythians, adorned with gold or gems or anything of high price.’

    If you’re too busy showing everyone you’re the leader, you’re not leading, you’re pillaging. Back when I was an actual Director of Quality and not merely a Director Emeritus, I had my cards say simply, “Quality Assurance.” Because my title wasn’t important, what I did was important. Plus, you get the respect of the blue collar grunts if you do like they do and live like they do. Or at least you get my respect.

  • Break something early.

    The wholesale destruction of a major town early in a campaign was a strategy adopted by Attila in both France and Germany. Metz recovered to become a city of importance. Aquileia did not. But the news of what happened in both places spread, as it was no doubt intended to, and the rulers of other cities duly took note.

    This is not to say you break the process or the methodology early, as I have advised against that above. However, every posting comes with some sort of deliverable, and the sooner after you take your position that you can create absolute havoc with it, the more the developers and other team members will listen to you when you explain how to avoid that in the future. Or maybe they’ll just fear you’ll do it to them, so they’ll be more careful. Either way, making that splash early can really ramp up your influence.

  • You don’t need a long contract or employment to make a lasting impression.

    Attila was sole King of the Huns for a mere eight years. In that short time the impact he made on his contemporaries was extraordinary. Much of this was due to his conquests. Eight years was a short period in which to hold both the Eastern and Western Empires to ransom with the threat of capturing and destroying both Constantinople and Rome, in addition to overrunning much of Germany and France.

    If you’re audacious and capable enough, you can make a lasting impression on an organization, its product, and its quality that will last long after you’re sacked for drinking kumis on the job on your third day. At the very least, they’ll remember the fermented mare’s milk.

Testing Candidates for a Sense of Humor

Wednesday, December 7th, 2011 by The Director

A short video explains how Southwest Airlines tries to determine if candidates for its open positions have a sense of humor:

Having a good drawing-and-quartering sense of humor (gallows humor is too humane for our line of work) will help one survive the software development industry. How important is it to you, and how do you go about finding it in candidates?

(Link seen here.)

As I Was Saying

Wednesday, November 16th, 2011 by The Director

Last night, this video about what motivates people made the rounds on Twitter:

It’s an interesting summation of Dan Pink’s book Drive: The Surprising Truth About What Motivates Us.

At first blush, you might think it does not agree much with my list of priorities with a job. My top item:

I want money. I’m not in this to change the world. I am a mercenary with a good skill set. I want a good paycheck. Also, they tell me benefits are important. But if you’re not going to offer me good compensation, I’m not going to work there.

The emphasis of the talk is on other things to empower and motivate people (autonomy, mastery, and purpose). But lower in hierarchy of needs remains money. From Dan Pink’s talk:

Fact: Money is a motivator at work, but in a slightly strange way. If you don’t pay people enough, they won’t be motivated. What’s curious about that, there’s another paradox there which is that the best use of money as a motivator is to pay people enough to take the issue of money off the table. Pay people enough so that they’re not thinking about money, and they’re thinking about the work.

Too many organizations are going to take away from that talk that money isn’t important and the other things will motivate employees to work for the company at a discount. Kind of like HR people trying to sell you that the staff bowling parties, free sodas, and great atmosphere of an organization is worth $25,000 in annual salary. It’s not the way to go, because other companies are going to catch on and start moving in this direction–so many have already–that underpaid employees (and employees who wonder if they’re underpaid) are going to wonder whether the grass would be just as green and the salary more green at that company up the road.

QA and the Maintenance Contract

Friday, June 11th, 2010 by The Director

Testy Redhead said on Twitter:

Never stop testing in production. You have to test the cloud, not just your code. Ken Johnston #bsadt

You know, that’s my motto, too. At my last full-time posting, I set my browser home pages to client sites so that I had to look at the sites by default every time I opened my browser. I ran through the sites every promotion with a basic set of regression tests. And I hounded the developers to make minor bug fixes, the stuff marked low or typo in the defect tracker, so that a low priority did not automatically mean it was resolved (wink, wink) as won’t fix without, you know, marking it so and leading to the firestorm of righteous QA indignation.


We could do that because we had a maintenance budget for these clients/sites/applications. Granted, we blew through the maintenance retainer because those retainers were set based on the assumption that the maintenance contract was pure profit after having a network admin make sure the machines were patched once every couple of months.

The point is, when your organization writes up its maintenance contracts, you should push to include as much QA and bug fixing time as you can to make the testing in production and the bug fixing palatable to the organization.

Otherwise, if the client writes a check and you’re done at product launch, you can test all you want and find a bunch of problems, but the rest of your organization will toussle your hair, chuck you on the chin, and ignore the whole business.

wordpress visitors