マネージャー、ディレクター、VPって何が違うの？キャリアアップのリアル（2015年版）

パフォーマンスや行動の問題に対処するのはマジで時間がかかるし、関係者以外には話せないことだよね。エンジニアリング組織は、常に手入れが必要なエンジンみたいなもの。良いマネージャーはそれが上手いんだよね。

＞Dealing with performance and behavioral issues can take a huge amount of time, and it something that is never discussed with parties who are not involved.
これはマジでそう。感情的になったり、公の場で恥を晒したりせずに、もっと良い解決策が必要だよね。
最近、うちの director が部下であるマネージャーのために給料がちゃんと振り込まれてない件で、payroll に強く言ってて感動した。普段はそんな素振り見せないから、知らなかった一面を見た気がする。
マネージャーの頑張りは、もっと上の人が公に認めるべきなのかもね。

うちの会社（big tech）では、マネージャーに人を引き止める力はほとんどないんだよね。給料とかボーナスは権限外だし、評価すら自分じゃ決められない。チームを良くしようとはするけど、あんまり上手くいってないし。問題が起きても、解決してくれないし。マネージャーの仕事は、事務作業、リーダーシップとのコミュニケーション、1on1（役に立つかどうかは別として）、roadmapping と alignement の手伝い、評価のための calibration meetings への参加とか。
役に立たないとは言わないけど、難しいことはチームに丸投げって感じ。たとえば、リーダーシップの要求を拒否したり、チームのタスクの優先順位付けを手伝ったりとか。Concrete example: 今、チームは残業続きで、oncall も大変なのに、新機能の開発を優先させられてる。マネージャーは「いつでも助けるよ」って言うだけで、何もしてくれない。良いマネージャーの基準は、有害じゃなくて、摩擦やストレスを増やさないこと。それ以上は期待できないかも。

人が辞めたいって思わないように、“managing moods” も大事だよね。全部、予算とか会社の方針の範囲内でやらないといけないけど。

それな！！マネージャーの仕事の9割はムード作りだよね。

＞Case in point: trying to retain good people.
マジそれ。良いマネージャーの最も重要だけど過小評価されてる duty の一つだと思う。リーダーとして、部下には「この人のために頑張りたい！」って思わせたいじゃん。そうじゃないと、北朝鮮みたいに、嘘をついたり脅したりして、無理やり引き止めようとしなきゃいけなくなる。そんなの悲しい光景だよね。

マネージャーの仕事って、input と impact の間にラグがあることが多いよね。Retention なんてマジで遅いし、まるでクルーズ船を操縦してるみたい！

ダウンvoteされてるけど、もっともな意見だよね。離職率が高いか、管理範囲が広いから、引き留めが入るんだよ。
人が会社を辞める理由のほとんどは、ダメなマネージャーのせいだって言うしね…なんか示唆的だよね。
俺は6～7年マネージャーとかディレクターやってたけど、退職は1人だけだったよ（惜しくない退職は2人）。

中小企業は良い人材の引き留めを考えてると思うけど、大企業は誰でも替えがきくと思ってるんじゃない？俺はICだから、引き留めのための動きは全然見ないし聞かないな。まさにその通りだね。

辞めようとしてるやつを引き留めちゃダメだよ。一時的に成功しても、結局は辞めるから。

逆に、会社が引き留めようとしてきたら、一番安全な考え方は「…代わりが見つかるまで」だよね。
信用ならないし。どこもチャンスを与えてみたけど、全部ジョークだった。全然うまくいかない。
前回は5万ドル提示されたけど、もっと警戒するには足りないね。

「honor amongst thieves」って言うんだよ。例えばMF DOOM:
＞ It don’t make no sense, what happened to the loyalty?
＞ Honor amongst crooks, trust amongst royalty.

＞ The idiom is “honor amongst thieves”
これは明らかに違う。
どうしても証拠が必要なら、
＞ https://english.stackexchange.com/questions/44388/is-there-h…
にたくさん集まってるよ。

それっていつもそうかな？
マネージャーが変えられることだけが問題なら、他の場所で求めてたものが手に入れば、辞める理由なくない？

