这篇短文是描述了一种“理想的”（当然也可以说是“自以为是的”，各种看法因人而异）Linux内核开发管理风格。这篇文章从某种意义上来说就和编码规范文档差不多，有了这篇文档，就可以避免总是重复地回答同样（或者类似）的相关问题。
管理风格其实是因人而异的，而且很难像编码风格一样，单纯用数量来衡量。因此这篇文档无法保证一定具有实际的参考价值。关于这一点，我们有言在先。你可以根据自己的情况来决定是否接受。
顺便提一下，我们所说的”内核经理“，明确地指（负责内核开发的）技术经理，而不是传统意义上公司内部负责行政的经理。如果你平时的工作涉及到采购或者是制定公司预算，那你基本上就不属于我们讨论的内核经理的范畴。如果是这样的话，本文就不适合你。
首先，我建议读者去买《成功人士的七个好习惯》这本书，然后千万不要读这本书，而是烧掉它。这种行为可以表明一种对所谓成功学的蔑视态度。
（*）本文绝对不会用来回答各种提问，而是要向那些提问者们阐述一个非常痛苦而且明显的事实：你们问的问题我们根本就不知道怎么回答。
废话少说，我们开始：
译文
第一章：决策
我们都觉得：经理的主要职责是做决策，而且做决策这件事情是很重要的。决策越大就愈发棘手，就需要职位更高的决策者来决定。这种说法看上去真的是又明显又有道理，但事实并非真的如此。
让我们来做一个叫做”不要做决策“的游戏吧。尤其是，当你被人要求”在A和B中选出一个”的时候，如果你是技术经理，对不起，那你的麻烦就来了。你手下管的人其实比你更明白各种事情的细节，如果他们都需要让你来做一个选择，那你算是彻底失败了。很明显，你的下属比你更有资格去做正确的决策。
（由同样的逻辑我们可以知道：作为技术经理，如果你手下管的人对技术细节的了解程度还不如你，那你又败了，不管是什么原因。这种局面只能说明：你不适合做技术经理的工作，相反你的下属反而比你更适合这个职位）
所以说，技术经理要“避免做决策”，至少那种又大又难的决策不要轻易做。那种规模较小，影响不大的小决策倒是可以做，并且可以让你看上去称职，所以技术经理要做的事情就是把又大又难的决策拆分成很多无关紧要的小事情，小事情是没有人会真拿它当回事儿的。
这还可以帮助我们认清“大决策”和“小决定”的区别，其主要区别就在于：你是否在事后有机会去纠正错误。如果你要把大事化小，那你一定要确保自己总是有机会去看看是不是做错了（或者会不会做错），如果错了，你可以浪子回头，避免损失。这样一来，突然你就可以做不同的决定了，正确的决定和错误的决定，就像灵活而善变的企业管理人员一样。
人们还真把这个当成是“领导才能”的象征（放屁）
其实避免做大决的要义在于“不要做你无法挽回的事情”。不要把自己逼到没有退路。要记住，狗急了能跳墙，兔子急了会咬人，技术经理被逼到走头无路的时候，只会挂掉。
“可挽回”的原则相当清晰明了，就算再荒唐再没大脑，也不会让技术经理去承担主要财务责任。因为花出去的钱就是泼出去的水，无法挽回，唯一能够挽回的是“技术性决策”，技术性决策的挽回是很简单的：把你手下的弟兄骂到半死，然后再跟所有人说抱歉，然后把去年搞砸的工作从头再来一遍。这样一来，你去年做的决策就不再是什么大决策了，因为这个决策失败的后果是可以挽回的。
不过有些人可能没法采纳上述的方法，理由有如下两点：
- 承认自己是白痴很难，能这么做更难。我们都要面子，公开场合说谁谁谁错了这种事情多数时候是不那么容易的。
- 要让别人告诉你，你去年做的工作完全就没有意义，这很毕竟不容易做到。对那些级别很低微的程序员来说也是如此。如果所谓的“重做”就是把他们原来的工作不分青红皂白地删掉从零开始，这样你很可能就会不可挽回地失去他们的信任。要记住：“不可挽回”是我们要竭尽全力避免的，一开始就是如此，我们要避免让我们的决策成为一个“大决策”。
幸运的是，上面所说的两个理由可以想办法缓解，我们不如一开始就放开心态，大大方方地承认自己其实没有什么好办法，告诉大家现在所做的决定全都是非常初步的，很有可能出错。你要一直做好改变的准备，并且让大家也都知道你是这么想的。这样就会在你犯错的时候，让自己更加勇于面对和承认自己的愚蠢决定。
如果你心态开放，那你犯错的时候，人们也只是轻描淡写地说：“瞧，他又错了”。
这种主动放低姿态的方式还会让大家在工作的时候养成三思而后行的好习惯，不管这个工作是不是真的需要那么谨慎。毕竟，如果大家在不是“非常确认这是个好主意”的情况下，你就不应该承诺说一定让大家的代码纳入到最终产品中。这样你就确保了他们在木已成舟之前充分地进行思考。
记住：你的属下最好比你知道更多的技术细节，并且他们通常觉得自己是万能的。作为内核技术经理，你要做的就是不要去干涉这种自负的情绪，而是要对他们的能力和作为做更深刻的思考。
另外一种“避免做决策”的好办法就是卖萌，技术经理可以可怜兮兮地问：“我们能不能以两个方面都兼顾呢？”。相信我，这招绝对好使。如果两种方案之间并无明显的优劣之分，你这么一问，你的下属们就会自己去解决问题。最后，分别支持两种方案的双方会各自放弃原来坚持的方案，并且都会非常不爽（但是能达成妥协性的一致）
也许你觉得这样的做法很失败，但是实际的情况是，很可能两种方案都存在问题，人们之所以无法做出决定，是因为他们都是错的。你的做法，实际上是中止了双输的局面，虽然会有人不爽，但也是长痛不如短痛，况且，你还成功地避免让自己做一个差劲的选择，如果你不这么做，很可能你就搞砸了。
第二章：人
我们身边的人基本上以白痴居多，作为技术经理，就意味着你必须要和这些白痴打交道，这么说还不太确切，确切地说，是他们必须要和你折腾。
技术上犯了错误，我们还可以挽回，但是人如果发神经，那真是不好办。所以你必须要学会处理这些人的神经病，当然，也要学会处理你自己发神经的情况。
然而，为了让你成为一个称职的内核技术经理，你一定要记住：“留得青山在，不怕没柴烧”，对你手下的内核开发人员要学会宽容。很显然，得罪人容易道歉难。因此“得罪”这个词语很立刻地就被归结到“不可挽回”的范畴中去了，这个在我们第一章所说的内容里是严格被禁止的。
那么，为了不得罪人，你应该遵守下面两条规矩：
- 不要用“SB”这种词语问候他人（至少在公开场合不要这么做）
- 如果你违反了第一条，那么要学会怎么给别人道歉
第一点所说的内容是很不容易做到的，因为骂人的办法实在太多了，就算你不用“SB”，还是能找到很多其他同样效果的词语，甚至有的时候，你出口成脏，自己都没有意识，而且往往伴随着极端的狂妄和自负。
你越自以为是（让我们面对事实吧，人人都想随意骂人SB，并且多数时候你都认为自己是对的），你就越不可能在事后跟人道歉
为了解决这个问题，你只有两个选择：
- 真心诚意给人道歉
- 把爱洒向人间，让每一个人都沐浴在你爱的阳光里，这样就没有人会感受到你的敌意。变得极富创意的幽默，让大家天天笑口常开。
其实后面那种超级好人的做法是不存在的。因为一看就是装出来的，没有人会信任这种人。
（*）保罗.西蒙斯唱过《Fifty Ways to Lose Your Lover》，说实在话，“告诉开发者他们是SB的100万种方法”这种主题好像和原来那首歌完全不搭调，但是我想西蒙斯也可能会考虑要不要唱一下。
第三章：人II – 如何做好人
如果周围的人都是白痴，很遗憾，你自己也是白痴的一员。在我们躺在自己创造的“周围的人都不如我”的意淫中（说实话，很少有人承认自己水平一般或者是不行）的时候，我们也该考虑一下承认现实，我们并不敢说自己是独一无二地优秀，身边总是有些人要稍微优秀一些的，而我们自己很可能真的就是个白痴。
“愚者怒，智者用”
作为一个内核的维护者，面对比你更聪明的人，确保你自己是智者。尽情地和他们套近乎吧，因为他们帮你干活，让你的工作更轻松。尤其是，他们甚至还要帮你去做决策，这个行业不就是这么玩儿的么。
所以，当你发现有些人比你聪明的时候，你就“袖手旁观”就对了。你的管理责任多数时候就变成了两种不同的问话：“听上去不错，整吧”，或者“听上去不错，不过那个xxx你觉得怎么样？”。后面那个问法很管用，如果你想了解xxx是怎么回事，或者你想委婉地向一个比你更聪明的人表达不同意见的时候，你就可以这么做。不论是哪种情况，你都是最后的赢家。
还有一个事情必须指出，人非圣贤，不可能面面俱到。你想要鞭策你的下属努力向前，但是要认清楚，他们在你要求的方面也许没那么优秀，也许是做什么错什么。关于这个问题，好的一面是，人类一般都会自觉地回到他们擅长的领域中，所以说不是你自己破釜沉舟，他们就真的能跟你一起破釜沉舟。所以不要逼得太狠了。
第四章：学会处理批评
事情可能会出岔子，而且肯定有人会为此遭受批评。没准这个人就是你。
实际上，被批对任何人来说都是不愉快的，尤其是大家都认为“又不都是我的错”的时候。这样就造就了我们面对批评的最好心态：“替别人承担责任”。如果你是帮别人承担批评，那一种荣誉感就油然而生，真正该被批评的那个人也因为没有被骂而很高兴，那个因为你们的工作失误而损失了36个G的爱情动作片的倒霉客户，虽然非常不爽，但是至少也会对团队敢做敢当的风格表示一下赞许。
接下来，就是找到那个真正惹了麻烦的开发者（如果你真的能找到他的话），私下里跟他说：你搞砸了。这样做的目的一方面是他以后不会将错就错地抵赖说是你惹的事儿，另一方面是你要让他知道他欠你个人情。接下来，也是很重要的就是，他应该做点儿什么去弥补错误了。实事求是吧，是你搞砸的，又不是我，总不会让我去弥补吧。
承担批评和责备也是你作为技术经理最重要的职能之一。你的兄弟会因为你敢做敢当而信任你，打心眼儿里佩服你，因为你是那个真正敢把“我们搞砸了”这句话说出口的人。如果你一直是这样的人，那么我相信你现在已经对这个问题处理得如鱼得水了。
第五章：该回避的就回避
有一样东西是比直接骂人SB更可恨的，就是假装仁义道德地用关心的口吻骂人SB（“某某某，我这是为你好，我当你们是我的孩子一样，我这是锻炼你……”，耳熟不？ —— 译者注）。骂人SB事后还可以道歉，第二种的话真是连道歉的余地都没有了。采用第二种做法，基本上就是自绝于人民，就算你有什么观点是对的，人家也都不再听你的了。
当然，我们每个人都认为自己比别人更优秀，这都可以理解，但是你要是装13，那就完全是另外一回事了。你或许认为自己很有节操，或者在智力上超群，比你周围的人都优秀，但是不要做得太明显，除非你想刻意激怒别人。
同样的道理，不要刻意强调礼貌，也不要敏感得不得了。礼貌这种东西要么就会让人得寸进尺，要么就暴露不出问题，同样，人们也会说：“在互联网上面，你敏感个头啊，谁会理你？”。如果你要想表达什么观点，那就老老实实地讲给人家听，因此除此之外，没有别的办法能让人明确你到底是什么意思了。
当然，在表达观点的时候讲一点幽默，无论是从人际关系上还是从效果上，都会有所帮助。把观点夸张到极致，甚至是到荒唐的程度，反而可以降低别人对你观点的敌意，哪怕人家一开始认为你简直就是白痴。同样，这种做法还有助于让人与人之间解开心理防备，我们多多少少都有一些这样的问题，不是吗。
（*） 提示：有的时候，去那些和你的工作不直接相关的社交媒体上骂一骂口水战，是很有利于你转移对工作的负面情绪的。在这些地方飚一些语言尖锐，冷嘲热讽的帖子出去，几乎每次都可以让你的情绪得到发泄，然后你的心态就会恢复平静一阵子。但是注意，别去那些人家认识你的地方，以免被人发现。
第六章：为什么选我？
作为技术经理，你又要帮别人承担责任和过错，又要在众人面前显示出自己的弱点，那么你一定要问的一个问题就是：我是做了什么孽？为什么一开始要干这个？
首先，也许你家里处于青春期狂躁的少女（或者少男，这里我可不想对男女生青春期谁更狂躁做讨论，更不想涉及性别歧视的问题）狂敲你屋子的门对你大吵大闹，你是不是会感觉到强烈的“责任感”，并且伴随一定的“成就感”？ 其实不要在意你是不是真的跟得上所有人的节奏，也不要在意你能不能赶上其他人的速度。反正在大家的眼里，你就是负责人。
只要能把事情搞定，你就牛了！
英文原文：Linux kernel management style
This is a short document describing the preferred (or made up, depending on who you ask) management style for the linux kernel. It’s meant to mirror the CodingStyle document to some degree, and mainly written to avoid answering (*) the same (or similar) questions over and over again.
Management style is very personal and much harder to quantify than simple coding style rules, so this document may or may not have anything to do with reality. It started as a lark, but that doesn’t mean that it might not actually be true. You’ll have to decide for yourself.
Btw, when talking about “kernel manager”, it’s all about the technical lead persons, not the people who do traditional management inside companies. If you sign purchase orders or you have any clue about the budget of your group, you’re almost certainly not a kernel manager. These suggestions may or may not apply to you.
First off, I’d suggest buying “Seven Habits of Highly Successful People”, and NOT read it. Burn it, it’s a great symbolic gesture.
(*) This document does so not so much by answering the question, but by making it painfully obvious to the questioner that we don’t have a clue to what the answer is.
Anyway, here goes:
Chapter 1: Decisions
Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That’s very deep and obvious, but it’s not actually true.
The name of the game is to avoid having to make a decision. In particular, if somebody tells you “choose (a) or (b), we really need you to decide on this”, you’re in trouble as a manager. The people you manage had better know the details better than you, so if they come to you for a technical decision, you’re screwed. You’re clearly not competent to make that decision for them.
(Corollary:if the people you manage don’t know the details better than you, you’re also screwed, although for a totally different reason. Namely that you are in the wrong job, and that they should be managing your brilliance instead).
So the name of the game is to avoid decisions, at least the big and painful ones. Making small and non-consequential decisions is fine, and makes you look like you know what you’re doing, so what a kernel manager needs to do is to turn the big and painful ones into small things where nobody really cares.
It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always undo the damage later by backtracking. Suddenly, you get to be doubly managerial for making two inconsequential decisions - the wrong one and the right one.
And people will even see that as true leadership (cough bullshit cough).
Thus the key to avoiding big decisions becomes to just avoiding to do things that can’t be undone. Don’t get ushered into a corner from which you cannot escape. A cornered rat may be dangerous - a cornered manager is just pitiful.
It turns out that since nobody would be stupid enough to ever really let a kernel manager have huge fiscal responsibility anyway, it’s usually fairly easy to backtrack. Since you’re not going to be able to waste huge amounts of money that you might not be able to repay, the only thing you can backtrack on is a technical decision, and there back-tracking is very easy: just tell everybody that you were an incompetent nincompoop, say you’re sorry, and undo all the worthless work you had people work on for the last year. Suddenly the decision you made a year ago wasn’t a big decision after all, since it could be easily undone.
It turns out that some people have trouble with this approach, for two reasons:
- admitting you were an idiot is harder than it looks. We all like to maintain appearances, and coming out in public to say that you were wrong is sometimes very hard indeed.
- having somebody tell you that what you worked on for the last year wasn’t worthwhile after all can be hard on the poor lowly engineers too, and while the actual work was easy enough to undo by just deleting it, you may have irrevocably lost the trust of that engineer. And remember: “irrevocable” was what we tried to avoid in the first place, and your decision ended up being a big one after all.
Happily, both of these reasons can be mitigated effectively by just admitting up-front that you don’t have a friggin’ clue, and telling people ahead of the fact that your decision is purely preliminary, and might be the wrong thing. You should always reserve the right to change your mind, and make people very aware of that. And it’s much easier to admit that you are stupid when you haven’t yet done the really stupid thing.
Then, when it really does turn out to be stupid, people just roll their eyes and say “Oops, he did it again”.
This preemptive admission of incompetence might also make the people who actually do the work also think twice about whether it’s worth doing or not. After all, if they aren’t certain whether it’s a good idea, you sure as hell shouldn’t encourage them by promising them that what they work on will be included. Make them at least think twice before they embark on a big endeavor.
Remember: they’d better know more about the details than you do, and they usually already think they have the answer to everything. The best thing you can do as a manager is not to instill confidence, but rather a healthy dose of critical thinking on what they do.
Btw, another way to avoid a decision is to plaintively just whine “can’t we just do both?” and look pitiful. Trust me, it works. If it’s not clear which approach is better, they’ll eventually figure it out. The answer may end up being that both teams get so frustrated by the situation that they just give up.
That may sound like a failure, but it’s usually a sign that there was something wrong with both projects, and the reason the people involved couldn’t decide was that they were both wrong. You end up coming up smelling like roses, and you avoided yet another decision that you could have screwed up on.
Chapter 2: People
Most people are idiots, and being a manager means you’ll have to deal with it, and perhaps more importantly, that they have to deal with you.
It turns out that while it’s easy to undo technical mistakes, it’s not as easy to undo personality disorders. You just have to live with theirs - and yours.
However, in order to prepare yourself as a kernel manager, it’s best to remember not to burn any bridges, bomb any innocent villagers, or alienate too many kernel developers. It turns out that alienating people is fairly easy, and un-alienating them is hard. Thus “alienating” immediately falls under the heading of “not reversible”, and becomes a no-no according to Chapter 1.
There’s just a few simple rules here:
- don’t call people d*ckheads (at least not in public)
- learn how to apologize when you forgot rule (1)
The problem with #1 is that it’s very easy to do, since you can say “you’re a d*ckhead” in millions of different ways (*), sometimes without even realizing it, and almost always with a white-hot conviction that you are right.
And the more convinced you are that you are right (and let’s face it, you can call just about anybody a d*ckhead, and you often will be right), the harder it ends up being to apologize afterwards.
To solve this problem, you really only have two options:
- get really good at apologies
- spread the “love” out so evenly that nobody really ends up feeling like they get unfairly targeted. Make it inventive enough, and they might even be amused.
The option of being unfailingly polite really doesn’t exist. Nobody will trust somebody who is so clearly hiding his true character.
(*) Paul Simon sang “Fifty Ways to Lose Your Lover”, because quite frankly, “A Million Ways to Tell a Developer He Is a D*ckhead” doesn’t scan nearly as well. But I’m sure he thought about it.
Chapter 3: People II - the Good Kind
While it turns out that most people are idiots, the corollary to that is sadly that you are one too, and that while we can all bask in the secure knowledge that we’re better than the average person (let’s face it, nobody ever believes that they’re average or below-average), we should also admit that we’re not the sharpest knife around, and there will be other people that are less of an idiot that you are.
Some people react badly to smart people. Others take advantage of them.
Make sure that you, as a kernel maintainer, are in the second group. Suck up to them, because they are the people who will make your job easier. In particular, they’ll be able to make your decisions for you, which is what the game is all about.
So when you find somebody smarter than you are, just coast along. Your management responsibilities largely become ones of saying “Sounds like a good idea - go wild”, or “That sounds good, but what about xxx?”. The second version in particular is a great way to either learn something new about “xxx” or seem extra managerial by pointing out something the smarter person hadn’t thought about. In either case, you win.
One thing to look out for is to realize that greatness in one area does not necessarily translate to other areas. So you might prod people in specific directions, but let’s face it, they might be good at what they do, and suck at everything else. The good news is that people tend to naturally gravitate back to what they are good at, so it’s not like you are doing something irreversible when you do prod them in some direction, just don’t push too hard.
Chapter 4: Placing blame
Things will go wrong, and people want somebody to blame. Tag, you’re it.
It’s not actually that hard to accept the blame, especially if people kind of realize that it wasn’t all your fault. Which brings us to the best way of taking the blame: do it for another guy. You’ll feel good for taking the fall, he’ll feel good about not getting blamed, and the guy who lost his whole 36GB porn-collection because of your incompetence will grudgingly admit that you at least didn’t try to weasel out of it.
Then make the developer who really screwed up (if you can find him) know _inprivate that he screwed up. Not just so he can avoid it in the future, but so that he knows he owes you one. And, perhaps even more importantly, he’s also likely the person who can fix it. Because, let’s face it, it sure ain’t you.
Taking the blame is also why you get to be manager in the first place. It’s part of what makes people trust you, and allow you the potential glory, because you’re the one who gets to say “I screwed up”. And if you’ve followed the previous rules, you’ll be pretty good at saying that by now.
Chapter 5: Things to avoid
There’s one thing people hate even more than being called “d*ckhead”, and that is being called a “d*ckhead” in a sanctimonious voice. The first you can apologize for, the second one you won’t really get the chance. They likely will no longer be listening even if you otherwise do a good job.
We all think we’re better than anybody else, which means that when somebody else puts on airs, it really rubs us the wrong way. You may be morally and intellectually superior to everybody around you, but don’t try to make it too obvious unless you really intend to irritate somebody (*).
Similarly, don’t be too polite or subtle about things. Politeness easily ends up going overboard and hiding the problem, and as they say, “On the internet, nobody can hear you being subtle”. Use a big blunt object to hammer the point in, because you can’t really depend on people getting your point otherwise.
Some humor can help pad both the bluntness and the moralizing. Going overboard to the point of being ridiculous can drive a point home without making it painful to the recipient, who just thinks you’re being silly. It can thus help get through the personal mental block we all have about criticism.
(*) Hint: internet newsgroups that are not directly related to your work are great ways to take out your frustrations at other people. Write insulting posts with a sneer just to get into a good flame every once in a while, and you’ll feel cleansed. Just don’t crap too close to home.
Chapter 6: Why me?
Since your main responsibility seems to be to take the blame for other peoples mistakes, and make it painfully obvious to everybody else that you’re incompetent, the obvious question becomes one of why do it in the first place?
First off, while you may or may not get screaming teenage girls (or boys, let’s not be judgmental or sexist here) knocking on your dressing room door, you will get an immense feeling of personal accomplishment for being “in charge”. Never mind the fact that you’re really leading by trying to keep up with everybody else and running after them as fast as you can. Everybody will still think you’re the person in charge.
It’s a great job if you can hack it.