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