两个故事

I want to tell you two stories from my career which I think are classic illustrations of the difference between tech companies that are well-managed and tech companies that are disasters. It comes down to the difference between trusting employees and letting them get things done, versus treating them like burger flippers that need to be monitored and controlled every minute, lest they wander off and sabotage everything.

我想给你们讲两个我职业生涯中的故事。我觉得这两个故事经典地阐释了管理很好的技术公司和管理糟糕的技术公司之间的差别。其实，这两者的差别就在于：相信员工，让他们自己把事情做好。或者是，把他们看成是混日子的，需要监督的，每分钟都要牢牢控制住，不然他们就会开小差甚至把所有事情都搞得一团糟。

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.

我的第一份工作是在微软。第一项作业就是要为Excel设计宏语言架构。没多久，我就想出了Excel Basic第一份草案。（后来又演化成Visual Basic应用程序，不过那是题外话了）然后，微软的一群叫做应用程序架构师团队的神秘人员，设法了解到了我的这份程序规范。这份程序规范肯定让他们有点担心，因为出于某些原因，他们觉得他们才是负责像宏语言架构这类工作的人。因此，他们向我索要了我的宏架构规范。

I asked around. Who's the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.

我四处打听，谁知道应用程序架构师团队么？ 看起来似乎没有人觉得他们是非常正经的组织。后来知道他们只是公司最近新招的四个博士组成的一个小组。（微软会雇博士其实还蛮奇怪的）我给他们发送了一份我的规范。然后跑去跟他们开会，觉得：也许他们会有一些非常有趣的观点可以分享一下。

"Blah blah!" said one of them. "Blah blah blah, blah blah blah!" said another. I don't think they quite had anything interesting to say. They were very enamored of the idea of subclassing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, "Well, this is all very interesting. What's next? Who has to approve your spec?"

然后他们中的一个人“巴拉巴拉巴拉巴拉”说了一通，另外一个人又“巴拉巴拉巴拉巴拉”说了一堆废话。我开始觉得他们没什么有价值的观点要分享。他们好像只是非常迷恋于“继承”。然后觉得所有用excel宏的人都会想要“继承”很多东西。最后，然后他们中的一个人说道：“嗯。这些都非常有意思，额，那么接下来会怎么样？谁会来批准你的规范呢？”

I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec. Hell, nobody had time to read my spec, let alone approve it. The programmers were bugging me every day to get them more pages so that they could write more code. My boss (and his boss) made it very clear to me that nobody else understood macros or had time to work on macros, so whatever I did, it better be right. And here this PhD working in a strange research group at Microsoft assumed that things were a bit more formal than that.

我笑了，虽然我只在微软呆了几个月，但是我知道，根本没有这么一回事说谁会来批准我的规范。见鬼了，才没有人有时间来看那么多的规范呢？更不要说批准规范了。那些每天让我多写几页规范的程序员只是为了他能有更多的时间来写代码。我老板和他的老板已经跟我说的很清楚了，没有其他人懂得宏或者有时间来做这个宏项目，所以不管我怎么搞，最好都得是对的。然后这群在什么奇怪的研究组里面工作的博士生们却会假设说事情好像要比原来的那个样子更加正式的。

I pretty rapidly realized that the App Architecture group knew even less than I did about macros. At least, I had talked to a handful of macro developers and some Excel old-timers to get a grip on what people actually did with Excel macros: things like recalculating a spreadsheet every day, or rearranging some data according to a certain pattern. But the App Architecture group had merely thoughtabout macros as an academic exercise, and they couldn't actually come up with any examples of the kind of macros people would want to write. Pressured, one of them came up with the idea that since Excel already had underlining and double-underlining, perhaps someone would want to write a macro to triple underline. Yep. REAL common. So I proceeded to ignore them as diplomatically as possible.

我很快就意识到这群应用程序架构组的人没有我了解宏。至少我列举一些宏开发程序员，和一些老的Excel程序员来举例说人们会如何使用宏。人们使用excel宏究竟做了什么？比如说：每天重新计算一个电子表单；或者说；按照某种模式来重新排列某些数据。架构程序组的那些人不过是把宏想像成一个学术研究罢了。他们根本想不出人们会写宏干些什么。也举不出宏实用的例子。在感到有些压力之后他们之中提出了一个主意：说既然Excel这样已经有了下滑线和双下划线，也许某个人可能会写一个宏来实现三下划线。好“平常”啊！所以我接下来就尝试尽可能的外交辞令式地忽略他们。

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him. Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?) My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

这种做法好像惹恼了应用程序架构团队的老板。这家伙叫Greg Whitten，负责管理应用程序架构团队。Greg是微软的第6号员工，虽然他已经老早就在公司了，但没有人知道他实际上做了些什么。很显然他似乎跟比尔盖茨一起吃中饭，然后GW-BASIC实际上就是以他命名的。Greg召集了一个很大的会议。继续抱怨说Excel团队（是指我）是如何在破坏公司的宏架构策略。我让他提出一些具体的原因。但是他的论据却没法没法让人信服。我觉得很高兴，因为我是一个新进员工，刚从大学毕业的小不点儿，然后却在和微软的第六号员工进行争辩。并且很明显我赢得了这场争论。（你能想像这种情况会在那种老牌的服装公司里面发生吗？）最重要的是：我们的程序组的头Ben Waldman，现在已经是微软的一个副总裁了，完全支持我。结果是我们的程序团队很快地实现了代码。然后就给这件事情应该如何了结画上了句号。

