The Business Sensei

Make A Decision!

“Daddy, can I have that?”

As the holidays approach, a familiar refrain is heard. More common than Jingle Bells or other traditional Christmas music are the unending requests from children for various toys. Even for those who do not have young children, there is the pressure of deciding what gifts to get for family and friends. Indeed, in one sense, the parents of young children have it easy: their kids are at least telling them what they want. Of course, if all the kids got all the toys they asked for, we’d be able to pay off the national debt about fifty times over. Since very few people have that sort of money, a certain level of decision making still needs to take place.

Although web-based retailers have certainly removed a great deal of the terror normally associated with holiday shopping, nonetheless it remains an oddly exhausting activity. An hour of shopping on Amazon.com may not leave us battered, bruised, or pepper-sprayed by over-eager shoppers, but it can still leave us feeling like our brains have turned to jelly and are dripping out our ears. Not only does this lead to some very odd looking stains on our shoulders, it can also be very hard to focus on much of anything else. Attempting to put off the e-shopping is even worse. In many cases, the effort of not shopping can be more exhausting than the shopping itself! When it finally happens, the shopping experience is all the more, let us say, poignant.

So what is going on here anyway? How can a few mouse clicks be so draining?

As psychologist Roy Baumeister and John Tierney explain in their book, “Willpower,” the act of decision making is oddly tiring. The more important the decision feels the more exhausting it is. When it comes to buying gifts for family and friends, well, the level of import often feels insanely high. Even worse, the more decisions we make, the harder the next one becomes. Eventually, we hit the point where we start making really bad decisions, such as deciding to go to the store at the last minute: even for those of us who are comfortable and familiar with the Internet, going to a bricks-and-mortar store often remains a natural and reflexive action no matter how utterly crazy the experience actually is. Worst of all: we don’t even realize how bad our decisions are becoming; all we know is that everyone around us is simply getting more and more unreasonable and the information we’re looking at more and more poorly written. Well, at least it appears that way and will only get worse when you’re experiencing decision fatigue. When our brains get tired, they start taking shortcuts, such as reverting to non-decisions such as “I’ll deal with it later,” or reckless ones such as buying our kids that “Build a killer robot” kit, complete with working death ray and nuclear reactor.

When it comes to buying presents, this once a year experience, nightmarish though it may be, is ultimately not all that big a deal. Sure, it may feel that way at the time, but ultimately it generally works out, albeit with the occasional bizarrely ugly sweater or killer robot along the way. In a business environment, however, this sort of decision fatigue can be both subtle and costly.

It turns out that there are two types of decisions that are particularly difficult. Coincidentally, they are also the types of decisions that arise quite frequently in businesses, at least those that involve more than one person. These two types of decisions are those involving compromise or negotiation and those involving innovation and trying out new ideas or ways of doing things.

The fact is, compromise and negotiation are relatively rare skills in the animal world. Outside of Tom and Jerry, I’ve never seen a cat negotiate with a mouse. When dogs and cats compromise, it usually involves one of them running up a tree (lest there be any confusion, it’s usually the cat). Even for people, compromise is surprisingly difficult at the best of times, not just when the old Christmas spirit is sapping our self-control.

Now, I am often told that compromise and negotiation is something that certainly managers and salesmen need to do, but what about everyone else? How much compromise and negotiation really takes place in an office? Quite a lot. Brainstorming, problem solving, group discussions all involve compromise and negotiation. So does simply dealing with life in the world of cubicles. When everyone is suffering from decision fatigue, it becomes much harder to work with other people. Little things become major irritants simply because it’s that much harder to shut them out.

Innovation and trying out new ideas run into trouble for much the same reasons. There is a much greater tendency to let problems fester or to accept those natural and reflexive solutions, the solutions that we don’t really like but which are familiar and oddly comfortable despite the actual unpleasantness they bring. In other words, the functional equivalent of going to a large department store, tired and grumpy children in tow, on December 23^rd. At least in that case you get to join all the other people who are doing the same thing.

