Documentation/process/management-style.rst

Source file repositories/reference/linux-study-clean/Documentation/process/management-style.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/management-style.rst
Extension
.rst
Size
13444 bytes
Lines
291
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _managementstyle:

Linux kernel management style
=============================

This is a short document describing the preferred (or made up, depending
on who you ask) management style for the linux kernel.  It's meant to
mirror the :ref:`process/coding-style.rst <codingstyle>` document to some
degree, and mainly written to avoid answering [#f1]_  the same (or similar)
questions over and over again.

Management style is very personal and much harder to quantify than
simple coding style rules, so this document may or may not have anything
to do with reality.  It started as a lark, but that doesn't mean that it
might not actually be true. You'll have to decide for yourself.

Btw, when talking about "kernel manager", it's all about the technical
lead persons, not the people who do traditional management inside
companies.  If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager.
These suggestions may or may not apply to you.

First off, I'd suggest buying "Seven Habits of Highly Effective
People", and NOT read it.  Burn it, it's a great symbolic gesture.

.. [#f1] This document does so not so much by answering the question, but by
  making it painfully obvious to the questioner that we don't have a clue
  to what the answer is.

Anyway, here goes:

.. _decisions:

1) Decisions
------------

Everybody thinks managers make decisions, and that decision-making is
important.  The bigger and more painful the decision, the bigger the
manager must be to make it.  That's very deep and obvious, but it's not
actually true.

The name of the game is to **avoid** having to make a decision.  In
particular, if somebody tells you "choose (a) or (b), we really need you
to decide on this", you're in trouble as a manager.  The people you
manage had better know the details better than you, so if they come to
you for a technical decision, you're screwed.  You're clearly not
competent to make that decision for them.

(Corollary:if the people you manage don't know the details better than
you, you're also screwed, although for a totally different reason.
Namely that you are in the wrong job, and that **they** should be managing
your brilliance instead).

So the name of the game is to **avoid** decisions, at least the big and
painful ones.  Making small and non-consequential decisions is fine, and
makes you look like you know what you're doing, so what a kernel manager
needs to do is to turn the big and painful ones into small things where
nobody really cares.

It helps to realize that the key difference between a big decision and a
small one is whether you can fix your decision afterwards.  Any decision
can be made small by just always making sure that if you were wrong (and
you **will** be wrong), you can always undo the damage later by
backtracking.  Suddenly, you get to be doubly managerial for making
**two** inconsequential decisions - the wrong one **and** the right one.

And people will even see that as true leadership (*cough* bullshit
*cough*).

Thus the key to avoiding big decisions becomes to just avoiding to do

Annotation

Implementation Notes