The Business Sensei

Where Did The Time Go?

There is nothing quite like that warm feeling you get at the end of the day when you look back and wonder where the time went. There is nothing quite like realizing that an entire day has gone by and nothing got done. Unfortunately, this happens far too often, especially when the day holds meetings.

Meetings have a bad reputation for consuming a great deal of time while producing little of substance. That reputation is well deserved. Despite this, meetings remain extremely popular in many companies. Unfortunately, in addition to potentially wasting a great deal of time, meetings often tend to leave people drained and unable to focus. As a result, they use up even more time getting back on track after the meeting.

Read the rest at FreudTv.com

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

Curse of the Half-Empty Glass

“What was the primary means of motivation in those days?”

“Fear.”

— Carl Reiner and Mel Brooks, The Two Thousand Year Old Man

For the 2000 year old man, fear may have been a very effective motivator: when he saw a lion, he was motivated to run the other way. That, in a nutshell, is the problem with fear. Fear doesn’t make someone move toward safety; it makes them move away from danger. Same thing? Not really. In jujitsu, pain can be used to invoke a fear of injury. Someone experiencing that pain, and that fear, will move away from it, even if moving away means running full tilt into the nearest tree.

In business, the same phenomenon occurs. Faced with an unexpected problem or setback, the most common response is to highlight the threat to the organization and all the terrible things that will happen if the threat is not immediately countered. This practice of attempting to motivate people to work harder through fear – fear of competition, loss of market share, job loss, company going out of business, and so forth – may encourage harder work, but not necessarily more effective work. In the business environment, there are a lot of trees.

While fear gets the adrenaline flowing, it also narrows focus, reduces creativity, and makes it harder for people to recognize and change a losing strategy. This would be fine, except that what is actually needed in most situations is a creative solution, the ability to accurately assess whether or not a strategy is working, and the ability to quickly discard failing strategies. Avoiding premature decision making, no easy task at the best of times, only becomes more difficult. As we all learned in grade school, in the event of a fire, don’t rush for the door: proceed slowly and avoid panic. The same is true in business: rushing to a decision is almost guaranteed to lead to a bad decision. 

So given that the business needs to get employees focused and energized to meet a potential challenge, how should it go about doing that?

The key is to recognize that the glass in not half empty. It’s half full. That makes a difference: instead of focusing on what you lack, focus on what you have going for you. Instead of fear, instill an atmosphere of optimism. There are several steps to accomplishing this:

1. Start by defining success. What does it look like? What will your business have accomplished in order to have been successful? Communicate that in a few brief, vibrant, sentences. If you don’t know where you’re going, you can waste a lot of time not getting there.
2. Lay out a set of goals that will make the business successful. Include what you’ll be doing as well as what you expect others to do.
3. Remind employees of previous challenges that they’ve successfully overcome. Emphasize the positive: how teams pulled together, how individuals stepped up to the plate, and so forth.
4. Recognize that roadblocks will appear: don’t assume everything will go perfectly. The competition may do something unexpected. A critical employee may get the flu. A storm may disrupt travel or power. Make sure you’ve allowed time to deal with the unexpected so that it doesn’t derail you.
5. Present energizing images to use when bad news strikes or setbacks occur: a cyclist passed by an opponent can imagine a rubber band attached to his opponent’s back. The rubber band pulls him faster and faster until he passes said opponent. Come up with the equivalent for your business. Repeat it frequently. If you can’t keep a straight face, find a different image.
6. Take the time to brainstorm different solutions to the problems you are facing. Evaluate what you come up with and make sure it will get you to that success state. Rushing off down the wrong path wastes valuable time and, even more important, drains enthusiasm.
7. Periodically review progress and show people how far they’ve come. Pilots may care more about the runway ahead than the runway behind them, but everyone else is motivated more by how much they’ve accomplished rather than being constantly reminded of how much more there is to do.
8. Celebrate successes. Short-term reminders increase the sense of progress and make people feel appreciated.

Half empty or half full. A fearful team or an enthusiastic, creative team. It’s your choice.

Published at FreudTV.com

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.

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?

Why Teams Fail

In today’s high-tech workplace, it is virtually impossible to not be part of a team. Projects are too big, too complex, too involved for a single person to do it all. Yet far too often people find teamwork to be frustrating and exhausting. Even when the team successfully ships a product, team members often feel burned out, frustrated, or surprisingly unhappy with their accomplishment.

Many managers have heard of the four stages of team development: Forming, Storming, Norming, and Performing. What is not as well known is the importance of that early, forming stage. During this phase, team members determine whether or not they feel emotionally and intellectually safe working with one another; they develop a sense of group identity, or remain a collection of individuals.

There’s an old saying that a couple isn’t really married until they’ve had their first fight. The same is true of teams. Part of working together involves arguing with coworkers: put any group of people together, and they are bound to have their own approaches and solutions to problems. If team members feel unable or unwilling to argue with one another, they avoid any conflict. If they are forced to argue but haven’t developed effective means for conflict management, the argument can quickly turn personal. In either case, the exchange of thoughts and ideas is blocked, anger builds, tension mounts, and the ability of team members to work together is severely compromised. Instead of developing group identity, team members may become convinced that their best strategy is maximizing personal gain instead of team performance.

The problems are exacerbated when the leader’s expertise is not management but engineering. There is a persistent, and ultimately painful, myth that engineers will only respect another engineer. Unfortunately, the very personality traits and skills that make someone a good engineer are often exactly the wrong skills to be a good manager. A team leader needs to have the social skills and empathy to manage the evolving dynamics of his team, and the interpersonal knowledge to apply those skills.

Of those people who do possess both sets of skills, even fewer can do both simultaneously. A good manager spends his time building the team. If he’s busy writing code, designing circuits, or what have you, then he’s not building the team. If he’s like most people thrust into a new situation and tasked with doing something he’s really good at, and something he’s not good at, he’ll gravitate toward the former.

Another problem faced by team leaders is that the storming phase can get, well, pretty stormy. The focus of that storm is often the leader. If the leader feels attacked, she’s likely to respond accordingly. This is a perfectly natural reaction. It’s also counterproductive. Managing conflict effectively means not getting enmeshed in the conflict in the first place: team progress can be set back weeks, months, or longer. Once conflict is joined, replacing the leader may improve things in the short-term, but can often make things worse long-term. The fundamental team dynamic needs to be repaired.

Unfortunately, more than half the teams in businesses become stuck in conflict or avoidance. When a team becomes stuck, it is stressful and exhausting to the team members. The company pays for this in lower productivity, reduced product quality, increased illness and absenteeism, and higher staff turnover, all of which can be fatal to a business.