The Business Sensei

Controlling the Little Things

One of the more painful experiences I had in jujitsu was when my instructor taught finger holds. We assume that because our legs are generally quite strong, it would be difficult for someone to force us to go somewhere we don’t want to go. That assumption lasted as long as it took my instructor to apply a finger hold. All he had to do was take control of the smallest joint of one finger and suddenly my legs would go exactly where he wanted them to go. By manipulating one little thing, he could convince people much larger and stronger than he was to become extremely cooperative. Controlling one small joint gave him control over their entire body, however controlling the body did not produce the same control over the arms and legs: the hands and feet still moved freely, and would regularly engage in what may be politely referred to as “nose seeking behavior.”

Now, you might be thinking, “Well, so what? That’s just leverage!”

Well, yes, it is leverage. And if that was the whole point, the correct reaction would indeed be “so what?”

Leverage, as we all know, enables us to move something large through control of something small. Jujitsu is merely a fairly straight-forward application of this principle. However, the principle is not limited to the physical. Our perception of control is determined not by the big things in life that we control, but by the little things. To put this another way, if we want people to tackle big, challenging projects, we have to convince them that they have at least some control over the outcome; they have to believe that their actions matter and have a reasonably good chance of producing positive results. Conversely, when we don’t have control over little things, we tend to assume that we can’t control the bigger things. Even worse, that feeling of not having control translates into a loss of initiative and creativity. Leverage cuts both ways.

In any organization, those stressors that decrease our sense of control are thus the most damaging. Organizational politics are one obvious example, but at a more direct level, the less control employees have over their immediate environment, the less initiative they take overall. Being able to, within reason, decorate your office or cubicle creates a sense of control. Conversely, when companies have elaborate rules that unduly limit personal expression, control is seriously decreased. Without that sense of control, employees become more like the person whose finger is being twisted rather than like the person doing the twisting: they might be compliant, but they are not enthusiastic or committed.

An article in the NY Times discussed how Google addresses exactly this issue. Google doesn’t just allow employees to decorate their work area; employees get to design their work area. Google provides them with the equivalent of high tech tinker toys that employees can use to build the work area they want. Feel like having a treadmill? No problem. Walking desk? Sure. The article pointed out that Google doesn’t even have an official policy about coming in to the office; rather, the assumption is that the employee will work out a reasonable schedule with her team. This is control in action: employees are given control over their environment, even whether to come to the office to work. This control, coupled with making the office an very enjoyable place to work, leads to employees who exercise their control to work longer and harder than anyone could ever force them to work. Indeed, one of the problems Google has is that sometimes they have to chase people out of the office! What would you do to have problems like that?

When we have to force someone to do something, either through threats or through lavish rewards, they don’t get a sense of control or commitment. They are being controlled, but they are not in control. Now, if all we want is compliance, maybe that’s just fine! Indeed, if the task is easy, that may even be sufficient. However, if we want a committed, enthusiastic work force that believes themselves capable of tackling big projects and overcoming apparently overwhelming obstacles, the secret to getting there is to give them control of the little things.

When Goals Take Over

“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 most computers will run before crashing (or installing an update without warning). 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, speed 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.

So why were these teams so insistent upon solving the wrong problems? 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. At that point, once goals are set, they become the focus of everyone’s attention and a lot of work goes into accomplishing them. That is, after all, the best thing about goals; unfortunately, it can also be the worst thing about goals.

While clear, specific goals are certainly good things, goals also have to make sense. You need to have the right goals. 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 possible 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 the results you actually need.

Once goals are set, they have a way of taking over. What are you doing to make sure you don’t set goals before you know where you’re going?

Of Cats and Unwanted Prizes

I have three cats. Cats being the creatures that they are, I have only to sit down to read a book and instantly there is a cat on my lap. Regardless of which cat it is, a familiar pattern ensues: first, the cat carefully positions itself in front of my book. Once I adjust to move the book, the cat then carefully positions itself on one of my hands. This continues until I give the cat the attention it’s seeking. At that point, it first butts its head against me and then, purring loudly, turns and sticks its behind in my face.

