この本では、自分たちの立ち位置や、周りのチームとの関係、向かっていきたい場所、よくわかっていない未知の場所など、地図のメタファーでまとめてチームに共有しましょう、としている。
ゆくゆくテックリードをやってほしい人向けには、このチームの課題は何？とか聞いているけど、そういったものを作るうえで、地図でやってみよう、とかワークショップでやってみるのは良さそう。
次に何をやるべきか？というときにも、地図が頭に入っていれば、地図によるとそれは大きな問題なので、チャンスがあったらうまく周りのメンバーを巻き込んで進めよう、とか、その課題は見つけただけで、話してはいるけど、べつにやらなくてもいいんじゃない？とか意見することができる。
社内用語で「金脈」という言葉があって、小さい労力でコストを削減とか、売上をアップできる可能性がある部分、ということ。
以前、Redashでおもしろがって「金脈ファインダー」というクエリを作ったら、それがいつのまにかチームの仕事に組み込まれていた。
ある日、金脈ファインダーが動かないんですが…と呼ばれて、たしかに最近のRedashの設定変更で、金脈ファインダーが止まっていますね、とかそんな話をしていた。
この本では「トレジャーマップ」という地図がでてきて、真っ先に思い出したのが、金脈ファインダーだった。けど意味は違っていて、ビジネス的に一発当てるためのビジョンということ。
エンジニアリングマネージャは人に関与するけど、スタッフエンジニアはやらないのか？という目線も得たくて読んでいたのだけと、そんなことはなくて、1on1をやったり各種アドバイスしたり。直接仕事はしないけど技術的なリーダーシップを取るなど。
ただし、求められてないのにアドバイスはしない。アドバイスせずに黙っているというのも難しくて、黙っていて、その後失敗し、そうなってから、「実はあの時こう言おうと思っていたんですが…」となると、先に言ってよ、となる。
ガードレールとして、失敗しないための動きをすばやくやってあげるのがよい。
また、口を出さずにいても、我慢できなくなり、ある日言いたくなってしまう、自分でやりたくなってしまう、みたいなことも社内ではたまに見る。しびれをきらさない胆力が重要と思う。
しかしメンバーの成功が自分の成功でもあるので、やってもらいつつも、直接はこちらから手を出さず、最後には成功する、ということが求められる。
うちの会社でスタッフエンジニアとして振る舞えるか？というと、複数チームで課題になっていることを見出して企画する、みたいなことができるなら価値がありそう。
1チーム内での機能開発という目線で見ると、どうしても今の延長になってしまうし、そこから、隣のチームも巻き込んで、ここをこう変えるぞ、みたいなパワーはなかなか出せないと思う。
たとえばサーバー、アプリの両方の暮らしを見ていて、あっちでもこっちでもこれが問題になっているな、みたいな情報を得られるように慣れば、価値を発揮できるチャンスがありそう。
