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