＞ マネージャー・レベルでは、ICの人が見ない、考えないような活動がたくさんある。
それって、俺が一緒に働いたダメなマネージャーがよく過大評価してたことだわ。チームを悪いことから守ってるつもりで、実はチームとコミュニケーション取ってなくて、上層部に言いなりになってるだけ。
普通のマネージャーなら、見えないところで色々やってくれてるって分かってるし、お互いに理解し合ってればうまくいく。
マネージャーが悪いことを隠してるつもりで、チームに必要な情報が伝わってないと、悪いことが起こる（そしてマネージャーは昇進して、チームはレイオフされる）。
＞ 例えば、良い人材の引き留め。
簡単だよ。正直に話して、公平に扱って、思いやりを持つだけ。
昇進させる方法や給料を上げる方法を考えるより、昇進や昇給に値しない理由を言い訳する時間が多いなら、お前はダメなマネージャーだよ。
良い人が他にやりたいことがあって、辞めるしかないなら、辞めさせてあげればいい。そうでなければ、会社のせいだよ（ダメなマネージャー、文化を壊す同僚とか）。
良い人が辞める理由は色々あるけど、会社がちゃんと扱ってないからだよ。理解できない理由で辞めるなら、「ばかげてる」んじゃなくて、お前が理解できないだけ。
良い人はプロだから、辞めることをマネージャーに伝えるのは当然だよね。
＞ 価値のある人材なら、エスカレーションして、マネージャー同士やHRと会議する。うまくいけば、引き留めに成功する。
引き留めに成功することは稀だよ（そこまで良い人材じゃない限り）。良い人が辞めたいと思う頃には、もう決意してるから、人生を変えるようなお金が必要だよ。
会社が今までひどい扱いをしてきたのに、そんな急な変化は無理だよね。
人が辞める決意をした時点で、お金で解決できると思ってるマネジメントは甘いよ。今まで不当に扱ってきたことを、お金でチャラにできると思ってるの？
＞ マネージャーとかしか知らない。他の従業員は何も知らない。
それは会社のポリシーが悪いからだよ。良い人が辞めるってことは、もう十分伝わってるはずだし、黙ってることで、他の従業員はもっと疑心暗鬼になるよ。
良い人と良い関係を築いてる人の方が、マネジメントよりよく分かってる場合が多い。
つまり、人が知らないのは、NDAを結ばせてるからだよ。
結局、ナルシストじゃなければ、親しくない人に自分のことを気にかけてほしいなんて思わないよね？
＞ 伝えたいことは2つ。マネージャーは見えないところで色々やってる。ICからマネージャーになるなら、こういうことを調べておくといいよ。
「見えない」のは過大評価されてると思う。「予想外」の方が適切だよ。
「見えない」仕事が多いなら、マネージャーは部下に伝えてないし、部下はマネージャーに責任を問えないってことだよ。コミュニケーション不足と文化の問題だよ。

従業員が完璧で、いつも正直にコミュニケーションを取るように聞こえるよ。自己批判ができなくて、対立を避けたい人も多いんだよ。それがサプライズにつながって、マネージャーにとっては最悪。

キャリアの中でいろんな役職を経験したけど、会社によって責任範囲とか仕事のレベルが全然違ったんだよね。最近レイオフされて転職活動してたんだけど、リーダーシップのポジションって、会社がマネージャーとかディレクターとかVPに何を求めてるのか読み解くのがマジ大変だった。
会社によっては「ハンズオン」が求められるし、そうじゃないとヤバいって思われることもあるし。人の管理能力とかEQが重視されることもあれば、技術力とか技術的な方向性が大事なこともあるし。前の人がやってたことをそのまま求めてたり、逆に前の人と真逆のことを期待してたりもするしね。
ソフトウェア業界のリーダーシップの肩書で唯一当てになるのは、どの会議に出席すればいいのかってことくらいじゃないかな。

似たような経験あるわー。会社の規模によって全然違うんだよね。大企業だと、ディレクターは部署内で閉じこもってて、あんまりコーディングしないことが多いと思う。でも、中小企業だと、コーディングもするし、コーダーの管理もするし、リーダーシップや戦略の議論にも参加する感じ。

