Contents of /alx-src/tags/kernel26-2.6.12-alx-r9/Documentation/ManagementStyle
Parent Directory | Revision Log
Revision 630 -
(show annotations)
(download)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File size: 13249 byte(s)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File size: 13249 byte(s)
Tag kernel26-2.6.12-alx-r9
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 Successful |
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 Lose 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 that 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. |