Marin Jankovski の README

目的

CEO ページに触発されて、 このページは Marin Jankovski の readme です。

チーム

GitLab での在職期間中、私はいくつものチームをブートストラップしオンボードしてきました。現在は Director of Platform Infrastructure の役職に就いています。

私は Distribution チーム、Delivery チーム、そして Infrastructure Platforms のチームリードであり、エンジニアリングマネージャーでした。

私は GitLab のインストールに関連するタスクで最初に働いたエンジニアであり、GitLab が成長するにつれて、より広いスコープに影響を与える必要も増しました。

チームを構築するとき、私が最初に取り組むタスクは、チームに明確なミッションとビジョンがあるようにすることです。各チームのハンドブックページはそのチームの単一の真実の情報源であり、チームページで情報が発見可能でなければ、重要ではないものと見なせます。

時間配分

各チームメンバーが最高の状態で仕事をできるよう支援すること、エンジニアリングタスク、採用の間で、私の 1 日はコンテキストスイッチの流れです。

タスクの上に立ち続けられるよう、私は bullet journaling と Remarkable2 タブレットを組み合わせて使います。私は毎日、翌日に完了する必要があるタスクのリストを書いて 1 日を終えます。私は毎仕事日を、前日に作成した日次リストと週次・月次プランを照合することから始めて、その日に完了することを目指すタスクの順序の優先順位を付けます。 これにより、短期で最優先項目を行いつつ、中長期のタスクセットと整合できます。このアプローチは、長期プランが現在の状況に良いものかを問うことも可能にします。

1-1

私はすべての直属の部下と週次の 1-1 を、すべての間接的な部下と月次の 1-1 を行います。最もよくある通話時間は 30 分ですが、これは個々の部下によって大きく変わります。すべての場合で、ミーティングが短くても長くても許容できると考えていますが、これらの通話をスキップするのは嫌いです。

1-1 をスキップすると重要な情報が失われることを発見しました。なぜなら、最も小さく、最も取るに足らないように見える「ところで」が、しばしば後の時間と労力を大きく節約できるからです。 私は他人を引用することが多くないので今もしませんが、私の意見では High Output Management - Andrew Grove はとても正しいことが多いとだけ言っておきます。

私の 1-1 にはいくらかの構造がありますが、それは人々がインスピレーションを得られないとき（毎週同じタイプの通話があるとき、あるいは通話の間隔が空いているときによく起こります）のガイドラインとしてだけです。

構造は次のもので構成されます:

• 各ミーティングには、直属の部下と私だけがアクセスできる Google ドキュメントがある
• ドキュメントの上部に、部下が使いたければ使える推奨トピックテンプレートがある
• ドキュメントはミーティングの 1 営業日前に部下によって埋められる
• ドキュメントは、ポジティブにもネガティブにもすべての考えを書き留める場所として使える
• 予定された通話の前に注意が必要な項目がある場合、部下は私にメンションするか、Slack のダイレクトメッセージで取り上げられる

私のアベイラビリティ

• 私のカレンダーは早朝／夕方には通常ブロックされています。この期間にはミーティングを受け付けないことが多いです
• 私は仕事専用のラップトップを持っており、そこには仕事以外のアカウントは音楽ストリーミングアプリケーション 1 つしかありません。 勤務時間外に応答している場合、それは通常、旅行中か、かなり大きな行動上の退行があることを意味します
• 私は携帯電話に Slack や仕事メールを設定していないので、仕事用ラップトップにいない限り ping に応答しません

コミュニケーション

• 私はとても直接的なコミュニケーションスタイルを持っており、人に怒っていると誤解されることがあります。 もしそう感じたら、そうなのかを確認してください。
• 英語は私の母語ではないため、自分の表現の仕方に影響することがあります。 私は frustrated と upset のような言葉を混同したり、ときに文を過度に単純化したりする傾向があります。 何が言われているかを翻訳するのに苦労しているとき、私は I don't understand ともよく言います。これに遭遇したら、明確化を求めてください。
• 私は GitLab に最初からいて、強い所有意識を持っています。 このため、何かが GitLab にとって有益ではないと考えるとき、過保護になる傾向があります。それが個人やチームではなく GitLab 全般にどう役立つかを説明してくれれば、同意するなら助ける方法を探します。
• 私は非効率が嫌いで、改善する方法を探します。これはグループ会話においても同様で、些末な議論（bike-shedding）は私を不快にし、参加者リストに関係なくとても直接的に発言する傾向があります。これがあなたを不快にするなら、私とミーティングをスケジュールしてフィードバックを提供してください。
• 私は性格的に楽観主義者ではないので、すべてをグラスが半分空だと見る傾向があります。常に改善の余地があり、私は常に改善の部分を強調します。最近、私はポジティブな性質のフィードバックを提供する方法について学んでおり、そのタイプのフィードバックを具体的に求めるよう人々にお願いしています。 即座に提供できない場合は、考える時間をください。私の側で余分な努力が必要です。

信頼

私のデフォルトのポジションは、仕事関連であれそうでなくとも、皆を信頼することです。 私は人々が情報を共有したくないときや同意できないときに発言することを期待するため、一部の人にはオープンで自由すぎると映ります。

仕事では、私は意図がデフォルトで良いことを信頼します。それが私の仕事であろうとなかろうと、会社にとって有益ではないと思うものを見たら、しばしばフィードバックを提供します。 あらゆる階級の個人に、このタイプの行動を観察したら、直接フィードバックを提供します。

自分のフィードバックを繰り返している、または直接私に提起されることなく誤用されていると感じたら、信頼を完全に取り下げて反応する傾向があります。そこから、私の信頼を取り戻すには多くの作業がかかる傾向があります。

このため、私と働く人々には、常に直接フィードバックを適時に提供すること、そして躊躇せずに私のフィードバックに適時反応することをお願いします。

ページのソースコードを見る - ページの編集 - please contribute.