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