作者:余晟 译来源:电子工业出版社|2009-12-10 12:37


Ideas are at the center of problem-solving leadership; they are the method by which we go from a definition of the problem to a high-quality solution. Too few ideas means no solution at all; too many ideas means chaos. Without leadership to manage the flow of ideas, two technical experts in the same room make an argument, three make a crowd, and four make a mob. With effective management of ideas, any number makes a successful problem-solving team. Here are twelve typical actions that problem-solving leaders use to manage the flow of ideas.

Contribute a clever idea to the team. Although this is the most obvious leadership action, and although new ideas are sometimes critical, there are actually very few truly new ideas. Several thousand years ago, Aristotle said, "It is not once, nor twice, but times without number that the same idea makes its appearance in the world." In three decades of working with high-tech organizations, I've seen fewer than ten truly original ideas. Virtually all of the new ideas underlying computer software technology, for instance, were put forth by Charles Babbage more than a century ago. More important than the clever new idea is creating an environment where the right idea for solving the problem will be recognized when it comes along.

Encourage copying of useful ideas. Problem-solving leaders are inveterate copiers, though some do not like to admit it. The best ones not only admit it, they cultivate it as a fine art. As Aristotle understood, most "new" ideas are actually copies of ideas from other contexts, and problem-solving leaders are constantly searching other contexts for ideas they can use. The best teachers never cease to study the texts, lectures, and exercises of their colleagues. The best computer programmers never write a new program when they can use an old one for a new job. The best circuit designers know what designs already exist, and whether they can be used in different situations. Problem-solving leaders are not interested in doing again what has already been done well, by themselves or someone else.

Elaborate on an idea that a teammate contributed. No idea is perfect when it is first formed; even copied ideas must be adapted to new circumstances. Most problem-solving leaders devote a hundred times more energy to perfecting ideas than to proposing them. This is what Edison meant when he said, "Genius is one percent inspiration and ninety-nine percent perspiration."

Drop one's own idea in favor of an idea the team wants to develop, and Refuse to let an idea drop until everyone understands it. These are the yin and yang of solving any complex problem. Large problems require the joint effort of many people working in harmony. However, the need for teamwork produces enormous pressures to go along with the majority, which can prove disastrous if the majority is stuck on an incorrect idea.

It's relatively easy to let all your ideas drop, or to refuse to drop any of them. What's hard is to strike a balance: to let go when you're merely being egotistical, but to hold on when the rest of the group is plunging ahead with a fatal mistake. I particularly remember one landscape architect, part of a development team, who graciously let go of his favorite playground design concept when it didn't fit with the rest of the project. My first impression was that he was weak and wishy-washy, but later he objected to a particular slide. Although he was one against seven, he persisted until someone else finally understood why the slide would be dangerous to children.

Resist time pressure, and take the time to listen when other people explain their ideas. The landscape architect's teammates deserve credit for taking time to understand why the slide was a safety problem. Under time pressure, most ideas get dropped before they're actually understood, even though some of them would save enough time to pay for trying to understand the bad ideas a hundred times over. Even if this weren't so, people tend to lose their dedication to a project when their ideas are dropped for the wrong reason. In the end, projects go faster in an environment where people listen to all ideas, even if the ideas turn out to be inapplicable.

Test ideas contributed by other people. In any given situation, the vast majority of ideas are not useful, but which ones are useful? High-tech companies like IBM and General Electric maintain large research laboratories, but few of their products originate in the research from their own labs. The researchers' principal job is to stay on top of developments in their field, critically analyzing each one for its potential benefit to the company. When an idea looks good, they then are prepared to seize it quickly and make it better.

Withhold quick criticism of teammates' ideas, in order to keep the ideas flowing. Although testing is crucial, few ideas are so dangerous they can't be allowed to live for the few moments it takes to reconsider our initial reaction to them. Criticism is one thing; quick criticism is another. Hightech companies often reject important ideas, several times even, before: some smaller company proves they can work in practice. In 1948, for example, IBM decided not to enter the computer business because the market was too small. What has made IBM the dominant force in the computer business today was not being first, but being able to reconsider early rejections after testing by others proved the ideas viable.

When you must criticize an idea, make clear that you are criticizing the idea, not the person who offered the idea. Problem-solving leaders are well aware that not every idea is useful for every problem, but they are even more aware that every person is useful. They know that remarks like "that's a stupid idea," or "you can't really believe that," tend to discourage further contributions, so they offer their criticisms in a caring way. This means that they pay attention to their choice of words, and criticize only ideas, never people.

Test your own ideas before offering them. The popular image of the problem-solving leader is a bright young person pouring out bright young ideas at two hundred words per minute. Such people may score high in leadership as measured by counting "acts of influence," but they are rarely the true problem-solving leaders. Quite the contrary. When asked why they talk so much, these babblers will often remark, "Well, nobody else had anything to contribute." This is nonsense. Nobody is bright enough to have all the good ideas, and a constant babble of your own unconsidered ideas is an excellent way to discourage other people's ideas.

When time and labor are running short, stop working on new ideas and just pitch in. There comes a time in every project when you have to actually do the work, because if you don't have enough ideas by then, you won't finish the project anyway. Some would-be leaders have such an inflated image of themselves that they cannot stoop to mere implementation work, but even God quit thinking up new species after six days.

Encourage the team to drop ideas that had succeeded earlier, but cannot be extended to the new situation. It's hard enough to let go of your bad ideas, but your good ideas are your stock-in-trade. Yet every great idea has its limits. Even banana cream pie gets tiresome if you have to eat it three times a day.

Revive a dropped idea later, when it has value for another part of the problem. Actually, there are no bad ideas, only ideas in the wrong place or at the wrong time. Sailing vessels disappeared when steamships took over, but as energy costs rise, sails are making a comeback. Old ideas don't wear out; a problem-solving leader has a terrific memory and an even better sense of timing.



为团队贡献一个明智的想法。尽管这是领导力最明显的表现,尽管新的想法有时非常关键,但真正的新想法其实非常少。几千年前,亚里士多德就讲过:"同样的思想在世界上出现,不是一次,也不是两次,而是无数次"。我在高科技机构工作的三十年中,见过的真正原创的想法不超过十个。其实,计算机软件技术中的所有新想法,Charles Babbage 在一个世纪以前就提出过了。比明智的想法更重要的是创造一个环境,只要真正能解决问题的想法一冒出来,就能被识别。













【责任编辑:董书 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0




共16章 | 晒书包




共20章 | 捷哥CCIE




共50章 | WOT峰会


读 书 +更多

Visual C# 2005从入门到精通

Microsoft Visual C#功能强大、使用简单。本书全面介绍了如何利用Visual Studio2005和NET Framework来进行C#编程。作者将C#的各种特性娓娓...