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