The Business Sensei

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

Seven Habits of Pointy-Haired Bosses

Scott Adams, of Dilbert fame, routinely features tales of bumbling managers. The popularity of Dilbert, and the degree to which it resonates with people, are a testament to his accuracy; indeed, Dilbert’s pointy-haired boss has become an iconic figure. Dilbert aside, however, I have observed that very few leaders are intentionally like the pointy-haired boss depicted in the comic strip. Rather, they engage in pointy-haired behaviors without realizing the effect they are having on the organization as whole. Let’s explore some examples of such behaviors and their unintended consequences.

1. Pointy-haired bosses break their own rules and figure either no one will notice or no one will mind because they are in charge. In one company, the CEO called everyone together to talk about the importance of really working hard and putting personal needs to one side in order to ship a product. At the end of the talk, he announced he was leaving for a two week vacation in Hawaii and wished everyone good luck. This did not go over well. One vice-president, who had apparently not been warned, almost choked on his coffee. When the CEO came back, two people had quit and the rest were up in arms.

2. The pointy-haired boss believes that he is separate from the group he leads. In fact, leaders are also group members, with a very important and well-defined role. Through their actions, leaders set the norms for their group. For example, the manager of a team at a large software company imposed a $.25 penalty for being late to meetings. When he was subsequently late himself, the team gleefully demanded he pay up. After a brief stunned moment, he tossed a quarter into the pot. No one complained about the fine after that. What the leader does is directly mirrored in the organization. When leaders find that employees are not living up to the standards of the organization, they often need to look in a mirror and see what example they are setting.

3. Pointy-haired bosses fail to recognize the culture they are creating. To be fair, it’s hard to see your own culture from the inside, and despite what many managers and CEOs believe, culture is formed not from what you say but from what you do. As MIT’s Ed Schein observes, “Culture is the residue of success: success in dealing with external challenges and success in internal advancement.” What behaviors are successful in the organization? What behaviors are rewarded? The very behaviors that people tell me they want to change are frequently the ones they are encouraging.”

4. Pointy-haired bosses lack an understanding of group/team dynamics. They like to say that their organization is “different,” and the research on group dynamics doesn’t apply. That’s like the people in early 2000 who said about the stock market that “This time, it’s different.” If you’re dealing with people, patterns repeat. It pays to recognize the patterns and understand how they are manifesting in your specific situation.

5. Pointy-haired bosses are often unable or unwilling to create a clear, compelling vision for their organization that gets everyone involved and excited. The best way to attract and retain top talent is to make people care about what the company is doing. That’s best done through painting a vivid picture of the outcome and creating clear goals.

6. Pointy-haired bosses motivate through short-term rewards and/or intimidation. They assume they know what their employees want, rather than taking the time to ask or to observe how people are responding. Short-term rewards and intimidation generate short-term spikes in performance, but build neither loyalty nor the desire to go the extra mile. Unfortunately, far too many people are willing to sacrifice the longer-term performance of their team for a short-term gain . In one company, the head of engineering “motivated” employees by inviting them to join him for happy hour in a bar on Friday nights. Had he asked, he would have realized that what the team wanted on Friday nights was to go home and have dinner with their families. Instead of motivating the team, he made them feel imposed upon.

Finally,

7. Pointy-haired bosses do not believe in asking for or accepting help. It’s not about asking for help, it’s about investing time and money to enable the company to accomplish its goals. The boss’s time is a resource; skilled leaders invest their time and the time and money of their business where that will produce the best return. Sometimes the best return is obtained by investing in an employee, sometimes by investing in a contractor.

Very few leaders deliberately engage in these Pointy-haired boss behaviors. Rather, their behaviors are the result of their own corporate success story. Therefore, for all that even one or two Pointy-haired boss behaviors can derail an organization, behaviors acknowledged to be counter-productive are very difficult to eradicate. Nevertheless, the ability of a manager or CEO to recognize these failings and invest in changing themselves is the true test of “great” leadership.

Published at FreudTV.

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.

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?