マジそれ。
うちの会社（社員150人くらいのSMB）だと、VPはコード書かないけど、ディレクターとマネージャーはまだプロジェクトのICとしてコード書いてるよ。
今はマネージャーとして働きつつ、ICとしてもコード書けるのがマジで楽しいんだよね。でも、いつかコードを全く書かなくなる役職にステップアップするんだろうなーって思ってる。長期的にはそっちの方向に行きたいんだけど、コード書かなくなるのはちょっと寂しいかも。

結局、どれくらいの部下がいるかで、自分の役割が決まるんじゃない？
社員20人のスタートアップのVPと、部下200人のFAANGのディレクターじゃ、責任範囲が全然違うでしょ。
面接で「何人くらい部下がいましたか？」って聞かれるのは、そういうことだと思うんだよね。肩書なんてマジで意味ない。結局は、どれくらいの規模の意思決定に関わるかってこと。
記事にも影響力とか意思決定の種類について書いてあるけど、大企業はそんなこと気にしないと思う。どれだけの部下を抱えてたかってことしか見てないんじゃないかな。スタートアップでVPやってた人が、いきなりFAANGでVPになるなんて、まずありえないでしょ。

部下の人数は役割を理解する上で役立つけど、それでもバラツキはあるよね。でも、部下の人数が、会社があなたを採用するかどうかの判断基準になるのは確かだと思う。会社は、似たような規模の責任を負ったことがない人を雇うリスクは冒したがらないから。
実際の責任範囲はかなり違うから、部下の人数がその代わりになるんだよね。
部下の人数を重視する理由はわかるけど、それが大企業が停滞する理由でもあると思う。人が変わっても、考え方や戦略は変わらないんだよね。

＞ソフトウェア業界のリーダーシップの肩書で唯一当てになるのは
肩書だけじゃないよ。技術スタックとか、責任範囲とか書いてあっても、実際は違うことなんてザラにある。あれはただの願望だったり、計画段階の話だったり、更新するのを「忘れてた」だけだったりするんだよね。

でも、それって悪いことじゃないと思うんだよね。役割が柔軟に対応できるのはメリットだと思う。
うちの会社では、求人広告に「ソフトウェアエンジニア、全レベル」って書いてるだけだし。

＞長年の開発で一番の問題は、VPの多くがまだディレクターみたいな考え方をしてること。
＞VPの仕事は、正しい答えを出すこと。彼らはその分野の専門家。チームの誰も彼らよりその分野のことを知らない。もし知ってる人がいたとしても、VPの役割を担うのは彼らであり、正しい答えを出すのは彼らの仕事。
＞CEOが計画を立てて、取締役会で承認されて、うまく実行されたとしても、うまくいかなかったら、取締役会に「でも、でも、合意した計画ですから」とは言えない。ほとんどのCEOはそんなこと夢にも思わない。なぜなら、CEOは努力や活動ではなく、結果に責任を負うことを理解しているから。VPレベルで働くということは、この事実を理解すること。
ああ、もっと早く読んでおけばよかった。
Cスイートのメンバーがいい戦略を思いついたんだけど、エンジニアリングチームがうまく実行できなかったからうまくいかなかったんだよね。彼は計画を修正したり、エンジニアリング文化を改善したりする代わりに、負け戦の計画の詳細に固執した。つまり、彼はディレクターのように考えていたんだ。
ちなみに、今日のトップニュースは、このことが重要な理由を思い出させてくれるもの：https://news.ycombinator.com/item?id=43431675

「Strategy and the Fat Smoker」って本がおすすめ。
コンサルタントが書いた本だけど、戦略の質よりも、実行能力の方が重要だってことを指摘してる。太った喫煙者が習慣を変えられないのと同じで、正しい戦略を知っていても不十分なんだよね。

君が言った一言以上の価値ってあるの？読む意味ある？

いや、短い本だけど読む価値あるよ。チームの文化とか習慣をどう変えるかって話がたくさん書いてある。

＞[Leveling]はキャリア開発と給料交渉をごっちゃにしてる気がする。「L10になるには何をすればいいか」じゃなくて、「100万円上げてくれ」って言うべきだって促してるよね。
これってそんなに悪いことかな？ box-tickingな考え方は ownership と initiative を阻害するのはわかる。でも software engineers には、給料を決める методический で透明性のある方法が必要だと思うんだよね。じゃないと、会社にとって価値のある人じゃなくて、口が上手いだけの人が得する状況になると思う。何か見落としてるかな？

