チームを率いて、私は圧倒されていますか？

私は非常に奇妙な位置にいるように見えます。私は特定のプロジェクトの役職で「チームリード」を務めています。役職はソフトウェアエンジニアです。私のチームには4人の開発者がいて、そのうちの1人は別のプロジェクトで同様の役割を果たしていますが、現在は私のものが優先されているので、彼は私のものに取り組んでいます。また、2人のテスターがいます。そのうちの1人はマネージャーです。チームの別のメンバーは、完全に無関係な部門の一部である「顧客担当者」です。また、私は私のすぐ上にいるマネージャーを持っています。私のチームの一部であるテストのマネージャーの上にもいると思います。

私は自分の役割が正確に数回ある理由を明確にしようとしました。権限がある場合でも、どこから始めてどこで終わるかを把握するのは困難でした。私が現在取り組んでいる答えは、私がチームの「技術的なリーダー」であるということです。これは、製品コード自体に関係するアーキテクチャ、設計、およびプロセス/コーディング標準に関する技術的な決定について、私の権限を持っていることを意味するようです。

今日、何かが起こり、私がチームのメンバーの1人に委任したコードの結果が、Scrum Show-It-All-Offミーティングで会社の他のメンバーに示されました。顧客の代表者が披露します。今日私は本当に異議を唱えたことを披露し、何が起こったかについて発言したいかどうか誰も私に尋ねたことがありませんでした。要するに、ユーザーが次の方法でレポートに値を表示する機能を提供するために（「doc」単位、設計単位、丸めではなく丸め）、各順列のアクセスフィールドを提供しました。したがって、値は、丸められたドキュメント単位、丸められたデザイン単位、丸められていないドキュメント単位、丸められていないデザイン単位になります。ユーザーが処理したい各レコードには多くの値があり、各レコードはこの方法で並べ替えられます。

本当に嫌いです。

これを示した人々は、レポートに使用するAPIがExcelへのデータのエクスポートなどの処理と同じであることを確認したいと考えています。残念ながら、今、私たちは本当に、本当に悪いと思う方向にこの勢いを獲得しています。

次回の会議で少し動揺しましたが、これを行った2人に「なぜこの決定に関与しなかったのですか？」と尋ねました。これは今後も発生し続ける問題であり、私が率いるチームに参加して、私が参加したいかどうかを尋ねるのは難しいようです。時々私はしないで、彼らが思いついたものは何でもいいと思う。他の回は。人々が私に尋ねない限り、私の意見を必要とする何かが起こっていることを知ることさえ難しく、彼らは私にその機会を与えません。

残念なことに、私の権限は、「次回、私と話をせずに外出して自分でこのようなことをするとき、あなたは懲らしめられます」と人々に伝えることにまでは及びません。それは「PR」の問題であり、私の権限の範囲内ではないことは明らかです。私は他の誰かが喜んでいる場合、私はその種のがらくたに対処する必要はありませんので、実際には私で結構です。

しかし、今日、私のマネージャーは皆の前で（そういうことをするのも部分的には私のせいだと思う）、私はすべての決定に関与することはできず、委任する必要があると言った。

もちろん私は正しいと思う....私はいつもそうだ。私がBSだと思うことは言いません。この問題についてアプローチして、もっと良いアイデアがあるかどうかを尋ねるべきだったと思う。これは、実際には新しい機能の最初の段階であるため、現在提供する1つの値を決定することであり、必要に応じて将来さらにアクセスを提供するためのオプションについて議論することです。現在の実装を承認したり推奨したりすることは一度もなかったし、それが日の目を見るとは思わなかった。

問題は、私は不合理な人ですか？

私たち二人はそれについて話し、私たち二人とも「ボールを落とした」ことに同意し、私たちは同じページにいるようです。月曜日の朝...チームで私の役割が明確になるようにしようとしています。そうすれば、デザインやタスクの変更が必要になる時期を判断することができます。私は提案を受け、同意するか、もっと深く見る必要があると判断します。それから、彼らが私に来ることができることを彼らが知っていることを確認するために私が取り組むことができるいくつかの他のビットがあります。

ソースのコミットを監視する必要があるようです。Perforceにはネイティブにこの機能がありますが、Gitにはフックを介して、他には独自のメソッドがあるはずです。すべてのコミットを選択する必要はありませんが、少なくとも通知を受け取ってそれらを差分化することで、プロジェクトに入るすべてのことを簡単に垣間見ることができます。

