]>
Commit | Line | Data |
---|---|---|
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. |