見落としてるのは、「L10になるために何をすべきか」と「会社にとって何が価値あるか」って、だいたいの場合、全然関係ないってことじゃないかな。例えば、キャリアラダーには「impact」とか設計の仕事が書いてあるけど、システムのメンテナンスの方がよっぽど重要なことって多いじゃん。それに、チームへの貢献度を測るのって難しいし。キャリアフレームワークで評価されることだけやって、それ以外を無視すれば、簡単にゲームできるんだよね。つまり、フレームワーク通りにキャリアアップを目指すように促すのは、まさに君が言う「口が上手いだけの人が得する状況」を作り出すってことだよ。

フレームワークが会社に価値を提供しないなら、そのフレームワークは欠陥品ってことじゃん。

まあ、それが著者の言いたいことなんだよ。どんなフレームワークも給料以外の何かに焦点を当ててるってことは、会社へのドル価値以外の何かに焦点を当ててるってことだよね。それでも使えるツールなのは、1)従業員のドル価値を正確に評価するのは難しいし、組織全体で標準化するのはもっと難しい、2)個人としても、「もっと価値を出せ」って言われるより、昇給のためには何をすればいいか、ある程度の方向性が欲しいから。

フレームワークなんていつも欠陥だらけだよ。
優秀なリーダーはみんな知ってる。

でも、欠陥があるからって、フレームワークは存在しちゃいけないってこと？ 欠陥があっても価値を提供できるものもあるじゃん。 leveling の場合、レベルはガイドラインであって、ポリシーじゃないと思うんだよね。ポリシーになった途端、マネジメントは対応できなくなって、価値を損ない始める。例えば、うちの会社にはレベルがあるけど（職種別）、全部のボックスを埋めないと昇進できないってことはないよ。ちゃんと説明すればいいし、レベルはガイドラインとして使うけど、全部守る必要はないと思ってる。

＞口が上手いだけの人が得する状況になる
現実にそうなるんだよね。仕事はできるけどアピールしない人は、給料が上がりにくい。良いマネージャーがいればマシになるけど。マネージャーが「Xさんの給料は低いから上げるべき」って上に言えばいいだけ。良い組織なら対応してくれる。ダメな組織は放置。ダメな組織なら自分で転職活動するしかない。組織が良いか悪いかって二元論じゃなくて、状況とか役員とか色々あるからね。 YMMV。

もし、静かで素晴らしい仕事をするけど、昇進を求めず、自分の成果を積極的にアピールしない人がいたら、給料が伸び悩む可能性があるよね。これって会社からしたら美味しい話で、低いコストでより大きな価値を得てることになるじゃん。意地悪な見方をすると、一部のテック企業は、まさにこういう行動をしがちな、自己肯定感の低い完璧主義者をターゲットにしてるんじゃないかって疑っちゃうんだよね。会社は、従業員の価値と本人が信じてる価値の差を利用しようとしてるんじゃないかって。

マジでそれあるよね。でもそういう会社って、Applied IntuitionとかScale AIみたいに「燃え尽き工場」って呼ばれるようになっちゃって、優秀なシニアを雇うのも、ジュニアが育ってシニアになるまで引き留めるのも難しくなるんだよ。結局、大人な会社は従業員を大人として扱うし、たった3年で1000万円ケチろうなんて思わないって。

開発者が不満に思うのは、より良い開発者になったことに対してお金が欲しいけど、責任を増やしたり、コードを書く時間を減らしたりしたくないってことだと思うんだよね。明確なキャリアパスが透明性と目標のために必要だってことには同意するけど、L39（とか）に上がると、会議に出たり、説得したりする責任が増えて、コードを書く時間が減るってことに気が引ける人もいるんじゃないかな。