マネージャーが委任する必要があると言っているので、私は同意するかどうかはよくわかりません。4人の開発者のチームで、あなたはそれを処理できるはずです。これ以上、私は彼（または彼女）の下見張りかもしれません。もちろん、委任されたタスクであっても、ステータスの更新や設計変更などのウォークスルーを要求する必要があります。

ミーティングでネガティブなことは決して起こしてはいけません -あなたとあなたのマネージャーの両方がこのボールを落としたように聞こえます。あなたができることが絶対的な最悪のこれまでピアに行うには、それらを困らです。（マネージャーと同様に）リードとして、親しみやすく信頼できる必要があります。誰かを軽litすると、resりにつながり、チームをリードする能力が損なわれます（不満を抱く従業員につながります）。

私は嫌い先導的な役割で誰からも単語「規律」を聞きます。懲戒（少なくともこの文脈では）は否定的であり、生産的ではありません。誰かと（会議の設定ではなく個人的に）作業し、提案されたソリューションに同意しない場合に、彼らが何かをした理由を見つけ、代替案を提供することが行われるべきです。時々、あなたが働いている人が正しいとあなたの腸の本能が間違っていることがわかります。どうして？彼らはあなたが持っているよりもその特定の問題により多くの時間を費やしました。

私を心配している他の何かは、「私は常に正しいと思う」です。IMO、それはどんなリードからも最悪の態度です。あなたは明らかに自分の能力に自信を持っているべきですが、特定の問題に深く関わっていないなら、何度もあなたの提案が後から出てきます（どれだけの経験があっても）。最善を尽くす。誰か場合され、特定の問題に集中するが、代替手段を提供し、それはだあなたのために（自分自身の経験レベルに応じて、彼らだけでなく、ほか）の仕事を証明あなたが優れている理由だけで、私はリードだ」と言うとないように、私はいつも自分が正しいと思う」と言います。

まとめます

はい、あなたはいくつかの点で不合理であるが、他の点ではそうではない。リードとして、機能またはアーキテクチャの変更があった場合、少なくともそれらが合格することを期待しています。

ただし、全体的なシステムとコードの品質を確保することもあなた自身の仕事です。あなたの会社はコードレビューを採用していますか？プログラマーは、コードに入る前に自分が取り組んでいるものを設計していますか？そうでない場合は、この種の品質管理メカニズムの採用を検討することをお勧めします。

あなたは管理のためにチェックアウトされているかもしれませんが、そうであればあなたは失敗しています（これは悪いことではないかもしれません;私たちの多くは良い開発者であり、悪いマネージャーです、そして私はプログラマーを管理するよりもはるかにプログラムします）。

多くの場合、マネージャーには、期待されるすべてのことに対する権限がありません。とにかく物事を成し遂げることは、良いマネージャーのサインです。いかなる懲戒処分もせずに人々に物事をさせる方法を見つける必要があります。（注：公の人々を非難することはそうではありません。公の場で賞賛し、非難し、部下に人々としての関心を示します。）

マネージャーは、たとえ痛いときでも委任する必要があります。自分で書くよりも、この問題の処理に多くの時間を費やす可能性が高く、それで問題ありません。一度対処すれば、それをやった人は何かを学んだはずであり、将来間違ったやり方をする可能性は低くなります。

このようなものに対処する正しい方法は、最初に開発者になぜディスプレイをそのようにしたのかを尋ねるプライベートな方法です。会議ではなく、あなたが正しいと彼らが間違っていると前もって仮定することによってではありません（たとえあなたが正しいと彼らが間違っていても）。彼らに説明する機会を与えます。だからと言って、あなたが彼らの決断を受け入れなければならないというわけではありません。結局のところ、あなたは技術リーダーです。それは、あなたが彼らにあなたのやり方でそれをする理由を与える必要があることを意味します、そして、あなたはそのプライベートミーティングの間に現れる基本的な問題に対処する必要があります。

また、マネージャーは、従業員から出てくるものに対して責任があります。特に顧客の前で、彼らがすることによって盲目的にならないようにしてください。これには、コードのチェックインの追跡や、開発者との迅速なミニ会議の開催が含まれる場合があります（注意が必要ですが、ゾーンにいる間は中断しないでください）。おそらく、顧客担当者とのミーティングの前の午後に、すべての開発者と話す必要があります。

