GitLabのOrganization Structureを読む[1/2]

Unknown Protocolでは何かとGitlabが使っていた技術を捨てて新しい技術を取り入れているところを書いてきたが、ついに上場するらしい。

Gitlabはリモートワークなど社員の働き方に関するドキュメントの整備も有名だが、その中でも特に、よくここまで書いたなと話題のOrganization Structureについて目を通してみる。

1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？

Organizational Structure

文書構成としてはManagerに求められる37項目、Director、Senior Leader（Senior DirectorやVP）、Executiveは下記の９分野に対して求められる「レベル」が書かれている。

Scope
Complexity
Decision Making
Influencing ability
Leadership
Business Expertise
Functional Knowledge
Values Alignment
Remote Working

まずは大量にあるManagerの37項目からいくつかピックアップしてみる。

Ensuring team members feel included and valued is one of the most important tasks of a manager. Proactively create psychological safety with your team members so that diverse perspectives can be heard and everyone can communicate and contribute authentically and creatively.

チームメンバーがincluded(参加している)とかvalued(評価されている)と感じられるようにensure(確実)にすることがマネージャーの最も重要なタスク。そのために心理的安全性をproactively(積極的)に作り、多様なperspective(視点)が聞かれ、誰もがコミュニケーションを取りauthentically(真に)かつcreatively(創造的に)貢献できるようにする。

こういったことを一番最初に書くところが素晴らしいと思う。

Managing underperformance is another important task of a manager. 
When times are great, be a voice of moderation. When times are bad, be a voice of hope.

underperformance(パフォーマンスの低下)を管理することも、もう一つの重要なタスク。greatな時はmoderation(節度)の声になり、badな時はhope(希望)の声になること。

メンバーと一緒に浮かれたり落ち込むようなマネージャの方が愛されたりするけど、会社が求めるマネージャ像はそうではないですよと。

To maintain an effective organization, a manager's span of control should be around 7 people, ranging anywhere from 4 to 10.

マネージャの管理範囲は4～10人で、3人以下だと組織階層が非効率的で、11人以上だと1:1を実行する時間が取れない。

マネージャが自分で管理する人数を決められるのか所掌範囲が気になるが、マネージャ自身が気付くべきことであるのは間違いない。

When you praise someone, try to do it publicly and in front of an audience. When you give suggestions to improve, do it privately 1 on 1.

称賛するときは聴衆の前で、改善するためには1:1でやること。

こういうことを明文化しないといけない（逆に言うと、人前で叱る人が後を絶たない）のって日本だけじゃないんだなと。

Express gratitude in team meetings, group conversations, and other communications to people who constructively challenge your opinions and ask difficult questions.

あなたの意見に対しchallenge(異議・挑戦)を唱える者に対し、感謝の意を示すこと。

challengeが「異議」というニュアンスで使われることがあるのは知りませんでした。。。

In addition to announcing new team member arrivals, departures are also announced in the #team-member-updates chat channel (but only after the Google/Slack accounts are revoked, see the offboarding page and the offboarding checklist for details).
We must respect the privacy of the individual concerned. If you are asked why someone has left or is leaving, please refer that person to the general guidelines section of the handbook where we describe what can and cannot be shared.

人事情報はSlackで発表される。なぜ辞めたのか理由を聞かれた場合、共有できるものとできないものが書かれているハンドブックを参照すること。

もしやと思ってクリックしたら、ちゃんとハンドブックまで公開されていた。こういった情報は公開してはいけないという一覧になっている。

Don't refer to GitLab as a family. Families come together for the relationship and do what is critical to retain it. Teams are assembled for the task and do what is required to complete it. Don't put the relationship above the task. Besides, families don't have an offboarding process.

家族はrelationship(関係)のために集まり、チームはtaskのために集まっている。タスクより関係を重視してほしくないから、Gitlabをファミリーとは呼ばないでほしい。

Pick a metric before launching something new. 9 out of 10 launches fail. If a project is not working out shut it down completely. Starving a team of headcount to have it die a slow death is not frugal nor motivating.

新しいものを立ち上げる前にmetricを選択してください。10のローンチのうち9は失敗する。プロジェクトが機能しない場合は完全にシャットダウンすること。チームをstarving(飢え)な状態にすることはfrugal(質素)でもmotivating(動機付け)でもない

metricをどう日本語を当てはめるか悩んだが「全部をやろうとするな」ということかなと。

Follow Berkshire's common injunction: "Always tell us the bad news promptly. It is only the good news that can wait."

「悪いニュースは迅速に伝えること。待つことができるのは良いニュースだけ」

元ネタはBerkshire Hathawayの幹部の発言らしい。

Try to avoid military analogies and imagery. We're not an army, we're not at war, there is no battle, we're not killing anyone, and we don't have weapons. Military language is not inclusive and can lead to zero sum thinking.

軍事用語を使うのはやめよう。我々は誰も殺さない。またゼロサム思考になる。ただしUnixのkillはしょうがない。あとマスター・スレーブはプライマリ・セカンダリと呼ぼう。

これ、自分も気になっていたがGitlab以外では見たことがないかも。

Create empathy for decisions from other leaders that negatively impact your team by explaining the reasons behind them. Organize a recorded AMA session with your team and the other leaders and encourage your team (as well as yourself) to ask any unanswered questions.

他のリーダーが自分たちのチームにネガティブな決定をしたとしても、その背後にある理由を説明し、決定に対して共感を示そう。AMA(RedditのAsk Me Anything)を整理しよう。

自分が今の会社でマネージャとして仕事をする中で目にするのは、もっと堅苦しい表現だったりする。GitlabのOrganization Structureの自然な書きっぷりに触れ、より優れた業績を生むマネージャー像をイメージするのに役立つかもしれない。

次回はDirectorより上の役職について読んでみる。