I am sure that there are people who find this end of a cat absolutely fascinating. I’m even quite sure that there are contests in which cats win awards for having the most beautiful behind. For cat breeders and cat fanciers, it can be a big deal to win one of these cat trophies. It is a cause for great celebration.

In an office environment, however, a catastrophe is anything but a cause for celebration.

The worst thing about catastrophes is that they happen about as often as a cat sitting down on top of the book you’re reading. At least, to listen to some managers, it certainly sounds that way. Somehow, every little thing, every small problem, was magnified until it had the aura of impending doom. In short, every setback was becoming a prize for the cat with the most beautiful behind. At one company, the conversation went something like this:

“We’ve found a major bug in the software.”

“We can’t delay the ship.”

“We can’t ship with this bug.”

At that point, the manager started screaming that the product would go out on schedule, or else. When he finally calmed down and I was able to talk with him privately, he told me that he knew that if the company didn’t ship on time, the customers would abandon them and they would go out of business. He was happy to ship non-functional software to avoid that fate.

When he calmed down still further, he agreed to delay the ship.

I am sure that most readers are chuckling to themselves right now. After all, delays in software are legendary. Obviously, this manager was overreacting. True enough; the question is, why? Why would a perfectly sensible, intelligent man react so negatively to something which is, frankly, a common event in the software business?

It turns out that this particular company prided itself on holding to very aggressive schedules. The schedule was so aggressive that they were virtually always running behind. Therein lay the problem.

Time is a funny thing. We react very differently depending on how we perceive it. Being behind schedule all the time had the effect of generating a certain sense of urgency, which was the stated intent of the aggressive schedule. Unfortunately, the urgency generated in this situation was of the slightly breathless, heart-pounding sort similar to what one might experience if being chased by a very large cat of the “has a big mane” variety. A cat which, I might add, is looking to do more than just sit on your book.

The problem with aggressive schedules is that, in fact, being behind schedule can generate the same panicked response in people that they would feel in a situation which actually was dangerous. While in those situations, we’re very good at running away or fighting desperately, but we’re not good at making cool, rational decisions or developing innovative solutions to problems. Each pebble encountered along the road becomes a giant boulder. When we do finally get to the end of the project, rather than feeling a sense of accomplishment and success, there’s more of a sense of relief that at last it’s over. What’s missing is the thrill of victory that energizes people for the next project. That feeling of success is the key to getting, and keeping, people excited and motivated.

In short, instead of the team beating the schedule, the schedule was beating them.

Conversely, when a team is running slightly ahead of schedule, something very different happens. Running ahead of the game means that the team is feeling a constant sense of success. When people feel successful, they work harder, they are more creative, and they look forward to coming into work each day. Teams that are running ahead of schedule are more likely to develop innovative new solutions to problems rather than just slap on band-aids. Feeling that you have the time to stop and think is critical: just think about how easy it is to miss the obvious when you are feeling rushed.

The trick is to view your schedule as a living document. It’s something that you will constantly adjust according to the situation, especially at the beginning of a project. The less you know about potential difficulties down the road, the harder it is to plan: so don’t. Instead, plan to plan. As you move forward, you can revise and project the schedule further and further into the future.

If you find yourself running behind, that’s feedback. Pay attention to what it’s telling you. Is something more complicated than expected? Is someone overwhelmed with a task that turned out to be significantly more time-consuming than you thought? Did something go wrong? Is a vendor habitually late with parts? Is your schedule just plain too aggressive?

If you’re running ahead, that’s also feedback. It might mean that the schedule is too easy and your team isn’t being challenged. Be willing to become more aggressive. It could mean that you need to slow down: are people rushing and cutting corners? At one company, pressure on QA engineers to rush product inspections led to some very expensive and embarrassing recalls and some very irate customers. Moving way ahead of schedule could also mean that your team is working too hard too soon: success is a marathon, not a sprint. Burn out early and you won’t reach the finish line.

