The Business Sensei

“We need to take our time and carefully evaluate the situation.”

“We don’t have a lot of time and we need to move forward.”

Both of these statements were made about the same project by different sets of people. The first was made by a representative of a large company, the second by a representative of a much smaller company with which the larger company was working. The folks from the large company wanted to plan everything out to the last detail, avoid any possible errors, guarantee a perfect product, and not move forward until success was assured. The members of the smaller company, not having the financial resources of the larger company and being more personally invested, wanted to get the project started.

In any project, it’s important to evaluate the situation and determine the best way to move forward. However, in any non-trivial project, it’s impossible at the beginning to foresee every eventuality. When leaving on a trip, one attempts to plan for various contingencies such as traffic, weather, flight delays, and so forth; however, some things cannot be predicted either because they are too far off to see clearly or because changing conditions make long-term prediction unreliable. On the other hand, it’s foolish to set forth on a journey without making some effort to predict the possible pitfalls and plan for how to deal with them.

There’s an old saying that “no battle plan survives contact with the enemy.” While true, how, and when, the battle plan fails can provide valuable information about what is going wrong and how to fix it. That’s assuming, of course, that the plan is designed correctly in the first place.

When planning a project, be it a battle, software development, a sales campaign, or just about anything else, the first step is always to understand how you’ll know when you’re at your destination. If you don’t know what success looks like in terms of the results you expect to achieve, it’s all too easy to take the wrong turn. Once you know what success is, only then can you identify what failure looks like.

Of course, success or failure is still a long way off. That means that your descriptions will, of necessity, be more or less vague. In order to sharpen your focus, you need to identify several stopping points between where you are now and where you want to end up. When doing this exercise, it often helps to work backward from the end point. Those stopping points become your initial milestones and should be sharper the closer they are to your starting point. A secondary goal of your milestones is to identify resources and dependencies and make sure they will be available or met at appropriate times.

For each milestone you must once again repeat the process of understanding where you are and how you’ll know if you didn’t get there. Your goal is not to avoid all possible errors, but to make sure you can identify errors as quickly as possible and be willing to cut your losses before you’ve invested too many resources down a non-functional path. When you’re uncertain which way to go, it often helps to explore several possibilities simultaneously. Some will be wrong, but if you cut your losses well, then you can save a great deal of time and may develop some novel or unexpected solutions. Walt Disney liked to have a dozen movies in production at once: he knew that half of them would flop, just not which half.

Once you have your milestones, you can get started. At each milestone, you need to evaluate your progress and adjust as necessary. What worked and what did not? Have unexpected problems cropped up? Are their external dependencies that may become a problem? It’s not about fixing blame but about understanding how to best allocate your resources and move forward. Mistakes are part of the game and initial guesses about how difficult tasks are or how long they might take are often wrong.

Once you’ve done all that, you’re still not ready to move forward to the next milestone. It’s important to take a little time and see what you’ve learned about your upcoming milestones. Have they come into sharper focus? Do they need to change? Have you discovered new dependencies that need to be taken into account or are there old dependencies that are no longer relevant?

While this may seem like a lot of work, with a little practice it becomes surprisingly easy. Once you understand your route and know how you’ll adjust it as necessary, cutting loose the anchors and moving forward is remarkably simple and even relaxing. You’ll reach your destination faster than if you rush forward without considering or planning for potential obstacles and much faster than if you never start.

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 intentionally act 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.

This one was just published in the CEO Refresher. The link is only good for month, so the text is below:

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.

In 1990s, a group of Nobel Prize winning economists developed some very interesting theories about how the financial markets should work. Their theories were brilliant and attracted billions in investment dollars into the hedge fund they created. Long-term Capital Management almost took down the entire US economy when it collapsed in the summer of 1998.

In both cases, 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. Indeed, even agreeing on how it should be organized generated controversy and bad feeling.

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: the best teams are the ones that know where they should go and will trample anyone who gets in their way. How do you create such a team? 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. Spend some time brainstorming; make sure you know what you’re trying to accomplish. 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. The customers only care that the software works.
• 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 and you’ll be better able to recognize if you’re going off course.
• Brainstorm possible solutions. Don’t be afraid to come up with wacky ideas.
• 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. Even Nobel Prize winning economists can make mistakes.
  • 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 either a way past potential roadblocks or that you have identified the work you’ll need to do to determine how you’ll know if there’s a way.
• Test your solution before you commit to it, or at least look for examples of similar solutions being successfully implemented. Why learn from your own mistakes when you have the opportunity to learn from someone else’s mistakes? The latter is a lot cheaper.
• 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. Solutions that looked good from a distance sometimes turn out to be unworkable or too expensive when you get closer.
• 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!