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