Leave the catastrophes to the cats.

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The McGraw-Hill 36-Hour Course in Organizational Development,” and “Organizational Psychology for Managers.” He is also a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

Controlling the Little Things

One of the more painful experiences I had in jujitsu was when my instructor taught finger holds. We assume that because our legs are generally quite strong, it would be difficult for someone to force us to go somewhere we don’t want to go. That assumption lasted as long as it took my instructor to apply a finger hold. All he had to do was take control of the smallest joint of one finger and suddenly my legs would go exactly where he wanted them to go. By manipulating one little thing, he could convince people much larger and stronger than he was to become extremely cooperative. Controlling one small joint gave him control over their entire body, however controlling the body did not produce the same control over the arms and legs: the hands and feet still moved freely, and would regularly engage in what may be politely referred to as “nose seeking behavior.”

Now, you might be thinking, “Well, so what? That’s just leverage!”

Well, yes, it is leverage. And if that was the whole point, the correct reaction would indeed be “so what?”

Leverage, as we all know, enables us to move something large through control of something small. Jujitsu is merely a fairly straight-forward application of this principle. However, the principle is not limited to the physical. Our perception of control is determined not by the big things in life that we control, but by the little things. To put this another way, if we want people to tackle big, challenging projects, we have to convince them that they have at least some control over the outcome; they have to believe that their actions matter and have a reasonably good chance of producing positive results. Conversely, when we don’t have control over little things, we tend to assume that we can’t control the bigger things. Even worse, that feeling of not having control translates into a loss of initiative and creativity. Leverage cuts both ways.

In any organization, those stressors that decrease our sense of control are thus the most damaging. Organizational politics are one obvious example, but at a more direct level, the less control employees have over their immediate environment, the less initiative they take overall. Being able to, within reason, decorate your office or cubicle creates a sense of control. Conversely, when companies have elaborate rules that unduly limit personal expression, control is seriously decreased. Without that sense of control, employees become more like the person whose finger is being twisted rather than like the person doing the twisting: they might be compliant, but they are not enthusiastic or committed.

A recent article in the NY Times discussed how Google addresses exactly this issue. Google doesn’t just allow employees to decorate their work area; employees get to design their work area. Google provides them with the equivalent of high tech tinker toys that employees can use to build the work area they want. Feel like having a treadmill? No problem. Walking desk? Sure. The article pointed out that Google doesn’t even have an official policy about coming in to the office; rather, the assumption is that the employee will work out a reasonable schedule with her team. This is control in action: employees are given control over their environment, even whether to come to the office to work. This control, coupled with making the office an very enjoyable place to work, leads to employees who exercise their control to work longer and harder than anyone could ever force them to work. Indeed, one of the problems Google has is that sometimes they have to chase people out of the office! What would you do to have problems like that?

When we have to force someone to do something, either through threats or through lavish rewards, they don’t get a sense of control or commitment. They are being controlled, but they are not in control. Now, if all we want is compliance, maybe that’s just fine! Indeed, if the task is easy, that may even be sufficient. However, if we want a committed, enthusiastic work force that believes themselves capable of tackling big projects and overcoming apparently overwhelming obstacles, the secret to getting there is to give them control of the little things.

It’s Not a Sprint, It’s a Hike up a Mountain!

Last summer, I had the opportunity to hike Algonquin. For those who are not familiar with Algonquin, which included me up until about two days before I climbed it, Algonquin is the second highest mountain in New York state. This translates to roughly 5100 feet, which may not be much by Sierra Nevada standards, but when actually doing the hike such subtleties swiftly become irrelevant. The trail up Algonquin starts at 2000 feet and climbs 3000 feet in 4 miles. There are a number of words for a trail like that; one of the less emotionally expressive ones is “steep.” The estimated time for the hike was 8 hours.