開発者が不満に思うのは、より良い開発者になったことに対してお金が欲しいけど、責任を増やしたり、コードを書く時間を減らしたりしたくないってことだと思うんだよね。
＞問題は、より良いコードを書いたり、より多くのコードを書いたりすることで、会社にどれだけのインパクトや追加収益をもたらすことができるかには限界があるってことを理解してない人がいるってことなんだよね。それが給料を上げる根拠になるのにさ。＜br>誰かをメンターしたり、優秀な人材を採用したりする方が、2倍良いコードを書いたり、2倍速く書いたりするよりも、会社への貢献度は高いんだよ。ほとんど全てのエンジニアリングの努力において、一人の人間が貢献できる量には限界があるんだよね。

＞誰かをメンターしたり、優秀な人材を採用したりする方が、2倍良いコードを書いたり、2倍速く書いたりするよりも、会社への貢献度は高いんだよ。ほとんど全てのエンジニアリングの努力において、一人の人間が貢献できる量には限界があるんだよね。＜br>それってめっちゃ議論の余地あるよね。俺が働いてた（働いてる）ところじゃ全く当てはまらないわ。良いコードの方が、新人を再教育し続けるよりも、長い目で見たら（5年以上とか）明らかに影響デカいじゃん。

それって工場の流れ作業の話でしょ。コード書くのって、正しい問題を解決することと組み合わせれば、10倍、20倍、50倍の影響だってあり得るんだから。自動化は、良いセットアップがあれば、めっちゃレバレッジ効くんだよ。

昇進するためには、上司にゴマすって、自分の仕事とか会社のニーズを完全に無視しないといけないんだよね。

役職が上がるほど、上司の管轄外のチームに影響を与えることが重要になるから、これは当てはまらないと思うな。

この文脈での「上司」っていうのは、組織図で言うと直属の上司より1、2個上のレベルの人を指すことが多いよ。定期的に顔を合わせられる一番偉い人だと思って、そこも上手く立ち回る必要があるんだ。

言うまでもないと思ったけど…そうやって上司を追い越して、自分の部下にするんだよ。実際に見たことあるし。

「10000ドル昇給したい」じゃなくて「L10になるにはどうすればいいか」って考え方になるのを推奨してるってことだよね。
＞これの何が悪いのかわかんない。
レベルってゲームのレベルみたいじゃないことが多いよ。最近のレベルは、いろんな仕事を disguised してるみたいなもん。昔のアナリスト、アーキテクト、テックリードとかが全部「レベル」って名前で disguise されてるんだ。
レベルが上がるとコード書く量が減って、システムデザインとか、コーディネート、メンターとかに focus するかも。それって本当に「career development」なの？横移動じゃん。
＞何か見落としてる？
そう、ownership を reward して、仕事がうまくなる人を reward するべき。今のレベルシステムはそうじゃない。

これは employer によって違うよ。
うちの employer では、「software developer」を含む job family がいくつかあるんだ。software engineer、cloud engineer、architect、technical fellow とかね。
engineering role には、レベルがあるよ。software engineer I、II、III、Lead、Principal。Architect はもっと seniority が高いところから始まるんだ。architect（Lead とだいたい同じくらい）、principal architect。Technical fellow は「director level」で、software を build するのがめっちゃ得意だけど、人を manage したくない IC のための terminal spot だね。VP とか director に report することが多いけど、meeting もたくさんあるし、company の technical direction を long haul で set してるんだ。

どこで働くかによるんじゃないかな。俺はstartしてから4つ“レベル”が上がったけど、基本的に同じことしてるよ。最初からもっと高いレベルであるべきだったって言えるかもね。recognize されるのに時間がかかったんだ。