Fundamentally, new ideas are particularly difficult to accept when we’re suffering from decision fatigue. Meetings to address what should be simple problems can drag on for hours and, at the end, no one can actually make a decision. This only increases the frustration level.

So what can be done to avoid these problems?

As many an endurance athlete has told me, “Eat before you’re hungry, drink before you’re thirsty.” In other words, don’t wait until you’re feeling grouchy and out-of-sorts to get a healthy snack (or even an unhealthy snack, though the benefit doesn’t last nearly as long). If you wait, you’re already making bad decisions and it can take a long time to get your brain back on track. Athletes who wait too long to eat or drink suffer from rapid performance collapse, and getting hit with decision fatigue is very similar. The major difference is that an endurance athlete whose performance collapses knows it. With decision fatigue, we don’t always realize just how drained we are until the next day when we ask ourselves, “How could I have been so stupid?”

Next, take breaks. They don’t have to be long, but getting out of the office for a few minutes to take a walk or get a snack can do wonders to replenish our mental energy before we start making bad decisions.

As the old adage goes, make haste slowly. If you do have to make a major decision, sleep on it. Make it first thing in the morning when you’re fresh, not at the end of the day. If you’re running a meeting, separate any decision making from the rest of the meeting. Take a long break before making any decisions or, again, if possible wait until the next day. Finally, recognize that everyone is always a little distracted at this time of year. Take that into account in your planning. It’s a lot more productive to build a little extra time into the schedule than to have to go back and fix bad decisions.

Making good decisions and getting along with our coworkers can be hard enough at the best of times. Don’t let the holiday spirit make it harder.

My Hovercraft is Full of Eels

As published in Corp! Magazine

“Is the product done?” a certain manager asked during a product review meeting.

“It is done,” replied the engineer building the product.

“Are there any problems?”

“There are problems.”

“What is the problem?”

“It does not work.”

“Why doesn’t it work?”

“It is not done.”

I will spare you the transcription of the subsequent half hour of this not particularly funny comedy routine. The manager and the engineer managed to perform this little dance of talking past one another without ever seeming to realize just how ludicrous it sounded to everyone else in the room. It was rather like Monty Python’s classic Hungarian-English phrasebook sketch, in which translations in either direction are random. In other words, the Hungarian phrase, “I would like to buy a ticket,” might be translated to the English phrase, “My hovercraft is full of eels.”

It was extremely funny when Monty Python performed it. As for the manager and the engineer, well, perhaps they just didn’t have the comedic timing of Python’s John Cleese and Graham Chapman.

As it happens, “my hovercraft is full of eels” moments come about far too often. What was unusual in this situation is that it involved only two people. Usually, considerably more people take part. Thus, instead of a not particularly amusing exchange between two people, there is an extremely frustrating exchange involving several people. The most common failure to communicate is the game of telephone: as the message passes along the line, it becomes increasingly distorted.

What I hear from teams over and over is, “We are communicating! We send email to everyone.” This is where the hovercraft starts to fill with eels. Broadcasting is not really communicating: effective business communications require a certain amount of back and forth, questioning and explaining, before everyone is on the same page.

Who talks to whom? When you send out an email, do questions come back to you? Or do people on the team quietly ask one another to explain what you meant? While it’s comforting to believe that every missive we send out is so carefully crafted as to be completely unambiguous, very few of us write that well. Of that select few, even fewer can do it all the time. Particularly in the early stages of a project, if there are no questions, then there are certainly problems.

When someone else asks a question, either via email or in a meeting, does everyone wait for you to respond? Even worse, does Bob only jump into a thread if Fred jumps in first? Who is Bob responding to at that point, you or Fred? Are you still addressing the main topic or is the hovercraft starting to become eel infested?