I have long believed the old adage that building a software project is a marathon, not a sprint. I was wrong. It’s a hike up a mountain. Consider that a marathon may be long, but it is basically predictable. You know how far you are going and exactly what the conditions will be along the way. When you get to the end, you’re done. Maybe it’s a big circle or there are busses waiting to take you home; either way, the finish line is the finish line.

Climbing a peak like Algonquin, however, is a different experience. At the base camp, the weather was sunny and warm, a typical August day. My wife directed my attention to the sign that said that the temperature at the peak was 40 degrees Fahrenheit, just a tad cooler. I hadn’t noticed that as my attention was on the sign that explained that no matter how beautiful the weather, sudden snow storms were still possible. Yes, even in August there are occasionally snow storms at and around the peak.

The trail itself started off very smooth and easy. My brother-in-law set a good pace, since we wanted to be up and down before dark. Assume one mile per hour, was what he told us. I was thinking that the trail wasn’t that hard, so why such a low estimate? Then we reached the steep part. Well, at least the part that seemed steep until we got to the really steep part. Then it got steeper from there. Suddenly, a mile an hour seemed optimistic.

See the connection to a software project yet?

Even a difficult project seems pretty manageable at the start. Sure, everyone talks about the inevitable rough patches, but no one really expects them to seriously derail the schedule. But then it gets steep; or, in other words, something turns out to be much harder or more complex than expected. Lack of planning? Not really; planning is important, but it can only take you so far. Sometimes you have to plan to not know something until you get there. Your plan needs to include how you’ll deal with that discovery.

I didn’t realize how steep the hike up Algonquin would be. But, I had a hiking stick and my wife was using poles. My stick was very useful; on one particularly wet and slippery section of rock, it nobly sacrificed itself to save my ankle. The, now much shorter, hiking stick was still useful in various creative ways on some other impressively inclined sections of the trail.

Preparation can seem pointless until you need it. If you haven’t prepared properly, your will to win won’t matter. That said, sometimes you also have to improvise and be willing to back up and try something different if your first idea doesn’t work.

Algonquin peak was beautiful. Despite the weather reports, it wasn’t nearly as cold up there as expected. No sudden snowstorms came rolling in. Of course, it was also only the halfway mark; we still had to hike back down. That didn’t stop us from having a picnic and enjoying the view; it’s important to celebrate successes along the way, even if you still have more to do. If you never stop and recharge, you’ll never maintain the focus necessary to reach the end. Hiking a wet, steep, trail, that can mean a blown knee or busted ankle; with software, it can mean endless delays, poor design decisions, and a buggy release.

In the end, our 8 hour hike took us closer to 10 hours. Fortunately, we’d started early in the day so we didn’t run out of light; if night had fallen, that would have been a serious problem. Although I did have a flashlight, I had neither a headlamp nor any desire to spend the night on the mountain. Leaving a little more time than you think you need is always a good idea; projects inevitably take longer than expected. Getting stuck on a mountain means a very long, unpleasant, and potentially serious delay; being too aggressive with your schedule can likewise trigger unexpected problems. Putting in some slush time prevents the unexpected from becoming the catastrophic.

As we finished the hike and emerged from the woods into the sunset, we were both exhausted and exhilarated. Algonquin is a tough hike; we celebrated with dinner at a very good restaurant. At the end of your projects, what are you doing to celebrate? No matter how dedicated people are and how much they enjoy the activity, there are sections that are just exhausting. Taking the time to relax and have some fun after the slog helps us appreciate our accomplishments and prepares us to tackle the next big challenge.

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Steve’s latest book, “Organizational Psychology for Managers,” sold out at Amazon.com two days after it was released. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

Thinking Success

This is an excerpt from my new book, Organizational Psychology for Managers.

“It was a terrible throw!”

