요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
큰 결정을 되돌릴 수 있는 작은 결정으로 만든다
management-style.rst:34-135세부 code를 가장 잘 아는 개발자가 technical option을 평가해야 한다. Maintainer의 역할은 정보가 부족한 상태에서 a와 b 중 하나를 권위로 찍는 것이 아니라, 실험과 review를 통해 결정의 크기를 줄이는 것이다.
큰 결정과 작은 결정의 차이는 틀렸을 때 되돌릴 수 있는가에 있다. Irreversible corner로 project를 몰지 말고 단계적 merge, feature isolation과 revert 가능성을 유지한다. 판단이 provisional하고 바뀔 수 있음을 미리 알리면 contributor도 큰 투자 전에 가정을 다시 검토한다.
틀린 판단을 인정하고 backtrack하는 기술적 비용보다 1년간 일한 개발자의 신뢰를 잃는 비용이 더 되돌리기 어렵다. 따라서 불확실성을 숨기지 않고 inclusion을 성급히 약속하지 않는다.
사람과의 관계는 쉽게 revert되지 않는다
management-style.rst:136-182Technical mistake는 revert할 수 있지만 사람을 공개적으로 소외시킨 결과는 쉽게 복구되지 않는다. 공개 토론에서 개인을 공격하지 않고, 선을 넘었다면 제대로 사과할 수 있어야 한다.
원문은 예의만 차리는 모호한 답도 신뢰를 만들지 못한다고 지적한다. 기술 문제는 직접 말하되 사람의 가치와 code의 결함을 분리하고, 감정이 판단을 앞서지 않게 한다.
자신보다 잘 아는 사람을 활용한다
management-style.rst:183-215Maintainer가 모든 영역에서 가장 뛰어난 사람일 수 없다. 특정 문제를 더 잘 아는 contributor를 찾으면 방향을 통제하기보다 맡기고, 놓친 constraint가 있는지 질문하며 결정을 분산한다.
한 분야의 뛰어난 능력이 다른 분야에도 자동으로 이어지지는 않는다. 사람을 강제로 맞지 않는 역할로 밀기보다 강점이 드러나는 영역에서 기여하도록 돕는다.
공개 책임은 maintainer가, 교정은 비공개로
management-style.rst:216-241문제가 생기면 maintainer가 공개적으로 책임을 받아들이는 편이 project 신뢰를 지킨다. 실제 실수한 개발자에게는 비공개로 무엇이 잘못됐는지 알리고, 문제를 가장 잘 이해하는 그 사람이 fix에 참여하게 한다.
책임을 피하지 않는 것이 technical lead에게 결정 권한을 맡기는 이유 중 하나다. 성공의 credit만 받고 failure를 contributor에게 돌리는 구조에서는 review와 risk reporting이 위축된다.
독선, 과도한 완곡어법과 권위적 태도를 피한다
management-style.rst:242-290도덕적 우월감을 섞은 비난은 기술적 지적 자체를 들리지 않게 만든다. 반대로 지나친 완곡어법도 실제 blocker를 감춘다. Internet text에서는 subtle cue가 사라지므로 문제와 요구 변경을 구체적이고 직접적으로 말한다.
적절한 humor는 비판의 긴장을 줄일 수 있지만 상대를 희생시키는 농담이 되어서는 안 된다. Maintainer 역할의 보상은 다른 사람보다 위에 서는 데 있지 않고, 빠르게 움직이는 contributor를 따라가며 project 전체가 앞으로 가게 하는 데 있다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _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
things that can't be undone. Don't get ushered into a corner from which
you cannot escape. A cornered rat may be dangerous - a cornered manager
is just pitiful.
It turns out that since nobody would be stupid enough to ever really let
a kernel manager have huge fiscal responsibility **anyway**, it's usually
fairly easy to backtrack. Since you're not going to be able to waste
huge amounts of money that you might not be able to repay, the only
thing you can backtrack on is a technical decision, and there
back-tracking is very easy: just tell everybody that you were an
incompetent nincompoop, say you're sorry, and undo all the worthless
work you had people work on for the last year. Suddenly the decision
you made a year ago wasn't a big decision after all, since it could be
easily undone.
It turns out that some people have trouble with this approach, for two
reasons:
- admitting you were an idiot is harder than it looks. We all like to
maintain appearances, and coming out in public to say that you were
wrong is sometimes very hard indeed.
- having somebody tell you that what you worked on for the last year
wasn't worthwhile after all can be hard on the poor lowly engineers
too, and while the actual **work** was easy enough to undo by just
deleting it, you may have irrevocably lost the trust of that
engineer. And remember: "irrevocable" was what we tried to avoid in
the first place, and your decision ended up being a big one after
all.
Happily, both of these reasons can be mitigated effectively by just
admitting up-front that you don't have a friggin' clue, and telling
people ahead of the fact that your decision is purely preliminary, and
might be the wrong thing. You should always reserve the right to change
your mind, and make people very **aware** of that. And it's much easier
to admit that you are stupid when you haven't **yet** done the really
stupid thing.
Then, when it really does turn out to be stupid, people just roll their
eyes and say "Oops, not again".
This preemptive admission of incompetence might also make the people who
actually do the work also think twice about whether it's worth doing or
not. After all, if **they** aren't certain whether it's a good idea, you
sure as hell shouldn't encourage them by promising them that what they
work on will be included. Make them at least think twice before they
embark on a big endeavor.
Remember: they'd better know more about the details than you do, and
they usually already think they have the answer to everything. The best
thing you can do as a manager is not to instill confidence, but rather a
healthy dose of critical thinking on what they do.
Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful. Trust me, it works. If it's not
clear which approach is better, they'll eventually figure it out. The
answer may end up being that both teams get so frustrated by the
situation that they just give up.
That may sound like a failure, but it's usually a sign that there was
something wrong with both projects, and the reason the people involved
couldn't decide was that they were both wrong. You end up coming up
smelling like roses, and you avoided yet another decision that you could
have screwed up on.
2) People
---------
Most people are idiots, and being a manager means you'll have to deal
with it, and perhaps more importantly, that **they** have to deal with
**you**.
It turns out that while it's easy to undo technical mistakes, it's not
as easy to undo personality disorders. You just have to live with
theirs - and yours.
However, in order to prepare yourself as a kernel manager, it's best to
remember not to burn any bridges, bomb any innocent villagers, or
alienate too many kernel developers. It turns out that alienating people
is fairly easy, and un-alienating them is hard. Thus "alienating"
immediately falls under the heading of "not reversible", and becomes a
no-no according to :ref:`decisions`.
There's just a few simple rules here:
(1) don't call people d*ckheads (at least not in public)
(2) learn how to apologize when you forgot rule (1)
The problem with #1 is that it's very easy to do, since you can say
"you're a d*ckhead" in millions of different ways [#f2]_, sometimes without
even realizing it, and almost always with a white-hot conviction that
you are right.
And the more convinced you are that you are right (and let's face it,
you can call just about **anybody** a d*ckhead, and you often **will** be
right), the harder it ends up being to apologize afterwards.
To solve this problem, you really only have two options:
- get really good at apologies
- spread the "love" out so evenly that nobody really ends up feeling
like they get unfairly targeted. Make it inventive enough, and they
might even be amused.
The option of being unfailingly polite really doesn't exist. Nobody will
trust somebody who is so clearly hiding their true character.
.. [#f2] Paul Simon sang "Fifty Ways to Leave Your Lover", because quite
frankly, "A Million Ways to Tell a Developer They're a D*ckhead" doesn't
scan nearly as well. But I'm sure he thought about it.
3) People II - the Good Kind
----------------------------
While it turns out that most people are idiots, the corollary to that is
sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot than you are.
Some people react badly to smart people. Others take advantage of them.
Make sure that you, as a kernel maintainer, are in the second group.
Suck up to them, because they are the people who will make your job
easier. In particular, they'll be able to make your decisions for you,
which is what the game is all about.
So when you find somebody smarter than you are, just coast along. Your
management responsibilities largely become ones of saying "Sounds like a
good idea - go wild", or "That sounds good, but what about xxx?". The
second version in particular is a great way to either learn something
new about "xxx" or seem **extra** managerial by pointing out something the
smarter person hadn't thought about. In either case, you win.
One thing to look out for is to realize that greatness in one area does
not necessarily translate to other areas. So you might prod people in
specific directions, but let's face it, they might be good at what they
do, and suck at everything else. The good news is that people tend to
naturally gravitate back to what they are good at, so it's not like you
are doing something irreversible when you **do** prod them in some
direction, just don't push too hard.
4) Placing blame
----------------
Things will go wrong, and people want somebody to blame. Tag, you're it.
It's not actually that hard to accept the blame, especially if people
kind of realize that it wasn't **all** your fault. Which brings us to the
best way of taking the blame: do it for someone else. You'll feel good
for taking the fall, they'll feel good about not getting blamed, and the
person who lost their whole 36GB porn-collection because of your
incompetence will grudgingly admit that you at least didn't try to weasel
out of it.
Then make the developer who really screwed up (if you can find them) know
**in private** that they screwed up. Not just so they can avoid it in the
future, but so that they know they owe you one. And, perhaps even more
importantly, they're also likely the person who can fix it. Because, let's
face it, it sure ain't you.
Taking the blame is also why you get to be manager in the first place.
It's part of what makes people trust you, and allow you the potential
glory, because you're the one who gets to say "I screwed up". And if
you've followed the previous rules, you'll be pretty good at saying that
by now.
5) Things to avoid
------------------
There's one thing people hate even more than being called "d*ckhead",
and that is being called a "d*ckhead" in a sanctimonious voice. The
first you can apologize for, the second one you won't really get the
chance. They likely will no longer be listening even if you otherwise
do a good job.
We all think we're better than anybody else, which means that when
somebody else puts on airs, it **really** rubs us the wrong way. You may
be morally and intellectually superior to everybody around you, but
don't try to make it too obvious unless you really **intend** to irritate
somebody [#f3]_.
Similarly, don't be too polite or subtle about things. Politeness easily
ends up going overboard and hiding the problem, and as they say, "On the
internet, nobody can hear you being subtle". Use a big blunt object to
hammer the point in, because you can't really depend on people getting
your point otherwise.
Some humor can help pad both the bluntness and the moralizing. Going
overboard to the point of being ridiculous can drive a point home
without making it painful to the recipient, who just thinks you're being
silly. It can thus help get through the personal mental block we all
have about criticism.
.. [#f3] Hint: internet newsgroups that are not directly related to your work
are great ways to take out your frustrations at other people. Write
insulting posts with a sneer just to get into a good flame every once in
a while, and you'll feel cleansed. Just don't crap too close to home.
6) Why me?
----------
Since your main responsibility seems to be to take the blame for other
peoples mistakes, and make it painfully obvious to everybody else that
you're incompetent, the obvious question becomes one of why do it in the
first place?
First off, while you may or may not get screaming teenage girls (or
boys, let's not be judgmental or sexist here) knocking on your dressing
room door, you **will** get an immense feeling of personal accomplishment
for being "in charge". Never mind the fact that you're really leading
by trying to keep up with everybody else and running after them as fast
as you can. Everybody will still think you're the person in charge.
It's a great job if you can hack it.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux kernel management style이라는 풍자
1-30이 짧은 문서는 Linux kernel에서 선호하는, 또는 누구에게 묻느냐에 따라 지어낸 것일 수도 있는 management style을 설명한다. 어느 정도 Documentation/process/coding-style.rst를 본떠 만들었고, 같거나 비슷한 질문에 계속 답하는 일을 피하려고 작성했다.
Management style은 매우 개인적이며 단순한 coding style 규칙보다 수량화하기 훨씬 어렵다. 그래서 이 문서는 현실과 관련이 있을 수도 없을 수도 있다. 장난으로 시작했지만 실제로 맞는 말이 아닐 이유도 없다. 판단은 독자에게 맡긴다.
여기서 “kernel manager”는 회사의 전통적인 관리자가 아니라 technical lead를 뜻한다. 구매 주문서에 서명하거나 group budget을 알고 있다면 거의 확실히 kernel manager가 아니며, 이 조언이 적용될 수도 있고 아닐 수도 있다.
저자는 먼저 『성공하는 사람들의 7가지 습관』을 사되 읽지는 말고 태우라고 권한다. 훌륭한 상징적 행동이라는 풍자다.
각주 1: 이 문서는 질문에 답하기보다 우리도 답을 모른다는 사실을 질문자에게 고통스러울 만큼 명백하게 보여 주는 방식으로 반복 질문을 피한다.
1. 되돌릴 수 있는 결정으로 만들기
32-133사람들은 manager가 결정을 내리며, 결정이 크고 고통스러울수록 더 높은 manager가 내려야 한다고 생각한다. 문서는 이 통념이 사실이 아니라고 말한다. 핵심은 결정을 내려야 하는 상황 자체를 피하는 것이다.
누군가가 “a와 b 중 하나를 골라 달라”고 technical decision을 요청한다면 곤란한 상황이다. 실제 작업자는 manager보다 세부 사항을 더 잘 알아야 하므로 manager는 그들을 대신해 기술적 결정을 내릴 능력이 없다. 반대로 작업자가 manager보다 세부 사항을 모른다면 manager가 잘못된 자리에 있다는 다른 문제가 생긴다.
따라서 크고 고통스러운 결정을 작고 중요하지 않은 결정으로 바꾸어야 한다. 큰 결정과 작은 결정의 차이는 나중에 고칠 수 있는가에 있다. 잘못되었을 때 되돌아가 피해를 복구할 수 있게 만들면 어떤 결정도 작아진다. 그러면 처음의 틀린 결정과 뒤의 올바른 결정이라는 두 번의 사소한 결정을 내린 셈이 되고, 사람들은 이를 leadership으로 보기도 한다는 풍자다.
큰 결정을 피하는 핵심은 되돌릴 수 없는 일을 하지 않는 것이다. 빠져나올 수 없는 구석에 몰리지 않아야 한다. Kernel manager에게 큰 재정 책임을 맡길 사람은 거의 없으므로 보통 되돌릴 대상은 기술적 결정뿐이다. 잘못을 인정하고 사과한 뒤 지난 작업을 되돌릴 수 있다면 1년 전의 결정도 돌이킬 수 없는 결정은 아니다.
하지만 이 접근에는 두 가지 어려움이 있다. 자신이 틀렸다고 공개적으로 인정하는 일은 겉보기보다 어렵다. 또 1년 동안 한 작업이 가치 없었다는 말을 들은 engineer는 code를 삭제해 작업을 되돌릴 수 있더라도 manager에 대한 신뢰를 영구히 잃을 수 있다. 신뢰 손실은 되돌릴 수 없으므로 결국 그 결정은 큰 결정이 된다.
이를 줄이려면 처음부터 자신이 확실히 모른다는 점과 결정이 잠정적이며 틀릴 수 있다는 점을 알려야 한다. 생각을 바꿀 권리를 항상 남겨 두고 관계자도 이를 명확히 알게 해야 한다. 실제로 잘못된 행동을 하기 전에는 자신이 어리석을 수 있다고 인정하기가 더 쉽다. 나중에 틀린 것으로 드러나도 사람들은 “또 그랬군” 하고 넘어갈 수 있다.
사전 고지는 실제 작업자도 큰 일을 시작하기 전에 가치가 있는지 다시 생각하게 한다. 그들도 좋은 생각인지 확신하지 못한다면 manager가 merge를 약속하며 부추겨서는 안 된다. 작업자는 세부 사항을 더 잘 알지만 모든 답을 안다고 생각하기도 한다. Manager가 할 수 있는 최선은 무조건적인 자신감보다 건강한 비판적 사고를 심는 것이다.
결정을 피하는 또 다른 방법으로 “둘 다 하면 안 되나?”라고 묻는 풍자적 제안도 한다. 어느 접근이 더 좋은지 명확하지 않다면 결국 작업자들이 알아낼 것이다. 두 team이 모두 지쳐 포기할 수도 있지만, 이는 두 project 모두에 문제가 있었고 어느 쪽도 옳지 않았음을 나타낼 때가 많다. 결과적으로 manager는 잘못 내릴 수 있었던 또 하나의 결정을 피한다.
2. 사람과 사과
136-180문서는 대부분의 사람이 어리석다는 과장된 전제에서 시작하며, manager는 그들을 상대해야 하고 그들 역시 manager를 상대해야 한다고 말한다. 기술적 실수는 되돌리기 쉽지만 성격 문제는 그렇지 않으므로 서로의 문제를 안고 살아야 한다.
Kernel manager가 준비해야 할 중요한 원칙은 관계를 끊거나 너무 많은 kernel 개발자를 멀어지게 하지 않는 것이다. 사람을 alienate하기는 쉽고 관계를 회복하기는 어렵다. 이는 되돌릴 수 없는 행동이므로 앞 절의 원칙에 따라 피해야 한다.
- 사람을 d*ckhead라고 부르지 않는다. 적어도 공개적으로는 그러지 않는다.
- 첫 번째 규칙을 잊었을 때 사과하는 방법을 배운다.
첫 규칙은 수많은 다른 표현으로, 때로는 인식하지 못한 채 어길 수 있다. 자신이 옳다고 강하게 확신할수록 그런 표현을 쓰기 쉽고 나중에 사과하기는 더 어려워진다.
해결책은 사과에 매우 능숙해지거나, 누구도 부당하게 표적이 되었다고 느끼지 않을 만큼 비판을 고르게 하되 재치 있게 표현하는 것이다. 항상 완벽히 공손한 선택지는 현실적으로 없다고 문서는 풍자한다. 진짜 성격을 숨기는 사람처럼 보여 신뢰받지 못한다는 이유다.
각주 2: Paul Simon이 『Fifty Ways to Leave Your Lover』를 불렀던 것은 “개발자에게 d*ckhead라고 말하는 백만 가지 방법”이 노래 제목으로는 운율이 좋지 않았기 때문이라는 농담이다.
3. 자신보다 뛰어난 사람 활용하기
183-213다른 사람이 어리석다는 전제의 귀결은 자신도 그렇다는 것이다. 누구나 자신이 평균보다 낫다고 생각하지만, 자신이 가장 뛰어난 사람은 아니며 더 현명한 사람이 있다는 사실을 인정해야 한다.
똑똑한 사람에게 불편함을 느끼는 사람도 있고 그들의 능력을 활용하는 사람도 있다. Kernel maintainer는 두 번째 부류가 되어야 한다. 그런 사람은 manager의 일을 쉽게 하고 결정을 대신 내려 줄 수 있다.
자신보다 뛰어난 사람을 찾으면 “좋은 생각이니 해 보라”거나 “좋지만 xxx는 어떠한가?”라고 말하면 된다. 두 번째 질문으로 xxx에 관해 새로 배우거나 상대가 놓친 부분을 짚을 수 있다.
한 영역에서 뛰어나다고 다른 영역에서도 반드시 뛰어난 것은 아니다. 특정 방향을 제안할 수는 있지만 너무 강하게 밀어서는 안 된다. 사람들은 대개 자신이 잘하는 영역으로 자연스럽게 돌아가므로 가벼운 제안 자체는 되돌릴 수 없는 일이 아니다.
4. 책임을 받아들이기
216-239일은 잘못될 수 있고 사람들은 책임질 대상을 찾는다. Manager가 그 대상이다. 모든 잘못이 manager 탓은 아니라는 사실을 사람들이 어느 정도 안다면 책임을 받아들이는 일은 생각보다 어렵지 않다. 가장 좋은 방식은 다른 사람을 대신해 책임지는 것이다.
그 뒤 실제로 실수한 개발자를 찾을 수 있다면 공개적으로 망신주지 말고 개인적으로 무엇을 잘못했는지 알려야 한다. 같은 실수를 피하게 할 뿐 아니라, 그 사람이 문제를 고칠 가능성이 가장 높기 때문이다.
책임을 지는 일은 manager 역할을 맡는 이유 중 하나다. 사람들은 “내가 잘못했다”고 말하는 사람이기에 그를 신뢰하고 성과를 인정받을 가능성도 허용한다. 앞의 원칙을 따랐다면 manager는 이미 잘못을 인정하는 데 익숙할 것이다.
5. 피해야 할 태도
242-272사람들은 모욕 자체보다 독선적인 목소리로 하는 모욕을 더 싫어한다. 전자는 사과할 수 있지만 후자는 상대가 더는 듣지 않게 만들어 사과할 기회조차 얻지 못할 수 있다.
누구나 자신이 남보다 낫다고 생각하기 때문에 다른 사람이 잘난 체하면 특히 불쾌해한다. 실제로 주변보다 도덕적·지적으로 뛰어나더라도 일부러 상대를 화나게 하려는 것이 아니라면 이를 과시해서는 안 된다.
반대로 지나치게 공손하거나 미묘하게 말해서도 안 된다. 과도한 공손함은 문제를 숨길 수 있고 internet에서는 미묘한 어조가 전달되지 않는다. 상대가 요점을 알아서 이해할 것이라 기대하지 말고 분명하고 직접적으로 설명해야 한다.
유머는 직설성과 도덕적 훈계를 완화할 수 있다. 일부러 우스울 만큼 과장하면 상대가 공격받는다고 느끼지 않으면서도 요점을 전달할 수 있고, 비판을 받을 때 생기는 심리적 방어를 넘는 데 도움이 된다.
각주 3은 업무와 직접 관련 없는 internet newsgroup에서 가끔 논쟁하며 좌절을 풀되, 가까운 업무 관계에서는 그렇게 하지 말라는 시대적 농담이다.
6. 왜 manager 역할을 맡는가
275-290주된 책임이 다른 사람의 실수를 대신 책임지고 자신의 무능함을 공개적으로 인정하는 것처럼 보인다면 왜 이 역할을 맡는지 묻게 된다.
실제로는 다른 사람을 따라잡으려고 가능한 한 빨리 뒤쫓는 방식으로 이끌더라도, “책임자”라는 데서 큰 개인적 성취감을 얻을 수 있다. 다른 사람들은 여전히 그 사람을 책임자로 여긴다. 감당할 수 있다면 훌륭한 일이라는 문장으로 문서를 맺는다.
회사 관리자가 아니라 technical lead에 관한 글
management-style.rst:3-30이 글의 kernel manager는 예산과 조직도를 다루는 전통적인 회사 manager가 아니라 subsystem의 technical lead와 maintainer를 뜻한다. Management style은 coding style보다 개인적이고 수치화하기 어려우며, 원문은 과장과 풍자를 섞어 반복되는 질문에 답한다.