pay と rank は connection があるけど、direct connection じゃないよ。
自分の仕事の value は？自分の impact は company にとって hundreds of millions の価値がある？ salary くらい？ overhead function で business の残りを enable してる？ value がない new business idea に取り組んでる？他の人ができないことやろうとしないことができる？
これらの question への answer と交渉 skill が pay を dictate するんだ。savvy で politics を navigate したり、intentionally かどうかはともかく、well liked であることは hugely important だよ。ほとんどの company はどう progress するかとか、manager がどうやって team に compensate するかを particularly clear にしてない。HR BP は「X% の budget がある、COLA は (X - 2)% が recommend、残りは merit raise に」って言うんだ。 stack rank を求めてくる place もあるよ。effectiveness と人とうまくやる willingness が Cost of Living Adjustment より多くもらえるかどうかに effect する。promotion time には、good manager なら skill が role に fit してるか check する。bad manager は bias で pick する。pay と rank の line を draw する time だよ。leveling と rank は org design のこと。Director で 70K の人も 300K の人もいる。Leveling は HR と management のこと。Value は provide するもので compensate されるべきもの。band は things を insane にしないためのもの。Levels は guide だよ。
もし title を「Professional Enthusiast」に変えられて level を L-1 にしても、同じ仕事をして同じくらい effective なら、pay を different にしたい？ value と compensation を rest の structural stuff と differentiate しよう。management construct は good と bad manager の両方に対する check and balance だよ。いい manager で promotion する準備ができてる人がいても、HR BP が money がないって言うかも。逆に money があっても role の space がないかも。1000 人いて 100 人 VP がいる place で work したい？ who exactly が in charge？bands を break しよう。long tenured Staff/Principle engineer は band より 25% over してるけど HR や SLT は complain しない。Leveling は title inflation に対する tool。senior management への movement を restrict する？Leveling を pickier にしよう。retaining しない？bonus structure を give したり band を widen しよう。title は nice だし、private school tuition、sports car、fancy vacation を buy わない。Bali への vacation を afford できる L4 employee は org design constraints のせいで L3 と L2 に never 行けないことを all that upset にならない。
俺は slightly funny な example。Europe の multinational から California の small software company に move した。title は Director (L3) から Senior Manager (L4.X) になった。span of control は 30-60 から 6 に。job は people の number を except して same。CTO はいないし VP が 2 人いて one には “Head of” title がある。Directors もいる。title は change してるけど level はしてない。pay も a little bit up した。
hierarchy に move できる place がない。CTO を add したら down the ladder に行くし CTO level が add される。jobs の stratification に match するように leveling が stratify される。CTO が Head of Tech の上に what をする？俺の skip level が俺が work した all the other CTOs が done したこと all をしてるから not sure。
Google で work した company で、VP level の IC がいる。mandatory Senior Management type meeting に go しなきゃいけない aside から exceptionally well paid Staff/Principle engineer だよ。value が there なら nothing wrong。X を pay する need があって X が VP の band に happen した。acquisition の part で stick around した。significant title が need で CEO に report しなきゃいけなくて VP が available な currency。last job で俺が work してなかったし CTO が Director に report した。value と title が directly connect してないことを betray してる holes が work してる way にあるけど management は possible に as close as possible に come する。
10k を ask しよう。level bump を get するよりも easier かも。

article は good だね。argument に complain したい。
＞CEO は effort や activity ではなく results に対して accountable だと understand してる
IMO は American business world で biggest problem の one だよ。company を ruin long term にして “results” を get したら plan は successful。company を harm short term にして long term benefit になったら plan は failed。
long term thinking がなくて number が up and down するのを見てるだけ。superstition の form だよ。

＞誰も profit のことを気にしない。
— W. Edwards Deming

Ruin は subjective で results は objective だ。

＞“3.65ドルで grande non-fat latte か organic lettuce の head を buy できる”
Ah、2015 年。

それ見て smile した。あの innocent time が miss。

cost を report する better unit を find して。work の hour とか hard asset（real estate、gold、Bitcoin とか）。otherwise every year disappointed するよ。

Bitcoinをハードアセットと考えてるなら、その定義を教えてほしいな。

言い方が悪かったね。インフレしにくいアセットって意味だよ。長期的に価値を保てるものが良いよね。もちろん保証はないし、特にBitcoinは変動が激しいけどさ。でも、それで購買力を判断する方がマシかなって。

Big Macならいくつ買えるかな？

それとも、グランデのノンファットラテ？

今、値段が安く見えるから無実ってこと？

この記事とは関係ないけど：
＞ほとんどのレベル分けシステムは細かすぎるし、レベル間の区別も曖昧だよね。　意味のない仕事だよ。　ニセ科学だし。　官僚的で、“出世”しか考えない人を助長するよね。（「今年はちょっと自立から、かなり自立できるように成長させよう」とか言うんだよ。）”
これってよくある変な要求だよね。新米developerは質問して良いって言われるけど、質問しない方が得になるんだもん。