The Business Sensei

It Takes a Process

Large projects can be very intimidating. It’s easy to feel like you are standing at the foot of a very tall and imposing mountain. Working on the project can easily overwhelm even very talented people. It can be hard to feel like you’re making progress when there’s always a lot to do and when it feels like problems are constantly cropping up. When you climb that mountain, it can often feel like there’s always fog ahead of you and behind you so that you can’t see how far you still have to go and you can’t tell how far you’ve come.

When I decided to write my first book, I didn’t jump in and start writing. Even though I’ve executed some very large projects, my first step was to learn a process for writing books. In this case, the process I used came from someone who had written over two dozen books, so I figured he had some clue what he was talking about. I subsequently modified the process by bringing in some of the lessons I’d learned from other complex projects and adjusting it to suit my personal style and to correct a few short-comings.

The trick with processes is that they serve to organize and simplify complex operations. They create structure. Writing a book is complex: there are a lot of moving parts. If nothing else, keeping track of the chapters, what’s ending up in each one, making sure there are no contradictions, that something mentioned in an earlier chapter is followed up on later, and so forth, can easily become nightmarish. However, using an organized system turns that nightmare into routine. Other projects have their own headaches that can by managed by having the right processes in place.

Processes, however, often feel awkward and alien when you’re first learning them. This is like the student in my jujitsu class who once said to me, “I’d never do that technique. It doesn’t feel natural.”

Of course it didn’t feel natural, he hadn’t practiced it! Processes are the same. They rarely feel natural at first. You have to get used to them. Processes also serve both logistical and psychological functions.

From a logistical perspective, a process serves as an organizational structure for projects that have a lot of moving parts. When designed well, the process captures the moving parts, or at least provides a way of making sure that they don’t get lost. Lost pieces of a project are a little like Roger Rabbit: just as he can escape from handcuffs only when it’s funny, lost pieces tend to show up only when it’s most inconvenient.

Psychologically, a good process protects us from having to spend our time and energy constantly wondering what we’re forgetting. This can be amazingly distracting. With a good process in place, even if some things still slip through the cracks, the frequency and severity of problems are minimized and are far less likely to derail the project. A process is, in essence, a way of breaking down a large project into goals and subgoals, while also providing a framework for keeping track of them all. This allows you to measure progress, making the whole project seem less intimidating. Put another way, you’ve at least cleared the fog from below, so you can see how far up the mountain you’ve climbed, and you have the tools to navigate the fog ahead of you.

Processes are not just about accomplishing large projects though. A good process can make it easier for new hires to become productive: for example, having a sales process helps new salesmen know what to say and how to demo the product. In this case, the process is serving to reduce confusion and provide structure to someone who is entering a new environment. By learning the process, they also learn what matters and what does not. Without a process, becoming productive is slower and involves a lot more wandering around in the fog.

Of course, no process is ever perfect. Once you’ve learned the process, you must modify it to fit you and to fix shortcomings. For team projects, part of how the team reaches its most productive stages is by figuring out how to modify the process so that it works for everyone on the team.

You wouldn’t climb a mountain without preparation. Tackling large projects without some sort of process is similarly unwise.

There Can Be Only One

The other morning, I noticed one of my cats running around with her catnip mouse. Now, this isn’t such an unusual occurrence. However, the difference this time was that the other two cats also wanted to play with the mouse. This is unusual: normally, when one cat gets the toy, the others ignore it.

It wasn’t until the cat dropped the mouse that I realized that either it wasn’t a catnip toy or the cat had been playing with a Pinocchio mouse that had picked a very unfortunate moment to become a Real Mouse.

As soon as the mouse was on the ground, it immediately tried to run from the cat. The only thing that saved the mouse was when another cat got in the way. It was a bit hard to tell, but I’m pretty sure that the cats were more interested in competing with one another over which one would get the mouse than in working together. It reminded me of an old Tweety and Sylvester cartoon.

What was particularly interesting, though, was how the mouse behaved whenever a cat did catch up to it: it would open its little tiny mouth, raise its front paws, and try to look fierce. It was pretty funny watching a mouse trying to intimidate a cat that outweighs it one hundredfold. Oddly enough, though, every time the mouse did this, the cat would hesitate, which usually gave enough time for another cat to get in the way. At that point, the mouse would run and the third cat would quickly chase and catch it, causing the whole process to repeat. Eventually, I managed to trap the mouse in a container and release it outside.

