あなたが働いてきた最高のマネージャーに共通する特徴は何ですか？[閉まっている]

私はスコット・ハンセルマンとロブ・コネリーのポッドキャスト「この開発者の生活」を聞いてきました。

最新のエピソードでは、人格特性について説明します。

1.0.4-平均であること。

業界で人々が意味することは何ですか？アグレッシブはどうですか？自信がある？違いは何ですか？むしろ、上司や禅師のためのドリル軍曹を持っていますか？サイラ・リチャードソンとジャイルズ・バウケットと話をします。

あなたが働いてきた最高のマネージャーに共通する特徴は何ですか？

編集：明確にするために、いくつかの近い投票があったので、私は開発者のマネージャーに共通の特性があるかどうかに興味がありますが、必ずしも他の職業のマネージャーが必要とする特性ではありません。

これがプログラミング関連かどうかについては、プログラミングについてではないサイトでこの質問をしたくありません。率直に言って、私は生でスープの缶を作る人に興味がありません。開発者がマネージャーから何を望んでいるかに興味があるので、マネージャーから欲しい。

私の経験では、次の組み合わせです。

1. 入力ではなく、結果/出力による測定。
2. 尊敬し尊敬できる、やる気を起こさせる、心に強く訴えるリーダー。
3. チームメンバーのニーズに敏感-サポート/トレーニング/キャリアなど
4. 競合をすばやく解決し、困難な状況を拡散します。
5. あなたの仕事を理解しています-彼らは実際にあなたの仕事をすることができるかもしれませんが、それをするためにあなたを雇いました。
6. 重要ではない、またはチームの生産性を損なうものを処理/除外します。

ジョエル・スポルスキーはそれを「抽象化レイヤー」と呼んでいます。プログラミングを続けるために必要なことをしてください。会社で何が起こっているのか教えてください、しかし政治から私を遠ざけてください。私はまだそれをしなければなりませんが、少なくともリクエストが強気であることを認めます。

私のために政治的な戦いを戦い、物事を成し遂げることを妨げる障害を取り除く誰か。

期間。

彼らのために働く人々の話を聞いて喜んでである。

私は非常に技術的に傾倒したマネージャーを抱えており、マルチタスクについても知らない人もいました（「ああ、すごい！Alt-Tabのトリックをどこで学びましたか？」）私が実際に仕事をして楽しんでいたのは、彼らがすべてを知っているわけではないことを知っていたことであり、実際に仕事をしているときに、提示されたアイデア、問題、またはその仕事に関する提案を管理することになっているときに耳を傾けることでした。

彼女/彼は彼のチームを保護し、彼/彼女の責任を引き受ける

チームの1人が実稼働データでサーバーをクラッシュさせます。マネージャーが全責任を負います。彼は最終的に、ミスをした上司に話すことを拒否し、部下の前に立ちます。

時間ではなく目標に基づいて管理し、主に私がそれらの目標を達成することに関心がある

私が机に座っている時間を気にするのではなく、彼らは私が与えられた仕事を達成するために必要なものを心配しています。これが障害や障害を取り除くことを意味する場合、または私が長時間/週末に働くことを許可する場合、それらは時間とのトレードオフをいとわない。予定より早く仕事を済ませ、医師の予約や家族の活動に時間が必要な場合、彼らは柔軟で理解しています。

私は確かに職場で説明責任を持ちたいと思っていますが、それは自分が達成することのためであり、デスクでどれだけの時間を過ごすかではありません。

私が参加する必要のない会議から私を遠ざけてください。 マネージャーがこれを何とかすることができれば、彼らは無限にもっと価値があるでしょう。

私は、決定を下すために雇われ、支払われているという認識。

あなたがNOと言うと彼らはあなたをサポートします

マネージャーの最もやる気を起こさせる特徴の1つは、彼の人々のために立ち上がる勇気の欠如であり、それが製品またはチームに影響を与えることを意味する場合でも、常に自分の上司の前でお辞儀をすることです。

叫んではいけません...ただしないでください。（大きな期限、バカなテスターなどについてあなたがどれほどストレスを感じていようとも）

仕事をさせてくれる人。

プログラミングの構成を理解する。何人のマネージャーがこの問題について何も知らないことに驚くでしょう。

