About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / ManagementStyle




Custom Search

Based on kernel version 2.6.32. Page generated on 2009-12-11 16:22 EST.

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 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.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog
Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.