個人的に受け取らないでください

それはチームの努力です。プロジェクトの唯一の人ではなく、テクニカルリードです。チームに間違いから学ぶか、プロセスを変更することに集中する必要があります。

リードして学ぶ

技術的なリーダーを含むリーダーシップの地位の一部は、あなたが持っている人々とあなたができる限り最善を尽くすことを理解することです。チームが協力すればするほど、彼らはいつ物事を起こすべきか、そうしないべきかをより多く知るようになります。チームに口述するというtrapに陥らないようにしてください。何がうまくいかなかったか、何がうまくいったかを毎週確認してください。チームのやり方を変えたい場合は、チームとコミュニケーションを取ります。懲罰的措置は常に最後の手段であり、通常、誰かを解雇する必要があるか、役割に失敗したことを意味します。

カスタマープレゼンテーションの前に確認する

プロジェクトのリーダーが、発表前に機能と実装をレビューしなかったのはなぜですか？

間違っている場合は修正してください

何かが間違っている理由を明確に説明し、それを変更します。高価ですが、実際に間違っている場合は修正してください。それが間違っていなければ、あなたが物事をやりたかったのとは違うだけです。プロジェクトに取り組んでいるのはあなただけではないことを理解してください。

実装することになっているものを文書化する仕様はありましたか？あまりにも開かれた要件を考えると、開発者は、適切だと思うもので空白を埋める（または、マイクロ管理を必要とする）ことがよくあります。

そのため、「仕様の内容に取り組む代わりに、彼らは代わりに[機能]を実行することに決めました。そもそも承認されなかった機能のために、私たちは遅れています」とマネージャーに行きます。

その後、開発者が再割り当てされると、機能の削除作業を開始できます。

編集>そして、いいえ、私はあなたが圧倒されているとは思わない。彼らの仕事は結局あなたのお尻になります。

私はしばしば同じ立場にいることに気づき、会議や議論でそれを上げることはどこにも行かないようです。決定を下す前の最後の手段として（自分ではなく）時々、理由を書いてこれを白黒で記載したメールを関係者に送ります。

その後、そのメールをアーカイブして、将来の参考のために、マネージャーまたは顧客がそのような方法で何かが行われた理由、または修正に多大な費用がかかっている理由を尋ねるときに、後で参照できるようにします。

あなたが認めたように、あなたがしたようにそれを持ち出すのは間違っていたと思います。このレベルでの設計に何らかの入力が必要であると言うのは間違いではありませんが、それをどのように実装するのが合理的であるかはわかりません。彼らはそれが簡単であると考えている場合、人々はあなたによってデザインを実行するつもりはありません。彼らはデザインそのものについてできるのと同じくらい簡単であるのと同じくらい簡単に間違っている可能性があるので、あなたは彼らのすべての間違ったデザインを見せてくれるボランティアを見つけることはありません。この時点で、私はあなたの仕事の習慣とコミュニケーションのパターンにほとんど興味がありますが、実際にそれがどのように行われても、あなたはこれらのことに目がくらむことがあります。すべてのコミットを熱心にレビューする以外は、これに対してどのように証明するかわかりません。

私はあまりにも感情的にこのように感じる：

 I of course think I'm right....I always do. 

しかし、私は時々自分が間違っていることを知ろうとする知的感覚を持っています。私はまた、いつ戦いを選ぶべきかを知っています-あなたはすべてについて議論することはできません、そして時にはあなたの側の予期しない合意は驚異を働かせることができます。

真のリーダーとは何ですか？

できる人である火従属、任意の従属を。（ただし、新しいものを雇う必要はありません）

時々、ほとんどの人はあるプロジェクトのリーダーとして「タグ付け」されますが、誰かの火の力がなければ、それは本当のリーダーというよりも「ガイダンス」/「教師」です。

しかし、ここでも、チームのリーダーになることはできても、現在のプロジェクトをリードすることはできません。最悪の場合には、顧客がプロジェクトをリードしているときです。この時点で、プロジェクトが失敗する（そして失敗する）場合、それはあなたの責任ではありません。

そして最悪のケースは、プロジェクトのリーダーが2人いる場合です。

