6 ways staff engineers help reach clarity

何が書かれているか

メモ

まず、チームを助けるために重要な要素は3つ

人

誰がオーナーシップを持っているか、体制はどうなっているか、組織にはどんな力学が働いてるかなど[]

ドメイン

ビジネスが解決している課題は何か

技術

どこで実行されどのようにサービス間の通信が行われ、どのようにテスト、リリース、運用されているか

以下6パターンそれぞれの場合で Staff Engineer がどのように問題解決にあたるべきかを整理している

1. You have the answer

「答えがあなたにある場合」

https://gyazo.com/20bb72dce2c528fab12f5bdfcbc0245a

ただし関与のしすぎは、以下の壊れた Ownership Trio を作ってしまう

Knowledge

チームが独立して運用できるようにチームが知識を持つべき。

知識が必要になったときに Staff Engineer に頼る必要がないようにするべき

Mandate

ゲートウェイとなって許可を得なければいけない状況は避けるべきで、チームは独立して意思決定をできるべきである

Responsibility

knowledge と mandate が揃ってるのであれば、オーナーシップや責任もそのチームが持つべき

2. The answer is within

「答えは本人が持っているがそれが見えてない場合」

https://gyazo.com/f54120c7153a149fad58a7fa38aca365

対話を通して、点と点を線でつないでいく。

この時にもチームにオーナーシップを持ってもらうように気をつける。

3. The answer is out there

「答えは第三者が知っている場合」

ここは第三者が誰かによっていくつかのシナリオがありえる

3.1 Another person/team has the answer

「他のチームや他の人が答えを知っている」

https://gyazo.com/709d2f68bcaf733f5d0c80633ff55a40

Staff Engineer としては、答えを持ってる人とつなくことで問題を解決する

3.2 The answer is scattered across multiple teams/people

「答えは複数の人やチームが知っている場合」

https://gyazo.com/ad7fe004a56d92413334fda2dd2d5463

3.1 の場合に似ているが問題の分割をまず支援する必要がある。

3.3 The answer hasn't trickled down

「そもそも問題がアクションを実行できるレベルにまだ達してない」

https://gyazo.com/d1e2383ed16e76ab5a0d6ef7efe8a773

その問題にオーナーシップを持ってる人と問題の整理をしながらアクションにつなげていく

4. The answer is behind an experiment

https://gyazo.com/02ecb3a299494b5bb2e65ea8567995d1

PoC や MVP を作ってみることで (実験をすることで) 答えにたどり着く

ただしここでも "you buid it, you own it" に気をつける。

深いコミットをしてしまうとオーナーシップがチームに宿らない。

5. The answer is in the future

「答えは時間の経過を待つ必要がある」

https://gyazo.com/e9f5198891e26f0754b22b82fd034728

6. The answer is unknown

「上記以外でどうやっても答えを得ることができない場合」

https://gyazo.com/f72a16a237d23390218d2af4db7b4489

わからないのであればわからないなりにリスクの分析を行って備えるようにする。

感想

問題の分類の仕方が明確で参考になった

Staff Engineer はなるべくオーナーシップを持たないような形で (チームにオーナーシップを委ねる形で) 支援をすることが大事というのが終始メッセージとして語られていた