path: root/Documentation/ManagementStyle (plain)
blob: dea2e66c9a101dc2f45341bacac5d3ef2256f0ee

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