軍隊として、指揮系統はすべてです（「プロジェクトの死」ほど急進的ではありませんが、十分に近いです）。この問題に関して、あなたのマネージャーはあなたのステータスを破り、「あなたの」人々のモラルを下げ、全く助けませんでした。

はい、あなたの上司は正しいです-あなたはすべての決定に関与することはできません。実際、すべてを自分でやらない限り、このようなすべてをキャッチすることは不可能です。私はそこからあなたが来ていると思う-あなたはあなたがすべての小さな詳細に関与しない限りプロジェクト全体をうまく扱うことができないと感じていますが、あなたはあなたを圧倒せずにすべての小さな詳細に関与することはできませんチームとおそらく燃え尽きます）。

答えは、間違っていることを心配することではない-彼らは常にそうする-代わりに、建設的な方法で後でそれらを修正することを心配することです。

コミュニケーションを順調に進めていれば、委任できるだけでなく、年配の人々にレビュー、ディスカッション、および誤った制御を行うことで常に遠ざけることなく、必要なことがわかっていることを任せることができます。彼らが正しいことをすることを信頼し、何が起こっているかについて「チャット」するためにそこにいてください。そうすれば、あなたはループにとどまることができます（そして本当に必要と感じたら鼻を刺します）。

いくつかの問題があります。最初に、マネージャーはチームの味方になり、さらに委任するように言いました。これは、チームをリードする能力に自信がないことを示しています。実際、あなたは技術リーダーの肩書きを持っているが、実際には、あなたには権限がないため、技術リーダーではないことが示されています。あなたはマネージャーと一緒に座って、これについて心を合わせて持つ必要があります。マネージャーのサポートがなければ、チームの意思決定を変更する権限がなければ、誰も彼の同意なしにテクニカルリーダーの地位に成功することはできません。あなたには仕事をする権限がありません。あなたの上司は、あなたが勝てない立場にあること、そして彼がそれを良くするために彼にあなたの公的なサポートを与えなければならないことを理解する必要があります。権限のない責任は、自分を見つけるのに最悪の状況です。

次に、あなたのチームはあなたを盲目的にしました。これについて彼らと話をする必要があります。開発を行う前、および公開プレゼンテーションを行うはるか前に、設計の議論を行う必要があります。設計の一部を委任しても構いません（ただし、委任すべきだと思うものを決めることはできますが）、通知せずに続行することは許可されません。彼らはあなたを盲目にすることによってあなたの信頼を失いました、今彼らはより良い行動を学ばなければなりません。頻繁に確認して、彼らが再びあなたを盲目的にしないことを確認する必要があります。もしそうなら、あなたは人事に対して問題の何らかの正式な報告をするべきです。リードは、人気がないというリードではありません。開発者は、指示された後、故意にリードを迂回する場合、結果に値します。ありません 彼らがあなたを好きかどうかは関係ないが、明らかに彼らはあなたを尊重していない瞬間に。彼らは彼らの不適切な振る舞いに対して結果を出す必要があります。そうしないと悪化します。ただし、管理サポートの問題を修正するまで、問題のこの部分を修正することはできません。

次に、あなたが公然と爆発した、あなたは公に謝罪する必要があります。これは、評判を取り戻すのに役立ちます。

次に、各人を個人的に脇に置いて、彼らの継続的な悪い行動の結果を伝える必要があります（あなたが彼らに結果を与えることを許可することにあなたのマネージャーに同意したら）。国民の賞賛と支援、私的な批判があなたのルールである必要があります。また、グループnmeetingsの外部でより頻繁にチェックインする必要がある場合があります。

率直に言って、上と下の両方が、あなたは無視され、知らされない人だとはっきりと思っているので、あなたは彼らがあなたを軽視する原因について自分自身を検索するいくつかの深刻な魂をする必要があります。また、技術リーダーにならないことが幸せにならないか、責任を持って行動する権限を持つ場所に移るべきかを決める必要もあります。あなたが地位にとどまることを決定した場合、あなたは人々があなたになぜあなたをそれほど貧しく扱っているのかについてあなたに平準化するように頼まなければならないでしょう。それは苦痛であり、おそらくあなたは答えを聞きたくないでしょうが、あなたは彼らがあなたを明確に知覚する方法をなぜあなたが知覚するかを知る必要があります。