To be fair, one can hardly blame the cats for taking an “every cat for herself” attitude. After all, in this situation, we’re talking about a very fixed pie, or mouse. Only one cat will get the prize. Whether that prize is then eaten or proudly left as a gift on a bedroom pillow, there can be only one winner, and it’s not the owner of the pillow. For cats, this is quite normal. Unfortunately, it is also quite normal on far too many so-called teams. Indeed, it is quite disturbing how often teams work together almost as well as did the cats.

Like the cats, though, in a very real sense you can’t blame the team members either. When there is only one mouse, or pie, suddenly the priority becomes getting it. Put another way, whenever team members are in a position of “I win, you lose,” you don’t really have a team; you have a mob or a horde of cats out for themselves.

It doesn’t matter whether there’s a fixed amount of money being given out to the “best” members of the team, or bottom ten percent are being fired. Quite simply, when members of a “horde” are competing with one another for the rewards, performance is drastically and dramatically reduced compared to a strong team. How bad can this be, you ask? A team outperforms a horde by at least tenfold, and can sometimes outperform by a factor of a hundred or more. What is that level of performance worth to you?

Like the cats being “intimidated” by the mouse, members of a horde are also more likely to be flummoxed by relatively simple problems. By behaving in an unexpected fashion, the mouse could startle the cats, in large part because each cat was devoting the bulk of its efforts to competing with the other cats. Thus, they were less able to focus on the mouse. Similarly, when team members are devoting the bulk of their efforts to competing with their supposed colleagues, they spend less effort solving problems. After all, the reward is not for finding the best ideas, but to finding an idea that looks better than the ideas that other team members came up with. In some cases, just being good at making someone else’s ideas look bad is enough to win. Well, at least the individual wins; the team, and the company, end up with a dead mouse on their pillow.

Competition on the team also means that you, the manager, have to spend most of your time keeping your cats walking in the same direction and focused on your goals. This can be exhausting, as anyone who has ever taken their cats for a drag can attest. Team members will only care about the goals of the team when no other way of getting ahead is available. As for taking risks, forget it. Why take a risk when that means someone else gets the mouse? It’s smarter to play it safe and let another person make the mistake.

Far better to eliminate competition within the team and focus team members on competing against other teams, preferably teams at other companies. Use the competition to bring them together instead of driving them apart. If someone on the team isn’t carrying his weight, it’ll become obvious and can be dealt with simply and directly at that point. Building a strong team takes effort, but it sure beats herding cats.

Yankee Swap Rorschach

This article was originally written a couple years ago, but always seems rather appropriate for the holiday season…

The holidays are the season for Yankee Swaps. Now, a Yankee Swap would seem to be a fairly simple and straightforward activity: each person either chooses a wrapped gift or steals an opened gift from someone else. This latter activity can, of course, trigger a chain reaction, but that’s part of the fun. At the end, everyone feels like they had at least some measure of control over the outcome. One would think it difficult, if not impossible, to mess up a Yankee Swap.

However, all things are possible. In this case, one company held a Yankee Swap with incredibly detailed and complicated rules which had as its most salient feature that no gifts were opened until the very end. In other words, the experience was transformed into the equivalent of a very slow grab bag: a long, frustrating, totally random process at the end of which people felt that they had no control over the outcome. Ironically, the most common complaint from employees at this company is that many of the rules are complex, time consuming, and leave them feeling like they have very little control over how they get their work done.

Now, a Yankee Swap is a pretty insignificant event, little more than an amusing party game. However, how a business goes about designing a small process says a lot about how it goes about designing larger, more significant processes: process design is strongly influenced by institutional habits and beliefs. With a small process, it’s easy to see the results of that belief in action because the entire event can be seen at one time; with larger processes, cause and effect may be separated by weeks or months, and the process is often so big that no one ever views it as a whole. The company ends up wondering why their results are poor, but can’t figure out the reasons. Those small processes can provide valuable insights into the company’s methodology and assumptions; recognizing consistent causes of small problems can enable you to avoid large ones. Ultimately, more important than improving one process is improving how the company designs all its processes.

In designing a process, it helps to clearly understand what you are trying to accomplish. Why did this particular company choose to redesign the Yankee Swap? Was there an actual problem that someone was trying to solve? Clearly, someone felt a need to come up with something, although their motives are impossible to fathom. As a result, they got a process that rather missed the point, but did end up reflective of the organization as a whole. However, it’s generally more successful to focus on results:

