Marin Jankovski の README
目的
CEO ページにインスパイアされた、Marin Jankovski の README ページです。
チーム
GitLab での在職期間を通じて、複数のチームをゼロから立ち上げてオンボードしてきました。現在はプラットフォームインフラストラクチャーのディレクターを務めています。
Distribution チーム、Delivery チーム、Infrastructure Platforms のチームリードおよびエンジニアリングマネージャーを歴任しました。
GitLab のインストールに関連するタスクに取り組んだ最初のエンジニアであり、GitLab の成長に伴い、より広いスコープへの影響を与える必要性も高まっていきました。
チームを構築する際、最初に取り組むのはチームが明確なミッションとビジョンを持てるようにすることです。各チームのハンドブックページはそのチームの唯一の情報源（single source of truth）であり、チームページで発見できない情報は重要ではないと考えることができます。
時間の使い方
チームメンバー全員が最善の仕事ができるようにすること、エンジニアリングのタスク、採用の間で、私の仕事時間はコンテキストの切り替えの連続です。
タスクを把握し続けるために、バレットジャーナリングと Remarkable2 タブレットを組み合わせて使っています。毎日の終わりに翌日完了すべきタスクのリストを書き出します。毎朝の仕事開始時に、前日作成した日次リストと週次・月次プランを照合し、その日に達成したいタスクの順序を優先付けします。 これにより、短期的な最優先事項を確実にこなしつつ、中長期的なタスク群とも整合を取ることができます。また、長期計画が現在の状況に適しているかどうかを問い直すことも可能になります。
1on1
すべてのダイレクトレポートとは週次で、すべてのインダイレクトレポートとは月次で 1on1 を行います。最も一般的な通話時間は30分ですが、個人によって大きく異なります。いずれの場合も、より短くても長くても構いませんが、この呼び出しをスキップすることは好みません。
1on1 をスキップすると重要な情報が失われることを経験から学んでいます。最も些細に見える「ところで」が、後々多くの時間と労力を節約することがよくあるためです。 他の人の言葉を引用することは多くないので今回もしませんが、High Output Management - Andrew Grove は私の意見では非常に多くの点で正しいと思います。
1on1 にはある程度の構造がありますが、あくまでガイドラインです（毎週同じタイプの呼び出しがある場合や、呼び出し間隔が長い場合にインスピレーションがない場合によく起こります）。
構造は以下の通りです:
- すべてのミーティングには、ダイレクトレポートと私だけがアクセスできる Google Doc があります
- ドキュメントには、レポートが必要であれば使えるサジェストトピックのテンプレートが上部にあります
- ドキュメントはミーティングの1営業日前にレポートによって記入されます
- ドキュメントはポジティブ・ネガティブを問わず、思ったことを書き留める場所として使えます
- 予定の呼び出しより前に対処が必要な事項があれば、Slack のダイレクトメッセージで私をメンションするか連絡することができます
私の在席状況
- カレンダーは早朝と夕方はブロックしていることが多く、この時間帯はミーティングに通常応じません
- 業務用ノートパソコンには業務外のアカウントが一つだけあります: 音楽ストリーミングアプリです。業務時間外に返信している場合は、たいてい出張中か、かなり大きな行動上の変化があったということです
- スマートフォンに Slack や業務メールを設定していないため、業務用ノートパソコンの前にいない限りメッセージには返信しません
コミュニケーション
- コミュニケーションスタイルは非常に直接的で、時として人に対して怒っているように誤解されることがあります。そういった場合は、実際にそうかどうか確認してください。
- 英語は私の母国語ではなく、自己表現に影響することがあります。
frustratedとupsetなどの言葉を混同したり、文章を過度に単純化したりすることがあります。また、言われていることを翻訳するのに困っている時、I don't understandとよく言います。遭遇した場合は説明を求めてください。 - GitLab には創業期からいるため、強い所有意識があります。これにより、GitLab のためにならないと思うことに対して過度に保護的になることがあります。そのことが GitLab 全体にとって（個人やチームではなく）どのように役立つかを説明してもらえれば、賛同できる場合は支援する方法を考えます。
- 非効率が嫌いで、改善方法を常に探しています。参加者のリストを問わず、自転車置き場の議論（bike-shedding）が起きているグループ会話でも不快感を覚え、非常に直接的に発言する傾向があります。これがあなたを不快にさせる場合は、ミーティングをスケジュールして私にフィードバックを提供してください。
- 私は本来楽観的な人間ではないので、すべてを半分しか入っていないグラスとして捉える傾向があります。常に改善の余地があり、改善の部分を常に強調します。最近は本来ポジティブな性質のフィードバックを提供する方法を学んでおり、特定のフィードバックを求めることでそれを手伝ってもらうよう人々にお願いしています。 その場で提供できない場合は、私が考える時間を与えてください。それは私にとって余分な努力が必要です。
信頼
デフォルトの姿勢は、仕事上かどうかにかかわらず、全員を信頼することです。 情報を共有したくない場合や同意しない場合は相手が言ってくれると期待しているため、私のことを開けすぎ、自由すぎると感じる人もいます。
仕事では、デフォルトで意図が良いものだと信頼します。それが私の仕事かどうかにかかわらず、会社のためにならないと思うことを見かけた場合はフィードバックを提供することが多いです。 このような行動を観察した場合は、あらゆる役職の個人に直接フィードバックを提供します。
フィードバックを繰り返していると感じたり、私のフィードバックが私に直接報告せずに悪用されていると感じた場合、完全に信頼を引き下げる傾向があります。その後、信頼を取り戻すにはかなりの努力が必要になります。
このため、私と一緒に働く人には、常に直接フィードバックをタイムリーに提供し、私のフィードバックには遠慮なくタイムリーに反応してもらうようお願いしています。