It can be extremely frustrating to ask, “Are there any questions?” and receive either dead silence or questions about something trivial. It can easily become tempting to assume that there are no questions and just race full speed ahead. However, until employees figure out how much each person understands about the project and how you will respond to apparently dumb questions, they will be cautious about what they ask. Their curiosity is as much about one another and about you as it is about the project. How that curiosity gets satisfied determines whether you have productive conversations or a hovercraft that is full of eels. In the former case, you get strong employee engagement; in the latter case, you don’t.

If you’ve been working with a team for some months, or longer, and people are still not asking questions then there are really only two possibilities: either your team is composed of professional mind-readers or you are about to find a room full of those pesky eels. No project is ever perfectly defined from the beginning. Questions and debate should be ongoing throughout the development or production cycle. A lack of questions tells you that there is a lack of trust between the team members and between the team members and you. When trust is lacking, so is engagement.

Now some good news: remedying that lack of trust isn’t all that complicated. It does, however, require a certain amount of persistence and patience.

Start by highlighting each person’s role and contribution to the project. Why are they there? What makes them uniquely qualified to fill the role they are in? Be specific and detailed. If you can’t clearly define their roles, you can rest assured that they can’t either.  Questions come when people are clear about their roles. Disengagement comes when people are not clear about their roles.

Prime the pump with questions. Demonstrate that you don’t have all the answers and that you need the help of the team to find them. Give each person a chance to play the expert while you ask the dumb questions. When you set the tone, the others will follow. Communications start with the person in charge.

Separate producing answers from evaluating answers. Collect up the possibilities and take a break before you start examining them and making decisions about them. Brainstorming without evaluating allows ideas to build upon one another and apparently unworkable ideas to spark other ideas. Pausing to examine each potential answer as it comes up kills that process.

Encourage different forms of brainstorming: some people are very analytical, some are intuitive, some generate ideas by cracking jokes, others pace, and so on. Choose a venue where people are comfortable and only step in if the creative juices start to run dry or tempers start to get short. In either case, that means you need to take a break.  Intense discussions are fine, heated discussions not so much.

Initially, you will have to make all the decisions. That’s fine, but don’t get too comfortable with it. As trust and engagement build, the team will want to become more involved in the decision making process. Invite them in: that demonstration of trust will further build engagement and foster effective communications. Effective communications, in turn, builds trust and engagement.

Having a hovercraft full of eels isn’t the real problem. The real problem is what a hovercraft full of eels tells you about the trust, engagement, and communications in your company.

Thoughts on multitasking

When we multitask, we force our brains to continuously move information around. Ever notice how your computer starts to slow down and the disk light flashes more when you have a lot of apps open? The computer has to constantly rotate information from the hard disk to RAM depending on which app you’re using. Our brains are very similar. Unlike computers, however, which never get tired, our brains very quickly get tired.

Another problem is that our brains are built to remember uncompleted tasks. As we start to stack up uncompleted tasks, more and more of our mental computer becomes engaged in tracking the uncompleted tasks, leaving less available to deal with the problem in front of us.

The net result is that multitasking brings about a short-term pop in productivity, for maybe a couple hours (if that), but productivity swiftly declines after that. Unlike other skills, which improve as we use them, our performance while multitasking does not improve: instead, our ability to concentrate on a problem may actually decline because we develop the habit of switching too often and too soon.

An office with a lot of multitasking is almost always one in which work flow and office routines are not well developed or thought out. Most so-called emergencies aren’t.

So how is that some people (e.g. athletes) appear to do multiple things at once? If you practice something until it becomes second-nature, then you can appear to multitask. The key is that the practiced activity no longer takes any appreciable amount of concentration: think of it as a body macro. However, like macros they are hard to interrupt, change on the fly, or pick up in the middle if you do get interrupted.

Who Betrays One Master

A nervous looking man in a suit slips furtively through the streets of an unnamed city. He comes to an office building and, checking to make sure that he isn’t being watched, slips inside. There, another man greets him.

“Do you have the plans?” the second man asks.

“Do you have the money?” replies the first.