I would have been perfectly happy to leave it at that. If the Apps Architecture team needed care and feeding and wanted to argue about stuff, that was OK, I would argue with them as much as they wanted as long as they left the programmers alone to do their work. But then something even more interesting happened that blew my mind. I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office -- I knew who he was, of course, but didn't expect that he knew me very well.

要是事情就是这样，我肯定会很高兴。如果应用程序架构组想要额外的关心和反馈，哪怕想继续争论，那也行。如果他们让程序团队继续做他们的事情，那么他们想要跟我争多久我就会跟他们争多久。然后发生了一些让我难以相信的事情。那天中午在Redmund我正在跟同事们一起吃中饭。然后Pete Higgins超走了过来，那个时候Peter是Office产品的总经理。我当然知道他是谁，但是我不觉得她会很了解我。

"How's it going, Joel?" he asked. "I hear you've been having some issues with the App Architecture group."

“最近怎么样？Joe”他问道“我听说你和应用程序架构团队有些矛盾”。

"Oh no!" I said. "Nothing I can't handle."

“没有，没有。”我说道，“没有我无法解决的事情。”

"Say no more," he said, "I understand." He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.

“应该说不会再有了。”他说道，“我懂的” 。然后他就走了。到第二天我就开始听到谣言传开来了，应用程序架构组被解散了。不仅如此，，每个组员都被派遣到了微软不同的部门。相互之间隔得尽可能的远。然后我再没有听说过他们。

I was blown away, of course. At Microsoft, if you're the Program Manager working on the Excel macro strategy, even if you've been at the company for less than six months, it doesn't matter - you are the GOD of the Excel macro strategy, and nobody, not even employee number 6, is allowed to get in your way. Period.

当然，我被震惊了：在微软，如果你是这个宏架构策略的程序经理。哪怕你在公司才不到六个月，你就是Excel宏策略的神。没有人，哪怕是第六号员工能挡你的道的，句号。

This sends a really strong message. For one, it makes everyone that much more conscientious about their jobs. They can't hide behind the idea that "management approved their spec," since management really didn't look too closely at their spec. All management did was hire smart people and gave them something to do. For another, it makes for an extremely nice place to work. Who doesn't want to be king of their own domain? Software, by its nature, is very easy to divide into smaller and smaller components, so it's always possible to divide up responsibility among people and let people own an area. This is probably THE reason why software people love working at Microsoft.

这件事情发出了很强烈的信息。第一，他让所有人都更加关心自己的工作。他们没有办法在躲在“管理层批准他们的规范”这种想法后面。因为管理层不会太仔细地看规范。管理层所做的不过是招聪明的人，然后给他们事情做。第二，这里变成一个非常好的工作场所。谁不想成为他们自己领域的上帝呢？软件从根本上来讲非常容易分成更小的部分。所以总是很容易，总是可以把责任分散到各个人员然后让这些人员来负责这些领域。这也许就是为什么软件程序员喜欢在微软工作的那一个原因吧！

Years passed. I found myself working at Juno, an online service and free email provider. This time, the experience was the exact opposite of my work at Microsoft. I had two programmers reporting to me, but my own manager constantly undermined my (limited) authority by going directly to my reports and giving them things to do, often without even telling me. Even for trivial requests like days off, my manager thought that it was his job to approve or disapprove the request.

几年之后我已经在Juno（一个在线服务和免费邮件提供商）工作了。然而这一次，却与我在微软工作的经验恰恰相反。我有两个直接汇报的程序员，但是我自己的老板却经常无视我有限的权力，直接跟我的下属程序员沟通，给他们分配任务，通常甚至不会知会我一声。哪怕是像很小的事情，像请假。我老板都会觉得那是他的工作来批准或者是否决。

After a couple of years at Juno I was working on the new user signup feature. For Juno 3.x, a major release, I was going to be in charge of a complete overhaul of the signup process. By this time, I was a relatively senior member of the technical team; I got great performance reviews, and my managers seemed to appreciate the work I was doing. But they just couldn't bring themselves to trust me. Command and control.

在Juno呆了几年之后, 我开始负责一个新的用户注册体验产品。Juno3.24 重大发布。我本来要完整的负责整个注册过程的。因为到这个时候我已经是技术组比较资深的成员了。我有很好的绩效考核结果，然后我的老板似乎也很欣赏我所做的工作。但是，他们似乎就是没办法让自己来相信我。他们更青睐命令和控制。

One part of the signup process asked the users to type in their birthday. This was just one small bit of a lengthy signup process that went on for something like 30 screens as Juno grilled you about your income, your favorite sports, how many children you have and how old they were, and about 100 other things. To make the signup process a little bit easier, I wanted to change the birthday field to be free format, so you could type "8/12/74" or "August 12, 1974" or "12 Aug 74" or whatever. (Have you used Outlook? It would work like Outlook, where you could type dates in just about any format and it would accept them).

