何故エンジニアの上司はエンジニアである必要があるのか？｜えふしん

組織の話をしていて、何故、エンジニアの上司はエンジニアである必要があるのか？ CTOはいるがCDOがいない会社は多い。マーケティングという専門職の上司が永遠にマーケティングというわけでもない。もちろんCMOもいるだろうが、CTOに比べて常識化しているわけではない。 CTOがいる企業は増えているが、製造業の歴史的に成功した大企業がCTOがいるわけではない。 ただのエンジニアのワガママやエゴなんじゃないか？と思うことも多々ある。だから、たまに迷いが生じる。もちろん採用市場における業界の常識というのがあるので、それを無碍に無視するわけでもない。 いずれにせよ何故、エンジニアの上司はエンジニアであるべきなのか？ということを言語化できることが重要だ。 ー・ー いろいろ考えた末に、僕が一つたどり着いたものは、 ・いわゆる組織図ツリーは、ビジネスを実現するための組織図である。ビジネスが第一義になるので、

[hatest]

会社のリソースでお金を稼ぐ部隊と、そのリソースを腐らないように維持していく部隊を同じ評価基準で扱わないようにするために、上司も2種類いないといけない

[t_motooka]

これ読んで思い出したけども、これまで色んな仕事をしてきた中で「上司がQAの責任者」という環境が一番、組織として健全に機能してた気がする。リリース可否判断とかは製品をまともに見れる人じゃないと難しい。

[quick_past]

評価や組織運営は、必ずしもすぐれたプレイヤーである必要はない。ただし、実務無経験でできるわけもない。野球やサッカーの監督がわかりやすいんとちゃうのかな。トップが凄腕で常に前線に経つ。なんて必要も無い

[for-my-internet-demo]

(プも否定しがちだけどビジネスロジック主体の会社なら特にいいコード分割すらいい組織設計から始まるのは年々そう思うとこある

[fukken]

一番腕がいいエンジニアである必要はないけど、それを評価できる程度にはエンジニアである必要があるよね。

[pawpuro10]

エンジニアの組織を作って維持していくのをコストとして捉えるか、将来への投資としても捉えるのか。コストしてだけ捉えられると無理だよなー

[cbkf]

エンジニアにも日本によくある肩書としてのものと、きちんとエンジニアリングを考慮・実行できるものがあるのでね。筆者さん自身はそこも意識されているように見受けられるけども、字面しか見ない人には伝わらない。