Perhaps they haggle for a moment, but then the second man hands over the money and the first man hands over an envelope. The second man glances into the envelope.

“I see you kept your word.”

“You earned it,” replies the first man as he turns to leave.

“No,” says the second, as he pulls a gun and shoots the first man, “I bought it.”

“I betrayed my company for you! I proved my loyalty.” gasps the first man, as he falls to the floor.

The second man looks down at the body on the floor and says, “The man who betrays one master will assuredly betray another.”

If this scene sounds familiar, it probably is. Some variation of it appears in hundreds of movies, from James Bond to WWII action films to fantasy adventure. The trope is a simple one: a man betrays his country, company, organization, or teacher. The person to whom he sells out reaps the rewards, but never believes the traitor’s protestations of loyalty to his new masters. Eventually, it ends badly for the traitor.

Now, if this scenario were only a work of fiction, there would be little more to say. Unfortunately, the fictional part is the end: in real life the disloyal person is rewarded and given every opportunity to betray his new masters.

Read the rest in the Journal of Corporate Recruiting Leadership

A Tale of Two Light Bulbs

As published in the CEO Refresher

Using the Force: What Every Exec Can Learn from Darth Vader

As published in the Worcester Business Journal

My 6-year-old son is seriously into Star Wars. As we were watching the movies recently, he turned to me and asked, “Why is Darth Vader such a mean leader?”

Coming from a kid who thinks the Sith are kind of cool, the question took me by surprise. On the other hand, it’s rather heartening to see that even a small child can recognize bad management. Of course, the real question is not what makes Darth Vader such a bad leader. After all, when you’re the Dark Lord of the Sith, you don’t really need a reason. More aptly, the question is: What does it take to be a good leader?

No Intimidation

First, we have to dispense with the primary weapon of the Sith: fear. Darth Vader rules through terror, but the fact is, you don’t need to have the power to choke people to death using the Force to create a climate of fear. Fear is very effective at getting people to move away from something. In the practice of Jujitsu, fear of injury is often quite sufficient to convince an attacker to dive headfirst into the ground or into the nearest wall. Some mistakes are a natural part of doing business. When people are shamed for making mistakes or threatened with loss of their jobs if they don’t measure up, they become less creative, less dedicated and errors are not corrected.

Team Spirit

To be a positive leader, the first step you need to take is to focus on affiliation. You might also think of it as team spirit. When people come together to form a team, the first thing they do is look for common ground. To really create affiliation, the leader needs to actively get to know his team members and encourage them to get to know one another.

Independence

Next is building autonomy. Perhaps counter-intuitively, autonomy is the result of having structure. Structure lets each team member know what the others are doing well enough to trust them when they aren’t visible. That trust is what permits autonomy.

Lack of structure is chaos. Too much structure is stifling. For example, when an employee comes up with a good idea and your response is to ignore them, that is too little structure. When you say, “Good idea! Here’s how we can make it better!” that’s too much structure. Appropriate structure is to say, “Great idea! How did you come up with it?”

Great Expectations

Competence is not just hiring competent people. It’s creating an atmosphere of competence. Nothing succeeds like the expectation of success.

Managers can motivate employees in one of two ways: you can focus on failures, and make dire predictions about what will happen if employees screw up; or you can focus on success, and remind the employee of the things they did well.

The keys to great leadership are: get away from fear, build affiliation, create structure to enable autonomy, and craft an atmosphere of competence.

The hard part is finding the right balance for your team and your company. Start slowly and let yourself accelerate as you learn to use these techniques effectively. You’ll soon be amazed at how fast you’re going.

The Engines Cannae Take Much More…

As published in the CEO Refresher

Imagine for a moment Mr. Scott giving his famous, “Captain, the engines cannae take much more of this,” line and Kirk responding, “No problem, Scotty. You take a break and I’ll fix the engines.” Even for Star Trek this would be ludicrous. Kirk may be pretty smart, but he’s not the master engineer that Scotty is. It makes no sense for him to try to do Scotty’s job; that’s what he has Scotty for. Oddly enough, Star Trek is one of the few places where this scenario never happens.