This statement was made to me by a student in my jujitsu class. She then proceeded to elaborate on all the ways in which she had executed the throw incorrectly. Her partner, meanwhile, was patiently lying on the ground at her feet where she had thrown him. Observing this fact, I eventually commented that the throw couldn’t have been all that bad. After all, it had accomplished its primary objective: putting the other person flat on his back.

In jujitsu, it’s easy to perform a technique and then focus on everything wrong with it; after all, a technique can always be improved. The problem, however, is that when you focus on all the problems you lose sight of the big picture which, in this case, was that the technique was successful. Was there room for improvement? Of course there was. That room for improvement doesn’t change the basic success, unless we allow it to.

The same phenomenon happens in business all the time. After a grueling marathon of long days and late nights, the team finally ships the product. Rather than celebrate the release, they focus entirely on the bugs that didn’t get fixed, or the features that they didn’t have time to put in. In one rather egregious case, the director of engineering was busily berating his team for their “lousy” work even as the customers were singing their praises!

As we have discussed in a number of different contexts throughout this book, a focus on success is far more rewarding and, well, successful, than a focus on failure. When we only look at failure, we start to think of ourselves as failures. When we look at success, we think of ourselves as successful. Failure is depressing; success is exhilarating. When we feel like we’re failing, our willpower is wasted just forcing ourselves to keep going. We try to make things easier in order to feel a success, any success. When we are successful, we start setting our sights ever higher. Think about the motivation trap and the high performance cycle!

Riveting!  Yes, I called a leadership book riveting.  I couldn’t wait to finish one chapter so I could begin reading the next.  The book’s combination of pop culture references, personal stories, and thought providing insights to illustrate world class leadership principles makes it a must read for business professionals at all management levels.

Eric Bloom

President

Manager Mechanics, LLC

Nationally Syndicated Columnist and Author

What does lack of control do?

This is an excerpt from my new book, Organizational Psychology for Managers.

As we discussed earlier in this chapter, our own stress response is one of the signals that tells us that we are in danger. When we feel threatened, we look for the threat. If our attempts to identify the threat and make it go away fail, we first start to see the people in other departments as the source of the threat, and eventually our own colleagues as well. Fear is not that precise an instrument! In a very real sense, it doesn’t matter if we are physically afraid or afraid of being embarrassed or losing status, the reactions are the same. If anything, our fear of embarrassment or loss of face is often greater than our fear of physical harm!

Thus, when fear takes over, cooperation and teamwork suffer. People start to fight over little things, as they attempt to exert control over something. When we feel out of control, we seek to take control of what we can in whatever ways we can. When we don’t know what to do, we do whatever we can, whether effective or not, whether appropriate or not.

The Efficient Light Bulb: A Productivity Fable

This is an excerpt from my new book, Organizational Psychology for Managers.

Once upon a time, there was a light bulb. This light bulb was quite a remarkable light bulb: it was praised far and wide for its incredible efficiency. This light bulb gave off no waste heat. This light bulb did not contribute to global warming. It had no carbon footprint.  It did not rely on fossil fuels. Truly, it was an amazing light bulb and visitors came every day to see this remarkable light bulb.

One day, though, a traveler coming to see the light bulb in action was delayed by an unfortunate flood that closed several roads. He did not arrive until well after night had fallen. Much to his surprise, he found the light bulb sitting in a pitch dark room.

“Why aren’t you giving light?” asked the traveler.

“Give light!” replied the light bulb in shocked tones. “You must be joking. If I did that, I would use fossil fuels. I would have a carbon footprint. I would give off waste heat. I would no longer be efficient.”

“But isn’t the purpose of a light bulb to give light?” asked the traveler.

“I’ve always been told to be efficient,” replied the light bulb with a shrug. If you have never seen a light bulb shrug, it is truly a wonder to behold. The traveler would have been amazed, except, of course, that the room was too dark for him to see the miraculous event.

