#blog [https://medium.com/volvo-cars-engineering/6-ways-staff-engineers-help-reach-clarity-963c1878accb](https://medium.com/volvo-cars-engineering/6-ways-staff-engineers-help-reach-clarity-963c1878accb) # 何が書かれているか [[Staff Engineer]] がチームを助けるためにどういうパターンの問題解決の方法があるかをまとめた記事 # メモ まず、チームを助けるために重要な要素は3つ - 人 - 誰がオーナーシップを持っているか、体制はどうなっているか、組織にはどんな力学が働いてるかなど - ドメイン - ビジネスが解決している課題は何か - 技術 - どこで実行されどのようにサービス間の通信が行われ、どのようにテスト、リリース、運用されているか 以下6パターンそれぞれの場合で Staff Engineer がどのように問題解決にあたるべきかを整理している ## 1. You have the answer 「答えがあなたにある場合」  ただし関与のしすぎは、以下の壊れた Ownership Trio を作ってしまう - Knowledge - チームが独立して運用できるようにチームが知識を持つべき。 - 知識が必要になったときに Staff Engineer に頼る必要がないようにするべき - Mandate - ゲートウェイとなって許可を得なければいけない状況は避けるべきで、チームは独立して意思決定をできるべきである - Responsibility - knowledge と mandate が揃ってるのであれば、オーナーシップや責任もそのチームが持つべき ## 2. The answer is within 「答えは本人が持っているがそれが見えてない場合」  対話を通して、点と点を線でつないでいく。 この時にもチームにオーナーシップを持ってもらうように気をつける。 ## 3. The answer is out there 「答えは第三者が知っている場合」 ここは第三者が誰かによっていくつかのシナリオがありえる ## 3.1 Another person/team has the answer 「他のチームや他の人が答えを知っている」  Staff Engineer としては、答えを持ってる人とつなくことで問題を解決する ## 3.2 The answer is scattered across multiple teams/people 「答えは複数の人やチームが知っている場合」  3.1 の場合に似ているが問題の分割をまず支援する必要がある。 ## 3.3 The answer hasn't trickled down 「そもそも問題がアクションを実行できるレベルにまだ達してない」  その問題にオーナーシップを持ってる人と問題の整理をしながらアクションにつなげていく ## 4. The answer is behind an experiment 「実験を通してしか答えが得られない」( [[Cynefin フレームワーク]] でいうところの Complex な問題 )  PoC や MVP を作ってみることで (実験をすることで) 答えにたどり着く ただしここでも "you buid it, you own it" に気をつける。 深いコミットをしてしまうとオーナーシップがチームに宿らない。 ## 5. The answer is in the future 「答えは時間の経過を待つ必要がある」  ## 6. The answer is unknown 「上記以外でどうやっても答えを得ることができない場合」  わからないのであればわからないなりにリスクの分析を行って備えるようにする。 # 感想 - 問題の分類の仕方が明確で参考になった - Staff Engineer はなるべくオーナーシップを持たないような形で (チームにオーナーシップを委ねる形で) 支援をすることが大事というのが終始メッセージとして語られていた