私は、決定を下すために雇われ、支払われているという認識。

私は、フードサービスの従業員である1時間7ドルではありません。私はここで意思決定をしています。何をすべきかの詳細をすべて聞かされたら、私もタイピストかもしれません。

（深い）共感スキル。

私が働いた最悪のボスの観点からこれに行かなければなりません-良いものはこれらの品質を持っていません：

決定を下すことができない_私が今までに扱った最悪の事態を単純化することは、誰かが彼と話すたびに彼の考えを変えたボスでした。3年間のプロジェクトで1日に4〜5回方向を変えました。

チームメンバーが行うことに対するクレジットを盗みます。私の上司は、彼らが公に与えた大きな賞を受賞しました。彼がやったと彼らが言ったことはすべて、私が実際にやった。言うまでもなく、これは極端な動機付けになります。

物事がうまくいかないときのパニック。さらにパニックになると、彼または彼女は不快になります。それは本当に物事を成し遂げるのに役立ちません。

彼自身の人々を突き刺します。彼は信用を得て、私たちは責任を負います。ANdは、必要なときにコマンドチェーンをサポートしません。

ソフトウェアの開発プロセスを理解しておらず、C＃（または他の選択した言語）を使用していることを知るのに十分な学習をすることすら気にしません。すべてが短時間で実行でき、User_interfaceページの外側の簡単な変更は、実装に時間がかからないことを意味すると考えています。締め切りの前日まで変化に着席し、「ああ、私たちがやらなければならないこと...」と言う人と、彼が求めるものは、基本的なアーキテクチャを変えるものです。

マイクロ管理するか、まったく管理しません。どちらも同様に悪いです。私は、遅すぎるまで一人の従業員に問題があることを知らなかった上司が多すぎて、他の誰もが混乱を解決するために代価を払わなければなりませんでした。また、5分ごとに煩わされるのをやめるように言わなければならない上司もいました。

政治的に素朴です。あなたの上司が彼の上の人々と政治的にうまくいかない場合、あなたは必要な人々を得るのに苦労し、あなたは最悪のスペースを持ち、レイオフでまたはそれが理由であなたが仕事を失う可能性が最も高いグループにいます彼を取り除く簡単な方法。ボスはオフィスの政治が得意でなければなりません。

プロジェクトの時間を半分に削減できると考えている人（クライアントはその数が気に入らないので）、それに応じて要件を変更することなく、その時間内にプロジェクトを完了することができます。

クレジットが必要な場所でクレジットを割り当て、それを割り当てるのに十分な知識

リッスンを追加しましたが、代わりにそれを支持しました。

1. 社内、オープンソース、またはサードパーティで開発されたライブラリにある機能を絶えず評価している人がいる場合、それは報われるのではなく、打ちのめされるべきです。
2. 実際にユニットテストを書いてそれを見つけるために誰かがすべてのバグ責任を割り当てられている場合、彼は罰せられるのではなく、報われるべきです。バグを見つけることは、そもそもバグを書くことと同じではありません。
3. 開発者または開発者のグループが期限を守るためにロバを破った場合、彼らが賞賛されるべきであり、最初に締め切りを考え出すためのマネージャーではありません。

彼らは仕事を成し遂げるために人々を信頼し、「猫を飼う」ことを試みません。

間違いを犯す（明らかに大きな間違いではない）人々に部屋を与え、彼らから学ぶ。

よく聞く人

そして

少なくとも週に1度は実際に私と話をすることを重要視している人

私には良いマネージャーと悪いマネージャーがいました。これらは私が悪いマネージャーで指摘したいくつかの特徴です：

邪魔にならないようにしましょう

優れたマネージャーは、コードを記述するための適切な機器があることを確認します。

間違った詳細をマイクロ管理する

この種のマネージャーは、そのメールの前に行った余分な作業を無視しつつ、メールに署名を付けられなかったことを噛み砕きます。

開発プロセスに関心がない

これは、ソフトウェア開発者を管理するマネージャーにとっては本当に悪い兆候です。彼は他の開発アプローチの調査については気にせず、ソフトウェアの次のリリースがどのバージョン番号であるべきかを知らず、Joel on SoftwareのようなブログやPeoplewareのような開発者の管理に関連するものを読みません。

