| 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 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 |
|
| 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 , 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 |
|
| 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 .
|
| 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 |
|
| 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.
|