Once upon a time, there was a software company named “Soak, Inc.” Soak’s product relied upon a very complex database server. One day, the VP of Engineering stormed into the office and declared, “The server is too slow. We need to speed it up.”

From that day forth, every effort was focused on improving the speed of the server. Other issues were deemed insignificant beside the one, critical, goal of performance. Engineers who dared to raise other issues were publically humiliated for wasting the company’s time. Bugs that did not relate to performance issues were deemed “optional.” People who spent time reviewing the optional bugs and trying to fix them were warned that their insubordination would cost them their jobs if it did not cease immediately.

Eventually, Soak developed an amazingly efficient server. It was fast. It was robust. It was ready to demonstrate to potential clients.

The demo started out remarkably well. The server did not crash, causing some to believe that this couldn’t actually be a demonstration of a software product. Indeed, the server performed flawlessly. All would have gone well indeed for Soak had not someone noticed that the data being delivered by the server didn’t make sense. Yes, what the server had gained in performance it had lost in accuracy. In other words, it was incredibly good at very rapidly delivering useless or incorrect information.

When the engineers were questioned about this unfortunate oversight, they shrugged and replied, “We were told to be efficient.”

While it is not nearly as amazing to see an engineer shrug as it is to see a light bulb shrug, the effects are much the same.

At Soak, a goal was set, a metric for success was defined, and that metric became the sole determinant of progress. Goals are extremely powerful tools: the best thing about them is that you accomplish them. Unfortunately, sometimes the worst thing about goals is that you accomplish them. At Soak, they accomplished their goals. A dead light bulb is extremely efficient, but not useful. Similar observations can be made about the server.

Before leaping into setting a goal, especially a goal to solve a problem, it helps to understand the actual problem and to understand what the actual symptoms are. Rather than create useful goals, they fixated on a symptom. That did not, however, actually change anything.

At Soak , the VP stated that they were trying to solve the problems his company was facing as rapidly and effectively as possible. They were setting goals. They were Taking Action! Taking action is certainly helpful, but it is even more helpful to be taking the correct action. Since it’s not always possible to determine just what the correct action is, it becomes even more critical to listen to the feedback and questions from the people who are charged with actually executing the action. The engineers knew that something was wrong, but no one was willing to listen to them. As we will discuss shortly, a key aspect of successful goal setting is understanding the feedback you’re getting.

I realize that many of you reading this are probably chuckling to yourselves and thinking that this scenario could never happen at your companies. The folks at Soak said the same before, during, and even after it happened to them. The light bulb had no comment.

Productivity seems like such a simple thing. Somehow, though, it never is. As we have already discussed, cognitive shortcuts such as the Halo Effect can influence how productive we perceive someone to be. Ultimately, the only real way to measure productivity is through understanding goals and knowing how to construct goals so that they will actually get you what you want. Otherwise, you may just end up with a dead light bulb.

After it was released, Organizational Psychology for Managers sold out in two days at Amazon.com. Order your copy now.

Feedback Systems

This is an excerpt from my upcoming book, Organizational Psychology for Managers.

Feedback takes many forms. Equity, blame versus problem solving, and dealing with jerks provide feedback that tell people how the organization works and handles difficulties. In addition, there are the explicit feedback systems:

There is the feedback that people get that tells them how, and whether, the organization views them as people. This is feedback about the nature of the relationship between members and the organization as a whole.

There is feedback that goes up the organizational hierarchy, informing those higher up about conditions, the market, problems in the organization, and successes. This system often fails.

There is feedback in the form of performance reviews. Done properly, which rarely happens, performance reviews are very powerful and valuable to the organization: they provide a route by which members of the organization can grow, develop their skills, and build their status. They provide an important connection to the organizational narrative.

Relational Feedback