• Clearly define the objective. If the objective is to solve a problem, take the time to look at the symptoms and consider what they mean. When do they come up? Under what circumstances? Remember, the symptoms are not the problem, they’re just the symptoms. Generate a list of hypotheses and then test them to see if they lead to the observed symptoms. Solving the wrong problem will generally make things worse, not better.
• Describe what a successful outcome will look like. What will have changed? What behaviors will be different? Make this concrete. If success is, “people will have more fun,” how will you know? If the picture isn’t clear, identify the questions you need to answer to bring clarity. This may be an iterative process.
• Identify what you can change and what you can’t. You probably can’t change the economy, but you can change how you deal with it. Tom Watson Sr., founder of IBM, used the Great Depression as an opportunity to build up a highly trained, extremely loyal workforce and a stockpile of equipment. When WWII started, IBM was in an excellent position to capitalize on the reawakening economy. If everything falls into the “can’t change” category, you need to revisit your goal or problem formulation.
• Brainstorm possible solutions or approaches. Record ideas and do not evaluate any of them until you have a significant number of possibilities. Don’t worry if some ideas are silly or off-the-wall: innovative solutions come from the most unlikely sources.
• Will your solutions really get you where you want to go? Do research. Don’t rely on opinion and conjecture.
• Define your action steps.
• Execute and evaluate. Did it work? If not, check your problem formulation and try again.

If you’re not getting the results you want, what steps are you missing?

Mousetrap Company

As published in Corp! Magazine

Remember the classic kid’s game, Mousetrap? In this historic tribute to the legendary Rube Goldberg, players have to assemble an exceedingly convoluted and baroque mechanism that will supposedly catch a mouse. As I have young kids, I recently had a refresher course in the game. What was interesting was the debate about which part of the trap is the most important: the crank turn at the beginning? The shoe that kicks the bucket, the ball bouncing down the stairs, the diver that flies into the washtub or the trap itself falling down the pole? In the end, most of the kids decided that it must be the trap, since without that you can’t actually catch the mouse.

Listening to the debate, I had the rather disturbing experience of being reminded of a certain software company. A similar debate occurred there as well: the engineers who were supposedly designing and implementing the software were being raked over the coals because they hadn’t successfully produced a workable product by the deadline. At first glance, it was clearly their responsibility to build the product, and their failure was costly indeed to the company.

The first glance is not, however, always the most accurate one.

In the game of Mousetrap, a number of things have to happen correctly in order for that all important trap to fall. If the shoe doesn’t kick the bucket, the ball won’t go bouncing down the stairs. If the crank doesn’t turn, the gears won’t rotate and the shoe won’t move. Indeed, while a failure at any point in this wonderfully elegant mechanism will derail the whole thing, failure at the start means that it won’t even get going.

At this software company, the process for getting a release out the door was, unfortunately, even more elaborate than the mousetrap. The biggest problem, though, was the crank at the top. The company had several products, and competition for resources was fierce. What the CEO seemed to be paying attention to was what received the time and energy of the engineers. Although the CEO kept saying that this particular release was critical to the future of the company, he made no effort to organize the company around that release, nor did he delegate that task to anyone else. Thus, the assumption from the top down was that this release couldn’t really be as important as all that.

By the time engineering got involved, the engineers were focused on multiple tasks. Without any direction from above, they took their best guess on which direction to go. Being engineers, that meant that they pursued the interesting technical problems, not the serious business priorities: when not given direction, most people will do the thing they are best at doing, whether or not that is the thing that really needs to be done at that moment.

When it came time to ship the product, the best that could be said about it was that it didn’t crash too often. The customer was not pleased.

What happened here was that there was no logical flow of control or means of prioritizing tasks. Superficially, an unhappy customer was the fault of the engineers; certainly, they took the blame. However, was that really accurate? The engineering team did their job as best they could with the information they had available. The real failure was in the leadership: when no one is leading, people follow the path of least resistance. That may not get you where you want to go. Although the failure did not manifest until the very end, the seeds of that failure were sown long before the engineers ever started working on that particular product.

Fundamentally, it is the job of the leader to set the direction for the company and keep people moving in the right direction.

It is the job of the leader to build the team so that the employees will follow him in that direction. It is the job of the leader to build up his management team so that he does not become the bottleneck.  It is the job of the leader to make sure that the technical problems and the business problems are in alignment and that the biggest contracts are the ones that get priority. This seems obvious, but for something obvious, it certainly fails to happen in far too many situations.

In this particular situation, the company’s mousetrap didn’t work very well. The trap didn’t fall. The rod didn’t move. The diver didn’t dive. The crank might have turned, but it didn’t turn particularly well. Indeed, the company really only got one part of the mousetrap process to work well.

