management-style.rst 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290
  1. .. _managementstyle:
  2. Linux kernel management style
  3. =============================
  4. This is a short document describing the preferred (or made up, depending
  5. on who you ask) management style for the linux kernel. It's meant to
  6. mirror the :ref:`process/coding-style.rst <codingstyle>` document to some
  7. degree, and mainly written to avoid answering [#f1]_ the same (or similar)
  8. questions over and over again.
  9. Management style is very personal and much harder to quantify than
  10. simple coding style rules, so this document may or may not have anything
  11. to do with reality. It started as a lark, but that doesn't mean that it
  12. might not actually be true. You'll have to decide for yourself.
  13. Btw, when talking about "kernel manager", it's all about the technical
  14. lead persons, not the people who do traditional management inside
  15. companies. If you sign purchase orders or you have any clue about the
  16. budget of your group, you're almost certainly not a kernel manager.
  17. These suggestions may or may not apply to you.
  18. First off, I'd suggest buying "Seven Habits of Highly Effective
  19. People", and NOT read it. Burn it, it's a great symbolic gesture.
  20. .. [#f1] This document does so not so much by answering the question, but by
  21. making it painfully obvious to the questioner that we don't have a clue
  22. to what the answer is.
  23. Anyway, here goes:
  24. .. _decisions:
  25. 1) Decisions
  26. ------------
  27. Everybody thinks managers make decisions, and that decision-making is
  28. important. The bigger and more painful the decision, the bigger the
  29. manager must be to make it. That's very deep and obvious, but it's not
  30. actually true.
  31. The name of the game is to **avoid** having to make a decision. In
  32. particular, if somebody tells you "choose (a) or (b), we really need you
  33. to decide on this", you're in trouble as a manager. The people you
  34. manage had better know the details better than you, so if they come to
  35. you for a technical decision, you're screwed. You're clearly not
  36. competent to make that decision for them.
  37. (Corollary:if the people you manage don't know the details better than
  38. you, you're also screwed, although for a totally different reason.
  39. Namely that you are in the wrong job, and that **they** should be managing
  40. your brilliance instead).
  41. So the name of the game is to **avoid** decisions, at least the big and
  42. painful ones. Making small and non-consequential decisions is fine, and
  43. makes you look like you know what you're doing, so what a kernel manager
  44. needs to do is to turn the big and painful ones into small things where
  45. nobody really cares.
  46. It helps to realize that the key difference between a big decision and a
  47. small one is whether you can fix your decision afterwards. Any decision
  48. can be made small by just always making sure that if you were wrong (and
  49. you **will** be wrong), you can always undo the damage later by
  50. backtracking. Suddenly, you get to be doubly managerial for making
  51. **two** inconsequential decisions - the wrong one **and** the right one.
  52. And people will even see that as true leadership (*cough* bullshit
  53. *cough*).
  54. Thus the key to avoiding big decisions becomes to just avoiding to do
  55. things that can't be undone. Don't get ushered into a corner from which
  56. you cannot escape. A cornered rat may be dangerous - a cornered manager
  57. is just pitiful.
  58. It turns out that since nobody would be stupid enough to ever really let
  59. a kernel manager have huge fiscal responsibility **anyway**, it's usually
  60. fairly easy to backtrack. Since you're not going to be able to waste
  61. huge amounts of money that you might not be able to repay, the only
  62. thing you can backtrack on is a technical decision, and there
  63. back-tracking is very easy: just tell everybody that you were an
  64. incompetent nincompoop, say you're sorry, and undo all the worthless
  65. work you had people work on for the last year. Suddenly the decision
  66. you made a year ago wasn't a big decision after all, since it could be
  67. easily undone.
  68. It turns out that some people have trouble with this approach, for two
  69. reasons:
  70. - admitting you were an idiot is harder than it looks. We all like to
  71. maintain appearances, and coming out in public to say that you were
  72. wrong is sometimes very hard indeed.
  73. - having somebody tell you that what you worked on for the last year
  74. wasn't worthwhile after all can be hard on the poor lowly engineers
  75. too, and while the actual **work** was easy enough to undo by just
  76. deleting it, you may have irrevocably lost the trust of that
  77. engineer. And remember: "irrevocable" was what we tried to avoid in
  78. the first place, and your decision ended up being a big one after
  79. all.
  80. Happily, both of these reasons can be mitigated effectively by just
  81. admitting up-front that you don't have a friggin' clue, and telling
  82. people ahead of the fact that your decision is purely preliminary, and
  83. might be the wrong thing. You should always reserve the right to change
  84. your mind, and make people very **aware** of that. And it's much easier
  85. to admit that you are stupid when you haven't **yet** done the really
  86. stupid thing.
  87. Then, when it really does turn out to be stupid, people just roll their
  88. eyes and say "Oops, not again".
  89. This preemptive admission of incompetence might also make the people who
  90. actually do the work also think twice about whether it's worth doing or
  91. not. After all, if **they** aren't certain whether it's a good idea, you
  92. sure as hell shouldn't encourage them by promising them that what they
  93. work on will be included. Make them at least think twice before they
  94. embark on a big endeavor.
  95. Remember: they'd better know more about the details than you do, and
  96. they usually already think they have the answer to everything. The best
  97. thing you can do as a manager is not to instill confidence, but rather a
  98. healthy dose of critical thinking on what they do.
  99. Btw, another way to avoid a decision is to plaintively just whine "can't
  100. we just do both?" and look pitiful. Trust me, it works. If it's not
  101. clear which approach is better, they'll eventually figure it out. The
  102. answer may end up being that both teams get so frustrated by the
  103. situation that they just give up.
  104. That may sound like a failure, but it's usually a sign that there was
  105. something wrong with both projects, and the reason the people involved
  106. couldn't decide was that they were both wrong. You end up coming up
  107. smelling like roses, and you avoided yet another decision that you could
  108. have screwed up on.
  109. 2) People
  110. ---------
  111. Most people are idiots, and being a manager means you'll have to deal
  112. with it, and perhaps more importantly, that **they** have to deal with
  113. **you**.
  114. It turns out that while it's easy to undo technical mistakes, it's not
  115. as easy to undo personality disorders. You just have to live with
  116. theirs - and yours.
  117. However, in order to prepare yourself as a kernel manager, it's best to
  118. remember not to burn any bridges, bomb any innocent villagers, or
  119. alienate too many kernel developers. It turns out that alienating people
  120. is fairly easy, and un-alienating them is hard. Thus "alienating"
  121. immediately falls under the heading of "not reversible", and becomes a
  122. no-no according to :ref:`decisions`.
  123. There's just a few simple rules here:
  124. (1) don't call people d*ckheads (at least not in public)
  125. (2) learn how to apologize when you forgot rule (1)
  126. The problem with #1 is that it's very easy to do, since you can say
  127. "you're a d*ckhead" in millions of different ways [#f2]_, sometimes without
  128. even realizing it, and almost always with a white-hot conviction that
  129. you are right.
  130. And the more convinced you are that you are right (and let's face it,
  131. you can call just about **anybody** a d*ckhead, and you often **will** be
  132. right), the harder it ends up being to apologize afterwards.
  133. To solve this problem, you really only have two options:
  134. - get really good at apologies
  135. - spread the "love" out so evenly that nobody really ends up feeling
  136. like they get unfairly targeted. Make it inventive enough, and they
  137. might even be amused.
  138. The option of being unfailingly polite really doesn't exist. Nobody will
  139. trust somebody who is so clearly hiding their true character.
  140. .. [#f2] Paul Simon sang "Fifty Ways to Leave Your Lover", because quite
  141. frankly, "A Million Ways to Tell a Developer They're a D*ckhead" doesn't
  142. scan nearly as well. But I'm sure he thought about it.
  143. 3) People II - the Good Kind
  144. ----------------------------
  145. While it turns out that most people are idiots, the corollary to that is
  146. sadly that you are one too, and that while we can all bask in the secure
  147. knowledge that we're better than the average person (let's face it,
  148. nobody ever believes that they're average or below-average), we should
  149. also admit that we're not the sharpest knife around, and there will be
  150. other people that are less of an idiot than you are.
  151. Some people react badly to smart people. Others take advantage of them.
  152. Make sure that you, as a kernel maintainer, are in the second group.
  153. Suck up to them, because they are the people who will make your job
  154. easier. In particular, they'll be able to make your decisions for you,
  155. which is what the game is all about.
  156. So when you find somebody smarter than you are, just coast along. Your
  157. management responsibilities largely become ones of saying "Sounds like a
  158. good idea - go wild", or "That sounds good, but what about xxx?". The
  159. second version in particular is a great way to either learn something
  160. new about "xxx" or seem **extra** managerial by pointing out something the
  161. smarter person hadn't thought about. In either case, you win.
  162. One thing to look out for is to realize that greatness in one area does
  163. not necessarily translate to other areas. So you might prod people in
  164. specific directions, but let's face it, they might be good at what they
  165. do, and suck at everything else. The good news is that people tend to
  166. naturally gravitate back to what they are good at, so it's not like you
  167. are doing something irreversible when you **do** prod them in some
  168. direction, just don't push too hard.
  169. 4) Placing blame
  170. ----------------
  171. Things will go wrong, and people want somebody to blame. Tag, you're it.
  172. It's not actually that hard to accept the blame, especially if people
  173. kind of realize that it wasn't **all** your fault. Which brings us to the
  174. best way of taking the blame: do it for someone else. You'll feel good
  175. for taking the fall, they'll feel good about not getting blamed, and the
  176. person who lost their whole 36GB porn-collection because of your
  177. incompetence will grudgingly admit that you at least didn't try to weasel
  178. out of it.
  179. Then make the developer who really screwed up (if you can find them) know
  180. **in private** that they screwed up. Not just so they can avoid it in the
  181. future, but so that they know they owe you one. And, perhaps even more
  182. importantly, they're also likely the person who can fix it. Because, let's
  183. face it, it sure ain't you.
  184. Taking the blame is also why you get to be manager in the first place.
  185. It's part of what makes people trust you, and allow you the potential
  186. glory, because you're the one who gets to say "I screwed up". And if
  187. you've followed the previous rules, you'll be pretty good at saying that
  188. by now.
  189. 5) Things to avoid
  190. ------------------
  191. There's one thing people hate even more than being called "d*ckhead",
  192. and that is being called a "d*ckhead" in a sanctimonious voice. The
  193. first you can apologize for, the second one you won't really get the
  194. chance. They likely will no longer be listening even if you otherwise
  195. do a good job.
  196. We all think we're better than anybody else, which means that when
  197. somebody else puts on airs, it **really** rubs us the wrong way. You may
  198. be morally and intellectually superior to everybody around you, but
  199. don't try to make it too obvious unless you really **intend** to irritate
  200. somebody [#f3]_.
  201. Similarly, don't be too polite or subtle about things. Politeness easily
  202. ends up going overboard and hiding the problem, and as they say, "On the
  203. internet, nobody can hear you being subtle". Use a big blunt object to
  204. hammer the point in, because you can't really depend on people getting
  205. your point otherwise.
  206. Some humor can help pad both the bluntness and the moralizing. Going
  207. overboard to the point of being ridiculous can drive a point home
  208. without making it painful to the recipient, who just thinks you're being
  209. silly. It can thus help get through the personal mental block we all
  210. have about criticism.
  211. .. [#f3] Hint: internet newsgroups that are not directly related to your work
  212. are great ways to take out your frustrations at other people. Write
  213. insulting posts with a sneer just to get into a good flame every once in
  214. a while, and you'll feel cleansed. Just don't crap too close to home.
  215. 6) Why me?
  216. ----------
  217. Since your main responsibility seems to be to take the blame for other
  218. peoples mistakes, and make it painfully obvious to everybody else that
  219. you're incompetent, the obvious question becomes one of why do it in the
  220. first place?
  221. First off, while you may or may not get screaming teenage girls (or
  222. boys, let's not be judgmental or sexist here) knocking on your dressing
  223. room door, you **will** get an immense feeling of personal accomplishment
  224. for being "in charge". Never mind the fact that you're really leading
  225. by trying to keep up with everybody else and running after them as fast
  226. as you can. Everybody will still think you're the person in charge.
  227. It's a great job if you can hack it.