「助けたいが何を手伝おうか」と言ってエンジニアの仕事の脆弱性を診断する

どうももう1つのチームの進捗が今一っぽい。ランチタイムには、リーダ役が愚痴を垂れ流すし、セカンド役は一緒になって現状の酷さを盛るように話すのですが。

愚痴を言いたければ好きなだけ話したらいいじゃないと基本的にはスルーしているけれど、他にタイミングがなければ一息つくお昼時に言いたくはないけれど、進捗させるために何をしたらいいのかを聞いたりすることもあるのだけれど。

愚痴を言っているときには指示しても変わらない

仕事上の愚痴をエラーログのように吐き続けているときには、あれこれ言っても愚痴を言っているエンジニアは届かないのです。だって、愚痴の根元が解消されないと気はそっちに回っているので。

それを踏まえないといけないのです。

つまり、愚痴を言っているところで「お前の仕事の仕方が悪い」とか「こうやってごらん」とか言っても聞く耳を持ってもらえないのです。

進捗しないのは周りが悪いと思っているから。被害者意識ですね。的外れですけど。

逆に、優しい言葉をかけてあげると聞いていないことまで話してくれるのはエンジニアは本来優しくして欲しい生き物なんだなと思うのです。

マネージャがあれこれ言うと、進捗していない状況と言うタスクが積み上がっているかスタックしている状況で、さらにマネージャからタスクを積み上げてしまったらどうなるでしょうか。

まあ、さらに身動きできなくなりますね。だって、自力で進捗していないんですから。

だったら、助言をしようとしていることを勝手に代替してできたものをあげればいいんです。

資料の作成に手が回ってなくて、作る順番を間違えているよ、先にこっちを作らないとロジックの展開がおかしくなるよ、的なものがマネージャが気になるなら、その足らないものを勝手に作って渡せばいいんです。

ただ勝手に作って渡してもいいけれど、

「助けたいが何して欲しい」

と問いかけることでそのときエンジニアが一番気にしていることを聞き出すと言うやり方もあります。これはあれですね、ハードニングしていないOSに色々情報を聞き出すのと同じやり口と言うか、セキュリティ上の脆弱性をついて余計な情報を引っ張り出す手口ですね。

まあ、エンジニアの仕事上の脆弱性診断をするようなものかもしれません。

それはさておき、マネージャが心配してくれると思ってくれることと、頑張らなきゃと思ってくれればそれは幸いで、こちらとしては拙い進め方をテコ入れしたいだけなんだけれど、進むならどうでもいいですが。

別な切り口で言えば、背中を見せると言うことでしょうか。資料はこう作るんだよ、と。

ただ、資料を作ったマネージャは当事者でないので全ての情報を手に入れられないので、作った資料はエンジニア自身がレビューして採用するかしないかの判断をさせることを忘れてはいけないのです。

あくまでも、作業の責任者はエンジニアなので。マネージャは好き勝手に作っただけで、それを使う使わないはエンジニアが判断すればいいのです。そう言う気持ちを持って作らないと、エンジニアがマネージャのリソースをあてにしてしまうんです。それはダメです。それはエンジニアの仕事なので。