彼が私に報告するためにそこにいると思う

この種のマネージャーは、すべてのことについて人々に彼に報告してもらうことに成功します。

時間を誤って割り当てます

開発プロジェクトの開始から完了までの1か月を考えると、このマネージャーは月の3/4を設計および要件チームに割り当て、1000行ワードのドキュメントを生成し、開発チームがそれをすべて1週間で実装することを期待します。彼はまた、要件が「完璧」になるまで要件を繰り返し、ドキュメントが使用できなくなるまで膨大な量の詳細を追加します。しかし、その後、開発プロセスの後半で、設計および要件のドキュメントにバグが見つかり、完璧なドキュメントを作成しようとすることに重点を置くことは間違いであることがわかります。

最も重要な2つの特徴は、経営原則の基本的な理解と、「私たちの1人」であることです。残念ながら、この2つはあまり頻繁に一緒に発生することはありませんが、それらが発生した場合は、優秀な人材を見つけることができます。

私が働いているところでは、プロジェクトマネージャーは元開発者です。彼は仕事の優先順位付けと指示が得意です-マネージャーが知っておく必要のあることですがそして私からの技術的な意見。

上司はこれらの両方のスキルセットも持っています。彼は実際には現在の開発者であり、他の責任が彼を引き離さない場合は、時々コードベースで作業してコミットします。彼は私たちにとって良い職場環境がどんなものかを直感的に知っているので、私たちが良い職場環境を持っていることを確認します。それは彼が働きたい条件です！

私のために戦う。ITに取り組む必要はないはずです。必要なツールを提供してくれます。会社の方針を伝えます。求められたときに決定を下し、そうでないときに留まる。

免責事項：私は以前管理職に就いていましたが、現在はそうではありません。それから私は間違いなく、テーブルの反対側にいるのはかなり難しいと言えるでしょう。

何をする必要があるかが明確で、技術的な詳細を考えさせ、必要なときにコンテキストを提供し、中途半端に終わっても要件を変更しない人。

2つのこと：

1）（またはごく最近では）開発者である。
2）上向きおよび下向きに管理します。

ポイント1は、開発者として、本当にマネージャーあなたを与えるだろう理解し、あなたの仕事が何であるかとで構成されており、理解し、あなたが（とも必要なものはありませんあなたの能力を最大限にあなたの仕事をする必要があるが）。彼らが現在開発者ではない場合（そして彼らが実際にマネージャーであるため実際に実践的な開発者であってはならない-そしてそれはフルタイムの仕事そのものである）彼らは以前の開発経験を持っているはずですが、それはかなり良いはずです最近（つまり、ここ数年）、少なくとも最新の開発言語、ツール、方法、およびテクニックに精通している。

ポイント2は、責任を受け入れ、オフィスの政治や不必要な気晴らしからチームを保護し、チームが必要なものを提供するために戦うマネージャーを提供します（したがって、ポイント1を有効にします）。彼の上（これは、あなた（開発者）とビジネス上の意思決定者（上級管理職）の間に多くのレベルと管理層が存在する大企業ではさらに重要です）。

簡単に言えば、特性（1）を持っていると、仕事を遂行するために必要なことを理解しているマネージャーが得られ、特性（2）を持っていると、必要なものを提供するマネージャーが得られます。

エールでのジョエル・スポルスキーの講演（および関連する「コマンドと征服とココナッツの群れ」記事）は、非常に簡潔に述べています。

Junoでの（悪い）管理について話すとき：

「人々に何をすべきかを伝えるためにマネージャーが存在するという前提がありました。」

Microsoftの（一般的には良い）管理について話すとき：

「マネージャーは、家具を邪魔にならないようにして、真の才能が素晴らしい仕事を行えるようにします。」

私は、枯れ木を認識し、それを取り除くことができる（そして勇気がある）人が欲しいです。これらの人々は製品に損害を与え、完成を遅らせています。あまりにも多くのマネージャーは、誰が悪い開発者であるかを認識できません（または、散らかったデスクを持っている人は悪いと思うか、実際に最も賢いまたは最も生産的な開発者であるかもしれないにもかかわらず、宇宙に飛び出しているように見える男）または、誰かが手放されていることを伝え、有能な人々に害と不満を引き起こしている枯れ木を年々とどまらせようとする必要はありません。