Psychologist Robert Cialdini observes that every culture has a social rule around favors: when someone does something for you, helps you, or gives you a gift of some sort, you are expected to reciprocate in some way. People who do not reciprocate, that is, those who take but do not give, are viewed as greedy moochers, and are often shunned by the rest of the society. Similarly, as Schein observes, those who give help but never accept it, are often viewed with suspicion or resentment.

In an organizational setting, people want to understand what sort of relationship they have with their coworkers, their boss, and with the more nebulous construct that is the “organization.” Reciprocity is one of the ways people explore that relationship. How the team and the organization handle reciprocity thus becomes a proxy for the relationship.

In early stage teams, people might refuse to accept help in order to avoid a feeling of indebtedness or incompetence, or might attempt to help another in the hopes of receiving help later or building status. In fact, for the team to be considered just and fair, there needs to be that mutual exchange of helping behavior in the early stages. Eventually, as the team develops, the mutual exchange of favors turns into a more abstract helping network in which team members automatically give and receive help as necessary to the accomplishment of the task at hand. It’s no longer about the individual ledger; rather, it’s the confidence that we will all engage in helping behaviors for the good of all of us. The trust that enables that to happen comes from demonstrating reciprocity in the early stages of team development.

Similarly, when members of an organization put forth an extra effort or engage in pro-organizational behavior outside the normal expectations, they expect that the organization will, in some way, acknowledge and repay their contribution. When the organization refuses to do that, or, even worse, treats the exceptional effort as “just part of the job,” this creates the image of someone who takes and takes but gives only grudgingly, if at all. For example, when employees work long hours or weekends in order to meet a deadline, they are sacrificing their personal time for the good of the organization. This is not, or at least should not be, a routine event. If it is, you have some serious problems!

How the organization responds to that sacrifice provides feedback on the relationship: reciprocity of some sort says that you are a valuable person; failure to provide reciprocity says that you are a tool or a slave, that the boss is selfish, that the organization does not value its members, or all of the above.

I’ve met many people who tell me that long hours are part of the job, and ask why they should thank or reward people for doing their jobs. The reason is simple: reciprocity is a proxy for the relationship, and the relationship determines trust. Without trust, motivation, team development, and leadership all start to break down.

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Steve’s latest book, “Organizational Psychology for Managers,” is due out from Springer in late 2013. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

Celebrate Progress

This is an excerpt from my new book, Organizational Psychology for Managers

One of the most important things you can do as a team is periodically celebrating progress. It is always more motivating to look at how far you’ve come rather than how far you have yet to go. Indeed, it’s more motivating to say, “we’re half done,” than to say, “There’s still half left to do.” The two statements may be mathematically equivalent, and IBM’s Watson, the Jeopardy playing computer, would probably find them identical. If you happen to be employing Watson, then it may not matter what you say. However, if you happen to be employing people, it matters.

In jujitsu practice, the students who always focus on how far off the black belt is tend to not finish the journey. Those who focus on how far they’ve come are the ones who keep coming back.
You don’t need to highlight individuals every time you do this; in fact, you shouldn’t. The goal is not to make anyone feel bad for not getting as much done as someone else; rather, it’s simply about sharing success. Feeling that the team is making progress helps boost everyone’s morale, increases team cohesion, and helps build trust.

Depending on your organizational culture, you can occasionally highlight individual accomplishments in much the way that some sports teams will highlight most valuable players. It’s important, though, to pay close attention to how people work and what they expect. At Atari, a new CEO tried to transform the highly collaborative, team-based culture into a more individual, competitive culture. He focused heavily on “engineer of the week,” and other such awards. However, engineers at Atari viewed game development as a collaborative process, where everyone worked together to produce a quality product. The focus on individual performance shattered the team structure, turning high performance teams back into struggling level one groups. Atari never recovered.

When you celebrate team successes, you build relationships, strengthen competence, and provide the trust necessary for greater levels of autonomy. Success builds on success just as failure feeds on failure. What you focus on is what you get.

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Steve’s latest book, “Organizational Psychology for Managers,” is due out from Springer in late 2013. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.