They did manage to kick the bucket.

Stephen Balzac is a consultant and professional speaker. He is president of 7 Steps Ahead (www.7stepsahead.com), an organizational development firm focused on helping businesses to increase revenue and build their client base. Steve is a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play,” and the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill. Contact him at steve@7stepsahead.com.

Light’s Better Here

There’s an old joke about a man searching in the gutter under a streetlight. A passerby asks him what he’s doing.

“Looking for my car keys,” replies the man.

“Where did you drop them?” asks the passerby.

“Over there,” says the man, pointing into the inky darkness down the street.

“Then why aren’t you looking there?” responds the passerby in amazement.

“The light’s better here.”

Although ludicrous, like many jokes its humor comes, as it were, from the light it sheds on an important aspect of human behavior. Given the choice between poking around blindly in the dark or looking in the light, most people will choose the latter.

I can already hear the cries of, “But wait a second! That’s nonsense. Why would anyone in their right mind deliberately look where they know the keys are not?”

Why indeed? The fact is, we already have our answer: “the light’s better.” The real question is what does that actually mean?

Read the rest in the Messenger.

Growing Wheat in Siberia

Yankee Swap Rorschach

The holidays are the season for Yankee Swaps. Now, a Yankee Swap would seem to be a fairly simple and straightforward activity: each person either chooses a wrapped gift or steals an opened gift from someone else. This latter activity can, of course, trigger a chain reaction, but that’s part of the fun. At the end, everyone feels like they had at least some measure of control over the outcome. One would think it difficult, if not impossible, to mess up a Yankee Swap.

However, all things are possible. In this case, one company held a Yankee Swap with incredibly detailed and complicated rules which had as its most salient feature that no gifts were opened until the very end. In other words, the experience was transformed into the equivalent of a very slow grab bag: a long, frustrating, totally random process at the end of which people felt that they had no control over the outcome. Ironically, the most common complaint from employees at this company is that many of the rules are complex, time consuming, and leave them feeling like they have very little control over how they get their work done.

Read the rest at Affluent Magazine

The Bi-Lingual Advantage in IT

Imagine a typical software solutions problem. The company needs to improve its bottom line revenue, the customers are complaining and want their problem solved yesterday. At best, the engineer sees a technical challenge involving algorithms and code. At worst, he sees an annoying interruption to solving interesting technical challenges. The engineer’s goal is to build a robust, elegant solution to a problem. The manager, on the other hand, sees something very different. His focus is not on the technology but the process of assembling and coordinating a team. Who has the right skills? What skills are needed? What will this cost? How quickly can it be done? The manager’s goal is to give the customer what they really want, even if that is not the most elegant solution.

Dilbert highlights, to great effect, the gap between management and engineering. Frequently, the two groups seem to live in different worlds. More significantly, they often appear to work for completely separate companies with totally contradictory agendas. Sadly, there is some truth to this. Ed Schein, professor emeritus of business psychology at MIT Sloan, points out, managers and engineers form two distinct, separate organizational subcultures. Each group has very specific goals, which may not always be in alignment. Unfortunately, since both groups are working for the same company, and apparently speaking the same language, they tend to assume that they have the same image in mind. As many managers and engineers have discovered, this can lead to more than a little friction.

Read the rest at Enterprise Management Quarterly

Growing Wheat in Siberia

Once upon a time, the late and unlamented Soviet Union decided to grow wheat in Siberia. Their logic was simple: by growing wheat in the inhospitable conditions of Siberia, the wheat would become stronger. The wheat, however, was indifferent to Soviet philosophy. Despite speeches, threats, and promises from the government, the wheat stubbornly refused to grow. 

A belief about how the world should work was trumped by the way the world does work.

To bring this a little closer to home, I worked with one high technology company that decided to create a set of coding standards for its software development team. While not an unusual occurrence in software companies, in this case, the manager in charge wrote up a fifty (that’s right, 50) page standards document. Naturally, everyone was overjoyed and memorized everything; at least, that’s what the manager thought. In fact, no one read more than a page or two and most of the engineers ignored even that.

Another company was trying to manage information: design decisions, notes from discussions, and so forth. They had the very good idea that they could manage all their accumulated wisdom as a Wiki. Unfortunately, the Wiki swiftly ballooned into an unmanageable morass of data in which no one could actually find anything useful. The problem wasn’t so much getting people to remember to update the Wiki; it was organizing the information in a manner useful to everyone who needed to use it, and in convincing people to take the time to keep it organized.

