O’Reilly创始人Tim O’Reilly谈领导力
领导力（Tim O’Reilly访谈录）
----------------------------------------------------------------------------------------------------------
Tim O’Reilly创办了O’Reilly Media, Inc.公司，《团队之美》以及我们另外几本书就是由这家公司出版的。我们两位编者对Tim和他所创办的公司一直都很钦佩，不仅仅是因为他对出版业产生的影响，而且因为他的影响力还扩展到了软件和软件开发领域。多年来我们和O’Reilly公司几乎每个部门的人都合作过，看到的是一个非常优秀的团队。我们想请Tim介绍一下他的思想，谈谈他是如何组建这个团队并能够让团队持续表现出最优秀的能力的。
----------------------------------------------------------------------------------------------------------
Jenny：在开始编辑《团队之美》时，我们注意到每个人对“团队”的定义似乎都有一些差别，后来发现书中讲述的一些内容明确地谈到了这个问题：团队总是由一些为了构建特定的项目而临时组织在一起的人组成？还是说一群素未谋面的人也能算是一个团队？
Andrew：我们用了一点小计策，提了一个让人易于发挥的开放式问题。我们想知道您是如何定义团队的？
Tim：我自己的经验主要是关于公司运营的，当然其中也包含了有关团队的经验。但我思考的大多是一个更具广度的问题，那就是如何发挥领导力。我先从重要的开始说起，谈几点有关领导力和管理的想法，这些都是整个团队事务的一部分。说到领导力与管理，我不是很清楚这方面的内容与团队的分界线在哪里。
首先我要引述两句别人说过的话。第一句出自Harold Geneen，即第一家现代化联合大企业ITT的创始人。他说：“管理的技巧就是通过其他人的工作实现你的目标。”这是一个有趣的看法。但问题是实现风格可以有很多种，其中一些完全是命令式的。比如典型的“经理”是这样的：分析一下需要完成什么，需要由什么样的人来完成，然后找到这些人组成团队。他们做的就是诸如此类的事情。
我完全认同这种观念，因为管理的技巧确实就是通过其他人的工作实现你的目标。同时，我还总是使用另外一句引语所表达的意思。那句话实际上是关于写作的，是Edwin Schlossberg说的，是我刚参加工作时从他发表在杂志上的一篇文章中看到的，那句话深植于我的脑海之中，算得上是对我影响最大的一句话了。他说：“写作的技巧就是创造一个能够激发其他人进行思考的环境。”
Jenny：那您是如何把“创造一个能够激发其他人进行思考的环境”的思想应用到软件团队中的？
Tim：我来谈谈我的看法，这和我所说的“参与的架构”（architecture of participation）有关。我们在1998年出版了一本叫做《Open Sources》的书，采访了一些在开源方面写过文章的人。Linus Torvalds在采访中说过一句话，这句话最后没有放到书中，但是让我印象非常深刻。他说：“对于Windows，我没有办法取得像Linux那样的成就，就算给我Windows的源代码也没用。它的架构不是那样的。”这句话让我对开源项目的架构开始了一系列的思考。例如，那些架构是如何设计的？为什么能够让人们自由、即兴地进行创作？成功的背后必定有一些规则在起作用。
Andrew：还有Linus做不到的事情？真有意思——这让我想起了SourceForge.net，上面有很多不知所终的开源项目。
Tim：我想某些项目之所以失败，是因为与这些项目搭配使用的系统有问题。系统必须具备这样一个基本特征：每个任务都很小，人们能够独立完成。比如有人说他们想按照维基（Wiki）的方式出书，我想可能就是这个原因，但是这种想法并没有实现。为什么呢？因为书的内容很多、很复杂，并且只有一条叙述的主线。而维基百科词典是一组页面，每个单元的内容都很少，个人凭一己之力就能完成，其他人可以更新或稍作调整。
整部词典都是由许许多多这样的小部分组成的。我想，某些类型的工作本身就适合于这种协作活动—它们在开始时的设计方式就是让各部分易于整合，所以更为自由。
UNIX的设计方式就有点像乐高积木，它的设计原则是有一些可以彼此连接在一起的“凸起”和“凹槽”。想一想管道、过滤器等类似的东西——人们完全可以利用自己的知识编写独立的实用工具。大多数程序接受标准化输入和输出，所依据的只是几条简单规则。
类似地，每一个独立的小部分都有一个指南页。我常常想，如果可以在遵守某种开源许可协议（比如GPL）的Windows系统和每一段代码都有一个指南页的Windows系统之间做出选择，我能够在这套系统上替换或更改一些什么内容？是的，开源许可的确重要，但是只有许可证是不够的。相反，有指南页就足够了，虽然你可能会侵犯某些人的版权。
Andrew：您的意思是，为了成功运作项目—开源项目或其他项目，关键是将项目分解成人们易于理解的小块？
Tim：我说的是需要有一个可以激发人们创造力的体系，还要有一整套原则。我来讲一个具体的事例。在1998年的时候，我组织了一次后来被称为开源峰会的会议。这个故事讲述的是发生在开源界的真实事情。其他人也在谈论开源界的事情，特别是Eric Raymond，他在此前编写了《The Cathedral and the Bazaar》。一年前我刚组织了Perl会议。我们都是在同时考虑几件事。Netscape刚刚将浏览器开源，轰动一时。我注意到一个问题，在Eric Raymond和其他人讲述的标志性事件中，完全忽略了BSD领域。他们讲的全都是Linux，全都是GPL的软件，全都是自由软件的理想。
同时，我看到了另外一种已经存在很长时间的开源方式。我在看到那种开源时说：“真没想到，这种开源的影响力要大得多。”我见人就问：“你知道Internet上的最好的5种程序都有哪些吗?”他们开始挠头思考。我告诉他们：“第1名是BIND（Berkeley Internet Name Daemon）。你们每个人的网站都依赖于这个程序，它是由红杉市一位留着长头发的程序员维护的。第2名是sendmail或Apache。75%的网上电子邮件都是由sendmail发送的。”你可以接着往下数，都是Berkeley的软件。人们却看不到这一切。
Jenny：我记得在那时候，对于选择开源协议有很多争论，即选择GPL还是BSD。听说是您设法解决了争论并引导大家达成了共识。当时是什么情况呢？
Tim：我把GPL的人和Berkeley的人都召集在一起，然后说：“我们必须找出共同之处。我们必须要讲点东西。5点钟有一个记者发布会，我不知道该跟他们说些什么，但在5点钟的时候一定得跟他们说点什么。”我隐约感到将要发生一些非常有意思的事情，但我不知道那天在20个人对问题纠缠不清的情况下应该怎么办。Eric进来说道：“我们几个星期前开过类似的会议，Christine Peterson提出了一个名字，叫‘开源’（Open Source）。”
Cygnus公司的Michael Tiemann说：“我们也一直在考虑‘自由软件’（free software）这个名字的问题。”Linus Torvalds说：“我没有意识到‘free’这个单词在英语中有两种含义（译注1： free在英语中有自由的意思，也有免费的意思。free software既可以理解为自由软件，也可以理解为免费软件，有歧义）。”Michael Tiemann接着说：“其实我们一直在用‘sourceware’这个词。”
于是我们投票表决。我们说：“我们大家都同意使用一个名字，以后都要开始使用这个名字。”我们在sourceware和Open Source之间进行投票，Open Source最终胜出。记者发布会在5点钟召开，后来的事情就尽人皆知了。
Andrew：真有意思。我和Jenny曾撰文说明人为的截止期限可能对团队产生各种负面效应。没想到这种方法却帮了你们大忙。
Tim：我们经常将一些短期合作的人召集到一起。我感觉会做出一些事情来，但不是很清楚它会是什么形式的，或者应该是什么形式的。但是我知道要把它变成现实。于是团队的原则之一就是创建一个人为的截止期限——比如说：大家注意，我们在5点钟要开记者发布会，这可能会成为一个有力的工具。但是，现在很多公司和很多人却在滥用这种做法。我看到有些项目经理在截止期限的问题上对他们的团队撒谎，想要人为制造一种紧迫感。这违背了诚信原则。
但是如果能够正确使用，获得那种紧迫感还是很好的。这有点像亚历山大·蒲柏在谈论诗歌创作时所说的：狭缝令创造力如喷泉般涌出。
说到团队，我还想说一下的是团队成员优势互补带来的威力。在O’Reilly公司，现在有一位能力很强的首席运营官，她发挥着巨大作用。我们俩像是硬币的两面。我专注大事，花在内部事务上的时间很少，这样可以做更多的事情。而她则专注于日常业务运营，比我两手都要抓的时候要好得多。能够认识到优势互补的力量是非常重要的。
Andrew：我提一个问题。我和Jenny前不久为ONLamp写了一篇题为“企业项目应当向开源项目学习什么”的文章。随后，我们又做了一次题为“开源项目为什么能够成功”的讲座。我们重点关注的是他们使用的实践方法，因为我们过去一直在做这方面的工作。
您讲了很多关于团队、个性、互补的力量、如何与人们一起工作的事情。但是我们发现一个问题，如果看一看最成功的、我们都了解并热爱的开源项目，像Apache、Linux和Emacs，会发现那里有很多优秀的实践方法。开源项目的开发人员、程序员和其他人都自愿贯彻执行，但是如果回到办公室环境中，同样是那些方法却让他们感到窒息，比如很严格的构建和发布过程、持续集成、测试驱动开发等。
Jenny：还有大量的代码评审。我们把同样的实践方法应用到公司环境中就会很费力，同样是那些人，他们甚至会抵制这些做法。您觉得为什么会存在这种情况呢？
Tim：嗯，让我这么说吧。骑过马的人都知道，要想骑好马，秘诀在于让马认为它做的是自己想做的事情。同样，当人们感到是别人命令他们应该怎么做时，就会产生抗拒了。如果他们认为那是他们自己想做的，他们立刻就会接受了。
两千五百年前，中国思想家老子就说过：“悠兮，其贵言，功成事遂，百姓皆谓：我自然。”最好的领导就是能够让人们自觉自愿地去做事。
当人们抱着审美的观点去创作一些奇妙无比的东西时，这种现象就更明显了。我们既然有了iPod，怎么还会想到有不带触摸屏的设备呢？我记得第一次拿起Kindle的时候，我在屏幕上按了几下但没有反应，还以为出了什么问题。实际上Kindle有它自己的特点，比如支持EVDO连通。“是的，它就应该是这个样子的。”
Andrew：真没想到您在谈论一个产品应当做成什么样子。我参加的大多数关于开源的讨论都是争辩一些像GPL、BSD许可协议和Creative Commons许可协议孰优孰劣的问题，我想人们有点纠缠于细节了。但您认为开源软件是实现愿景的一种非常独特的方式，我从来没有这么想过。
Tim：必须承认，人们总以为开源的关键在于其许可方式。它当然重要，但就像你们刚才说的那样，实践方法远比许可方式重要。在回顾O’Reilly在行业中取得的成就时，我首先想到的就是所有的书籍都是由用户编写的。大多数产品的创作者都不是我们公司的职员。我们必须提出一个和产品相关的、可信的想法，然后又得去找一个会说“嗯，这主意不错，我也想那么干”的人。我们给他们指导，从公司内外找来很多其他人评审他们的工作。我们必须要有一套管理制度，尽管这套制度常常很松散。这些事情可以通过很多种方式完成，我之所以非常喜欢Larry Wall的Perl口号“完成的方式不止一种”，这也是原因之一。因为我认为答案不止一个。
Andrew：特别是在Perl中。
Tim：是的。看看《Programming Perl》那本书。我可以花上6个月时间把这本书按照我的想法进行改造。或者，我也可以说：“写成这样已经很好了。”虽然这本书如果让我来写，我是不会按照这种方式写的。我会祝它好运，然后送去出版。
我还记得我们出版这本书的情形。真是很遗憾，编辑的精力全都用来把它改造成另外一本书，她花了两年时间和几位作者一起工作，或教导或强迫或哄骗，让他们不要以他们开始时设想的方式写书。她不知道如何让作者放手去写。于是我说：“那也是一本书，只不过和你想象的不一样。”她回答说那几个人写的完全是一些内容上没有联系的片段。
我说：“你只要给他们介绍一些写书的基本情况就够了。”
Jenny：我们团队很多人都说《Programming Perl》是他们读过的最好的编程书之一。你得到的书和你所期望的不一样，但却更好。
Tim：那是特例。你怎么能够发现事物的本质呢？我想这可以算得上是悟性之源、万物根基了。悟性有多种。其中一种基本上是有关算法和操作的：给你的是所有这些数据，你很善于操作它们。有些人在某些方面确实很聪明，但是在其他方面却很笨拙。比如说他们对很明显的道理视而不见，没有一点常识。还有另外一些人，他们不善于符号操作、不会拼写也不会做算术，但在审时度势、理解事物本质方面却是天才。最聪明的人同时具备这两种特质。他们能够以全新的视角看待世界，他们的领悟能力很强：“我知道它可以成为什么样的。”
现在再回到刚才说的那本Perl书上，编辑接受过所有的培训，知道一本书应当是什么样的，应当怎么写。这种培训对她形成了障碍，她无法再以新的视角看待那本书。她无法理解的是，如果帮助作者按照他们所希望的方式写书，进展会更顺利。
Jenny：您认为一名编辑或者任何一个团队负责人都不应当逼迫作者或团队向着一个特定目标前进？
Tim：经验告诉我，多数情况下，领路人不一定要做团队成员。领导的大部分工作是对人员的指导，我指导的方式就是尽量少做。要实现这个想法，就需要看到团队成员的长处，遇到事情可以说：“这是我们能够处理的。”
这是模式识别（pattern recognition）的一种，又回到我对编辑过程的理解上了。这有点像米开朗琪罗在谈论雕塑时常常说的一句话：雕塑就是把隐藏在石头中的形象发掘出来。
我认为编辑图书的过程是类似的。领导一个项目也是类似的。当我开始编写Web 2.0的文章时，也是一个查看大量数据并把隐藏在石头中的形象发掘出来的过程。我编写开源文章也是这样。领导一个团队也是这样的。如何能让一群人发挥他们的潜力？关键是了解他们，了解他们能够做些什么。
Andrew：如果缺少一位优秀的领导，更多是依靠集体领导力，您认为这样有可能会造就一个出色的团队吗？
Tim：有可能。但是有一点要注意。Apache是一个很好的例子。Tim Berners-Lee制定了蓝图，他说：“我想好了，就是超文本服务器和超文本客户端。”Apache的天才们欣然接受这种约束。我还记着在20世纪90年代中期的时候，Netscape添加点这个东西，Microsoft添加点那个东西，每个人都说：“Apache似乎无所作为。他们没有添加过任何特性，他们已经落伍了！”Apache的人说：“呃，我们做的是超文本服务器，我们有良好的扩展机制，人们想要的功能可以自己添加进去。”
这又回到了“参与的架构”上。他们没有构建这个大型、复杂的应用。他们保持着单纯的愿景。这个愿景实际上是由一位富有远见的领导者提出来的，并不是Apache的一部分。
NCSA服务器团队在创办Netscape时有一部分人没有带过去，Apache就是由这些人搞起来的。那时还有一些客户在使用NCSA服务器，所以他们说：“我们必须维护这个应用程序，保证它的正常运行。”这是一个多么了不起的团队，他们接受了原有系统设计的限制。他们并没有想着展示自我或者创造力。
在我看来，由IETF（互联网工程任务组）在早些年完成的工作也是这样的。他们制定了一些很好的原则，人们都遵守这些原则。如果你读一下John Postel在TCP RFC写的有关健壮性原则的文章，就好像是出自《圣经》：“对自己做的工作要保守，接受别人的意见时要心胸开阔。”他们是这么说的，也是这么做的。
关键是，如果你的系统结构良好，团队取得成功的机会就大一些。你不需要团队依赖于某一个愿景或某一位领导，不会因为失去了领导，整个团队就快速崩溃。
Andrew：说到快速崩溃，您在过去有过事情进展不太顺利的时候吗？比如一两次彻底的失败，让您得到很深刻的教训？
Tim：这些年来可能有不少很失败的地方，其中一些在事后看来又可以看做成功了。那些算不上彻底失败，但的确是失败了—它们是选择的结果，这要回溯到领导力这个方面。事情可能出错。想想看，雅虎和微软都发生了什么。每个人都在议论说，他们不知道杨致远和斯蒂夫·鲍尔默谁更失败，他们的管理过程出现严重问题，没有清晰的愿景以说明什么才是正确的事情。但是当我们以后回头再看的时候可能会说：“啊，杨致远真是英明。他保持了雅虎的独立性，他的策略帮助他及时避免了损失。你能想象得到吗？就像现在回顾PC史上早期由比尔·盖茨和IBM做的交易一样。如果IBM能够再精明一点，结果会怎样？历史将会完全被改写。谁也不知道会怎样。
Jenny：是的，我们现在认为显见的成功，日后再看也许连一个明智的选择都算不上。您做出一系列选择，不管结果如何都能够接受。您就是以这种方式看待自己的成功与失败吗？
Tim：在那样的时刻，我看到了不同的选择所带来的影响。第一个网站门户是在O’Reilly做出来的。我们建起了GNN（全球网络导航），比雅虎还早，是最早出现的Internet站点门户。我集中全力，不愿意放弃对公司的控制权，于是把GNN卖给了AOL。
我正确地做出了推断，除非愿意放弃公司的控制权并引入投资者，否则很难赶上Internet的发展速度。此前我读了由早期的风险投资家William Davidow 写的一本好书，叫做《Marketing High Technology》（Free出版社）。他说这是一个简单的算术题。统治市场意味着占领超过一半的市场份额，而且成长速度要比市场整体更快。我们在了解了Internet之后说：“我们是一个完全依靠自有资金的私营企业，统治不了市场。Internet呈现出爆炸式的增长，我们迟早会被边缘化。我们要么引入资金，要么把它卖掉。”结果我把它卖掉了。可以说，我们因为缺乏经验而付出了昂贵的学费。杨致远和大卫·费罗引入了风险投资，尽管最近遇到了困难，但他们的公司已经发展成为营业收入达到数十亿美元的公司。我想，单从财务的角度来看，他们比我们做的要好得多。我是说，我当时清楚我的个人目标是什么：保持一个独立的公司，做自己喜欢做的事情。此后我一直是这样做的。
我想说的是，失败与成功是相对于你想实现的目标而言的。如果我们当时是一个靠风险投资支持的初创企业，那么卖掉GNN的决定可能是一个灾难性的失败。但是作为一个靠自有资金发展起来的企业家，我可以自主决定，是否出售由我说了算。我想说的是不要在事后对别人的“失败”评头论足，这一点很重要，因为失败可能是自己所选择的结果。
Andrew：难道您都不需要做最终核算吗？到了最后，一个项目不是成功就是失败，对吗？
Tim：我们的想法也是非此即彼，不是失败，就是成功。我们会努力从一组可能的成功方案中进行选择。没有最佳方案，只是做出的选择不同而已。
我认为在很多情况中，包括商业和软件设计（实际上包括任何一种工作产品的设计）两个方面，我们都没有理解审美的重要性。华莱士·史蒂文斯写过一本叫做《The Necessary Angel》（必要的天使，Vintage出版社）的文集。在那本书中，他的一个观点是：我们都认为是选择决定了结果。他有一首诗叫做《Notes towards a Supreme Fiction》（最高虚构笔记）。他的看法是：也许上帝是为了让人们信仰而虚构出来的。宗教、科学界的目标就是创造一个我们可以信仰的美学愿景。只需要去尝试说服人们相信它。
Andrew：我能想到某个在企业环境中构建数据库应用程序的读者，在看到那本书后会说：“在我的工作中没有美学。”
Tim：我要说的是“去看看斯蒂夫·乔布斯。”这就是我的回答——他可以证明美学带来的威力。他做过很多选择。很多人觉得苹果公司犯错是因为他们没有紧随主流的做法。
他们按照自己的道路、自己的审美观点在走。他能够一次次地返回苹果公司，是因为他有一个令人信服的愿景，能够说服别人接受。人们谈论的是“斯蒂夫·乔布斯的现实扭曲场（译注2：现实扭曲场（reality distortion field）最初是用来形容斯蒂夫·乔布斯的，他利用自己的领袖魅力在任何问题上几乎都能够说服别人）”——情况就是这样。他可以创建一个令人信服的愿景并让别人接受。
我记得我们有一个骨干员工曾经笑着对我说：“我有一次和你见过面，然后走了，我觉得你说的每句话都对。可等我离开并思考时，‘实际上我并不相信你说的那些东西！’”
我就是这样能够说服她。这又回到了一个有趣的观察上。我记得当我们公司超过了50人的时候。那时我不得不更改我的工作方式，因为在早期，我对人们有“现实扭曲场”的作用——对公司中的每个人都是这样。我们是一个小群体，在一起紧密地工作。
我记得在上中学的时候，我常常在夜里开着父亲的小汽车悄悄溜出去。为了不让他听见，我把汽车推到马路上，直到很远才敢开动引擎。在推车的时候，你会感到你正在推动这个庞然大物，于是你不停地推啊推，而它也开始慢慢加速前行了。我觉得推动公司职员也是如此—“啊，这些东西真的很重。”我一定要让它动起来。之后，我就一次找几个人谈谈话。你应当让人们自由地做他们的事情，然后看看他们的情况。
在我参加工作的早期，我读过一本科幻书，对我影响非常大，那本书是由F. M. Busby写的《Rissa Kerguelen》（Berkeley出版社）。读过这本书的人不是很多。那些年，特别是20世纪五六十年代（这本书是20世纪70年代写的），人们经常谈论的一个关键概念是时间膨胀的思想。如果速度接近光速，爱因斯坦的一个悖论是惯性框架将发生变化，高速穿行的人的时间将流逝得非常慢。很多科幻小说故事都提到了人们去了又来，发现周围人都变得很老了。《Rissa Kerguelen》有3部分，其中的一个部分是“远景”。它讲的是如果打算做一次星际旅行，应当做什么准备，你将在15年后再次出现。这个思想是你必须让事物动起来，然后再赶上它。我觉得这个场景中有些东西很强大，我们前面讨论的事情——各种系统的结构，那就是你推动事物的方式。你可以和它在指定的时间会合，看看它是否在按照你期望的方式发展。我在开始考虑应当对公司做些什么的时候就是这么想的。我必须让事物动起来，然后再赶上它们。
Jenny：在你开始推动的时候，团队的反应是什么？
Tim：他们的自信与活力在不断提升。他们都想当领导，都想把事情带向另外一个方向。我认为：作为一个好的领导，就是要知道人们什么时候有能力去做那些事情。我是凯尔特人队的球迷，我记得在拉里·伯德时代有一个很有启发的故事。那时K·C·琼斯是教练。在篮球比赛到了临近终场的关键时刻，大家围在一起听取教练的战术安排。拉里·伯德说：“把球交给我就行了，你们都闪在一边。”K·C·琼斯说道：“拉里，我才是教练，闭上你的嘴！大家听明白了吗？我们把球交给拉里，然后都闪在一边。”
有时候，人们进展顺利，作为教练或领导，你的工作就是说：“他们是对的，让他们那么做吧。”我和Dale Dougherty在很大程度上就是这种关系。实际上，O’Reilly的成功有很大一部分要归功于Dale。很多事情人们都认为是我做的，其实他从中起了很重要的作用。他是最早将我们带进万维网的人。他是提出“Web 2.0”这个说法的人。他现在是《MAKE Magazine》的出版人。有点像是跳舞，他离开片刻去发挥自我，然后又回来了。有时候感觉像是兄弟关系，我们对于谁来掌舵有一番争执。但是其他时候我们确实非常和睦融洽。你需要能和你争执的人。你需要人们有他们自己的想法。
当你认为某件事情是正确的—我不知道正确指的是什么意思，是绝对正确还是只是美。学上的正确。当一切正常，当你听到美妙的音乐，当你看到绘画中的线条或石雕的轮廓时，你会说：“美即是真，真即是美，这就包括你们所知道和该知道的一切。”这是济慈的诗，事情就是这样的。对于我来说，为了让人们能够一起工作，最重要的是给他们一个愿意接受的美学愿景。在你为自己构造的真理构建一个大家都能接受的愿景时，你也是在表达一种理想。因为只有这样才能让人们独立地、自由自在地追求那种理想。