Where does this scenario play out? In far too many businesses. I am always fascinated when a manager tells me that he would never ask his employees to do something that he couldn’t do. What is the point of having a team? A team that limits itself to the abilities of the leader is not really a team. It’s a group of henchmen who may be good at carrying out instructions, but who are not capable of achieving high levels of creativity or performance. It would be like Kirk refusing to order Scotty to fix the engines because Kirk can’t do it himself.

In an effective team, the abilities of the team are greater than the sum of the individuals. It is the capacity of the team to work as a unit, to be able to put the right person or subset of people in the right place to deal with problems that makes the team strong. Fictional though they are, the crew of the Enterprise is an effective team exactly because they know how to put the right people in the right place at the right time. While it certainly helps to have a cooperative script writer, the fact is that the level of teamwork that they demonstrate is not fictional at all. It is something that all teams can achieve, for all that barely one in five actually do.

To bring this into the real world, or at least as real as the software industry gets, I worked once with a software company that had the idea that every engineer should become expert in every other person’s code. Unfortunately, this was a fairly large project and the different pieces required different areas of highly specialized knowledge. Each of the engineers had spent many years building up that expertise and could not simply transfer it to every other engineer. While having partners working together makes a great deal of sense, trying to have everyone doing everything is self-defeating. It sacrifices the benefits that come from applying specialized knowledge to specific problems.

However, this was not nearly as dysfunctional as the suggestion by one senior manager at a high tech company that part of having everyone in the company better understand one another’s jobs, each person should spend time doing each of the other jobs. When it was pointed out that engineers are not always the most socially adept people, and that perhaps having the engineering team trying to market to customers wasn’t the best choice, his response was, “Then they need to learn.” When it was pointed out that marketing and sales professionals, talented as they are, generally are not trained engineers, he had the same response. Fortunately, wiser heads prevailed: while those engineers who wanted to become more involved in customer facing activities were given the opportunity to do so, the engineers did not end up trying to sell the product and the sales force did not end up attempting to build it.

Now, the fact is, this manager did have a point. Helping people to become more knowledgeable about one another’s jobs is important. If you understand just a little about what other people are doing, you have a much better sense of what is a reasonable request and what is not, what you can do that will help them accomplish their jobs, and what you can do to help them to help you do your job.

So how do you develop that level of mutual helping? Different people bring different skills to the project. The more people can get to know one another, to appreciate the perspectives, experiences, and ideas that each one brings, the more they will start to come together as a team. The leader needs to set the example that asking for help is not a sign of weakness and accepting help is not a sign that you can’t do your job. It is exactly because you have multiple perspectives and approaches, multiple skill sets and ideas, that the team becomes strong.

The leader can do this by, well, leading. Not by ordering or threatening or attempting to coerce people, but by demonstrating the behavior that he wants other people to engage in. The leader must be the first one to acknowledge that the reason there is a team in the first place is because the leader can’t do it all himself. If he could, why is anyone else there? Whether it’s Captain Kirk trying to run the Enterprise single-handedly or one man trying to play all nine positions on a baseball team, a leader who can’t accept help is not a leader.

What are you doing to help your team members help you?

Of Deck Chairs and Ocean Liners

As published in The CEO Refresher

“Just give me the numbers!”

Falling firmly into the “I just can’t make this stuff up” category, the preceding statement was made by the head of a certain engineering department. He wanted the performance figures on a series of database lookups so that he could determine if the database code was performing up to specifications. This would be a perfectly reasonable request except for one minor problem: the database code was not producing the correct results in the first place. Performance was sort of irrelevant given that getting the wrong answers quickly is not necessarily all that helpful, although it may be less irritating than having to wait for the wrong answers. It’s rather like driving at 75mph when lost: you may not know where you are or where you are going, but at least you’ll get there quickly. Or something.