In both of these cases, beliefs about how people should do their work were trumped by the way people actually do work. Like Soviet wheat, it can be remarkably difficult to motivate or threaten people into doing something that they really do not want to do. Unlike wheat, people can be forced. It’s merely a question of how much time and energy you want to spend: pushing people takes a great deal of effort and tends to result in significant amounts of anger and frustration for all parties involved. Not, in other words, a conducive atmosphere for creating a strong, collaborative team.

Of course, sometimes it is necessary to have people do things they don’t want to do. Code does need to be commented, information needs to be documented, and so forth. Fortunately, unlike wheat, people can be convinced. Instead of pushing them, the key is to get them to pull. How do you do that? Here are some tips:

• Involve those who will be affected by the outcome in the process of solving the problem. Nothing gets buy-in like giving people the opportunity to develop the solution.
• Identify the actual problem. The company with the 50 page style guide needed code that could be maintained over time and easily read by someone other than the writer, and they needed the process to not interfere with actually getting work done. That can be accomplished with a one page style guide. Instead, they were trying to win the World’s Most Beautiful Code Contest. That may be prestigious in certain obscure circles, but it doesn’t sell product.
• Ask yourself how you’ll know when you have a workable solution. This may seem counter-intuitive since you don’t have a solution yet, but it helps to figure out what success looks like. That way, you’ll know it when you get there.
• Brainstorm possible solutions.
• Do not evaluate any solution until the end of the brainstorming process. Off-the-wall ideas frequently trigger creative solutions.
• For each solution, ask yourself if it will actually get you to the outcome you want. Focus on the idea, not the person who came up with it.
  • Take the time to honestly assess what might go wrong.
  • Recognize that “oh, we’ll figure that out later,” is often a warning of trouble ahead. Make sure there is a way past potential roadblocks.
• Test your solution before you commit to it, or at least look for examples of similar solutions being successfully implemented.
• If more than one solution has survived to this point, pick one and implement it. Be willing to abandon it and pick another if it becomes obvious that it won’t work. You can’t foresee everything that can go wrong.
• Be willing to reformulate the problem if the solution doesn’t work.
• Give people as much autonomy as possible in implementing the solution. When possible, allow them to develop their own implementations. The company with the Wiki could have used email and encouraged each person to maintain their own records in whatever form was most individually useful. Instead of trying to figure out how to maintain a central repository, perhaps what they should have done was to present different ways of organizing the information and allow each person to pick the one most useful to them.

This may seem like a lot of steps, and there certainly is effort involved. The Soviet Union decided it was easier to yell at the wheat. Given the amount of wheat they imported, it’s clear which method is cheaper in the long run.

Good luck!

Published  at FreudTV.com

Just Lucky I Guess…

A great deal has already been said about the plane landing in the Hudson River last Thursday. What’s amazing to me is how many people have ascribed to luck the happy ending to what could have been a major disaster.

Was luck involved? Certainly!

It was lucky that the plane went down at a time of day when there was very little commercial shipping on the river. 

It was lucky that the ferries were out at the time the plane went down.

It was lucky that the particular pilot just happened to have the necessary and appropriate training to recognize what had happened and not panic. Instead, he remained calm and relied on his training to glide a passenger jet down to the river.

As the old saying goes, luck is when 10,000 hours of preparation meets a moment of opportunity. 

The lack of shipping and the presence of ferries wouldn’t have helped much if the pilot had lacked the skill to bring the plane down safely. It’s doubtful that he ever really believed that all that time he spent training, flying, and in a simulator would matter, other than for his own growth and development. What are the odds of a double-bird strike? What are the odds that just the right person was in the right place at the right time? Who could have known what would happen?

No one.

And this is the lesson for businesses. It’s easy to see what skills and knowledge are useful today. No one knows what skills or knowledge will prove useful tomorrow. Trends can change in a metaphorical heartbeat. When businesses cut training and development, or restrict the courses an employee can take (refusing to pay for a course unless a “clear” business need exists), that business is focusing entirely on the problems of today. It is not creating a workforce that is ready for the problems of tomorrow. Ready, in other words, to face unpredictable situations, unexpected problems, and unplanned for or unlikely circumstances.

On the other hand, those who have had the opportunity train and develop their skills, who have the freedom to explore their interests and learn the things that may or may not be obviously useful, are the most likely to come up with a good solution to an unexpected problem.

In the end, luck really does favor the prepared mind.