使用している言語やデータベースバックエンド、その他の重要なツールを知らないマネージャーに恥ずかしく思われたくありません。プロジェクトに3年間携わった後、私たちがプログラミングした言語を（クライアントの前で）尋ねました！長い間経営に携わってきた人たちが、あらゆるものの手足についてまだ最新であるとは思わないが、彼らは少なくとも私たちが何を使っているかを知っているべきだ。そして、彼らはそうしないと他の人の前にそのようなものを尋ねないように十分にスマートでなければなりません。

勇気のあるマネージャーが欲しいです。後戻りせずにその非現実的な締め切りを受け入れないでください。従業員をいじめさせたり、短期間で育てられずに乱暴な開発者を不愉快にさせたりしないでください。あなたが私が動揺するかもしれないと恐れているので、私が何か間違ったことをしているかどうかを私に言うのを忘れないでください。悪いニュースを処理するためにマネージャーが部分的に存在します。できる人が欲しいです。

私は家庭生活をしていることを理解し、疲れ果てた開発者が間違いを犯し、40時間よりも週に60時間働くプロジェクトを行うのに時間がかかることを理解しているマネージャーを求めています。

何よりも、私は良い仕事を認識し、私自身と彼または彼女の上司までのチェーンの両方の両方で口頭で感謝しているマネージャーを望んでいます。悪い仕事が良い仕事であり、間違った人々に報いると彼らが考えるとき、私は本当にそれを嫌います！

親しみやすさは私がそこに置くものだろう。上司が私のキュービクルを訪問することにした場合、私は恐怖感を感じるのが好きではありません毎回。あちこちで好意を募る友人を助けているような気がするなら、私のパフォーマンスは少し良くなるかもしれません。例えば、締め切りに間に合うようにプロジェクトを終わらせるために他の方法ではしたくないかもしれない時間。

複数の物事を管理する能力は、私が探しているもう1つの側面ですが、これはある程度明白な特性とみなされるかもしれません。競合の解決と和解のスキルも、開発者に対する開発者または開発者に対する開発者のどちらかである可能性があり、どちらかが正しいことを要求する問題に関しては、マネージャーが処理できることを知りたいと思います場合によっては、作業の一部の側面が複数の解釈を持つことがあります。

開発は工場作業ではないことを理解している人。1日あたりより多くの時間を投入しても、収量が大幅に増加する可能性はありません。プログラマーは、砥石からかなり頻繁に鼻を取り上げる必要があり、問題を解決して物事を成し遂げるために自分が取り組んでいることを考えないでください。

良いマネージャーは私にノーと言わせてくれます。彼らはソフトウェア開発が邪悪な問題であることに気づいています。したがって、たとえマネージャーが技術的に私よりも落ち着いていても、彼らは私がソリューションを実装しているので、単に私が問題をよく知っているかもしれないことに気づきます。同時に、コンテキストが欠落していることを知らせてくれます。多くの場合、マネージャーは、私が知らないことを知っていることに基づいて決定を下す場合があります。その場合は、詳細を記入するか、少なくとも私が知らないことを知っていることを知らせてください。

私は、経営陣が明らかに非技術的であるいくつかの場所で働いてきました。私の現在の雇用主は、技術的な決定を下すマネージャーは解雇の根拠であるという方針を持っています。（これは聞いたこともない小さな会社ではなく、およそ3分の1が当社の製品を運用しています）。このポリシーの結果として、少なくとも私の意見では、ここのマネージャーは他の雇用者よりもはるかに「強力」です。彼らは技術的な意思決定に関与していないため、経営陣によって行われる「わずかに非常に間違った」技術的な決定の一定のストリングはなく、彼らは大きな「製品ラインレベル」の決定のみを行います。

私が持っていた最高のマネージャーは、開発者のために「干渉」を実行する人たちです。優れたマネージャーは、「必須の会議」と必須の会議の違いを伝えることができ、あなたに知らせます。

基本的な管理スキルは、開発者に環境のコントロールを感じさせることです。これは、会社に応じて思い出させるか幻想にすることができますが、それは非常に重要なスキルです。