In another example, the engineers developing a bioinformatics data analysis package spent all their time arguing about the correct way to set up the GUI elements on each page. The problem was that when they actually ran one of the calculations, the program appeared to hang. In fact, I was assured by everyone, it just “took a long time to run.” How long? The answer was, “maybe a few weeks.”

This may come as a shock to those few people who have never used a PC, but a few weeks is generally longer than either a PC or a Mac will run before crashing. Besides, the complete lack of response from the program regularly convinced users that the program had crashed. The engineers did not want to put in some visual indicator of progress because they felt it wouldn’t look good visually. They refused to remove that calculation from the product because “someone might want to try it.” Eventually, they grudgingly agreed to warn the user that it “might take a very long time to run.”

In both of these cases, the team was solving the wrong problem. Although there were definitely complaints about the speed of the database, that was very much a secondary issue so long as the database wasn’t producing correct results. And while the user interface decisions were certainly important, designing an elegant interface for a feature that will convince the user that the product is not working is not particularly useful. At least rearranging the deck chairs on the Titanic was only a waste of time. It didn’t contribute to the ship sinking.

The element that made each of these situations noteworthy is that in both cases there were people present pointing out that the wrong problems were getting all the attention. The people making the decisions didn’t want to hear that. They wanted to solve a certain set of problems and, by golly, they were going to solve them! This is a version of the Hammer syndrome: when all you have is a hammer, everything looks like a nail. Sometimes, though, that nail turns out to be a thumbnail.

So why were these teams so insistent upon solving the wrong problems? Fundamentally, because they could. Simply put, if you give someone a problem they can solve comfortably, and one that they have no idea how to approach, they will do the former. In addition, they had never established clear metrics for success, never established standards by which they would know if the database was fast enough or the user interface was good enough. As a result, they built their goals and evaluated their performance around those issues. They were not being evaluated on whether they got the right answer, despite the opinions that the customers might have in that regard.

While clear, specific goals are certainly good things, goals also have to make sense. When a company is constantly seeing flaws in its products, it can be a very valuable exercise to look at the goals assigned to each person and each team in the company. Do those goals make sense? What problems or challenges are they addressing? Are the goals complementary, or are there significant gaps? If the engineering team is being evaluated on how many bugs they can fix and the QA team on how many new bugs they can find, what happens to the step where fixed bugs get verified? If no one is responsible for that happening, it won’t get done (and didn’t, in several software companies!). If the team focuses on the wrong problems, they’ll spend their time fighting symptoms or revisiting solved problems, and never deal with the real issues.

Therefore, even before you can set goals, you have to know what the problem is that you are trying to solve. That means first separating the symptoms of the problem from the problem itself. The symptoms are only symptoms; frequently, they can point to many possible problems. It’s important to look at the symptoms and brainstorm which problems they could be indicating. When you start developing solutions, you then need to ask what the final product will look like if you go ahead with your solution and you need to know what success looks like. Make sure that your proposed solution will actually solve at least some of the potential problems you’ve identified, and develop some way of testing to make sure you are solving the correct problem. In other words, have some checkpoints along the way so you can make sure that you’re actually improving things. Only then can you start to set goals that will effectively guide you to producing a quality product.

What are you doing to make sure that you are not rearranging deck chairs on the Titanic?

When the Fat Tuesday Sings

As published in the CEO Refresher

I Told You: 360-Degree Feedback Done Right

“We were thinking of doing a 360-degree feedback to help him understand what other people think.”

This very frustrated comment was made to me recently regarding efforts to explain to a very senior manager that his style of leadership wasn’t working for his team. At that point, all efforts to convince him to change were foundering on the manager’s simple perception that things were working just fine.

Such being the case, it’s hard to imagine how a 360 can help. Sure, he might find that his subordinates don’t like him very much, but he might also feel that his job isn’t to be liked, but to get people to perform.

Read the rest at LabManager Magazine.