注册过程的其中一步是请用户输入他们自己的生日，这只是正常的注册过程中的一个很小的一笔。整个注册过程，大概要有三十多个屏幕。因为Juno会不停地拷问你的收入情况，喜欢的运动，你有几个孩子？多大？还有其他一百项诸如此类的问题。我想把注册过程变得容易点。我想把生日栏的输入变得更加自由一点。你可以输入“8/12/74”或者输入“1974年8月12号”或者“8月12号，74年”或者其他。（你用过Outlook么，就像Outlook那样不管你输入什么格式的日期，他都能够接受）

Without going into too much detail, my manager decided he didn't like this. It became an issue of ego for him. First he yelled at the designer who was working on that page (without even telling me). Then he yelled at me. Then he reminded me every single day that I had to change it to the way he wanted it. Then he got the CEO of the company to review it, and made a big show out of getting the CEO of the company to criticize my new design. Even the CEO at Juno is perfectly happy to interfere in work done at the lowest level in the company, in fact, it's standard operating procedure.

还没讨论到任何细节的时候，我老板就决定说他不喜欢这样。这成为他的心病。首先他朝着设计那个页面的设计师嚷嚷，先没告诉我，然后开始朝着我嚷嚷。然后他每天都会提醒我，我必须要把这个输入框改成他要的样子。然后他拉来公司的CEO来批评我的设计，大秀特秀。 哪怕是真的公司的CEO也完全乐意干扰哪怕是最底层的工作。实际上这就是公司运作的标准模式。

I was furious, needless to say. It was a small thing, a matter of taste, really. Some people would prefer my way. Some people would prefer his. In either case, the message was clear: you WILL do as you are told here, dammit. It was a very command-and-conquer mentality that was more of a battle of cojones than a discussion of user interface design.

毋庸质疑，我恼羞成怒。这只不过是很小的一件事情，不过是关乎品味的一件事情。真的，有些人会倾向于我的方式，有些人会欣赏他的方法。不管怎么样，有一点是肯定的：你必须按上面的要求来。扯淡的是：这更像是一种命令与征服思维模式 而不是为了并肩作战一起来讨论用户设计。

I won't say that this is the reason I left Juno, but it does illustrate the reason I left Juno: it was the idea that no matter how hard you work, no matter how smart you are, no matter whether you are 'in charge' of something or not, you have no authority whatsoever for even the tiniest thing. None. Take your damn ideas, training, brains, and intelligence, all the things we're paying you for, and shove it. And at Juno, there were plenty of managers, something like 1/4 of all the employees, and so they had plenty of times to stick their fingers into every single decision and make sure that they were in control. The contrast with Microsoft, where VP's descended from Building 9 to make it clear that you have the authority to get things done, was stark.

我不想说这就是我离开Juno的原因。但是这确实说明了我离开Juno的理由。就是那种不管你工作多么努力；不管你多聪明；不管你是不是负责某些事情，你对哪怕是最小的事情都没有自主权，什么都没有！收起你那些想法，所受的培训，思维方式，才能，所有那些雇你进来的理由。忘了那些吧。并且Juno有大量的程序经理，大概占到所有员工数的四分之一。这样他们就能够花大量的时间把他们的魔爪伸向每一个细小的决定。保证他们能够控制所有事情。与之相对比的就是微软，从第九号楼下来的副总裁都会跟你说的非常清楚：你有充分的自主权来把事情做完。绝对就是这样。

To some extent, Juno's hopelessly inept management process is a factor of being a New York City company, not a West Coast company, so modern styles of management haven't quite permeated. It's also a problem caused by the deep inexperience of Juno's managers, and it originates at the top - the CEO, a 29 year old who has never worked outside D. E. Shaw, who interferes in everything he can get his fingers into, including the wording on error messages that come up when things go wrong; the CTO regularly screams at his reports if they dare to question his wisdom; they take it out on the programmers, who go home and kick their dogs. Compare this to Microsoft, where things are done at the lowest level, and most managers act like their most important job is to run around the room, moving the furniture out of the way, so people can concentrate on their work.

从某种程度上来说Juno的那种让人绝望的无能管理过程，首先归因于它是一家纽约公司而不是西海岸的公司，因此浸染现代现代管理方式不深。其次还要归因于管理层没有什么经验，从CEO开始，这位29岁的CEO除了DE SHAW之外就没有其他外部工作经验，却想要管理任何他力所能及的范围，甚至是软件出错的时候的出错提示信息如何措辞都要插一笔。要是有经理胆敢质疑CTO的智慧，CTO就会把气撒在经理的报告上，朝着经理嚷嚷。然后直接经理会把气撒在程序员身上，而程序员最后就只好回家踹他家的狗。相比之下，微软是事情在最底层就被做完了。程序经理的最重要的工作就是在房间里面走来走去。把家具从走道上班开，这样人们就能够专注在他们的工作上了。