コミュニケーション能力が低い開発者を管理する方法
私は、大企業の中で、ライフサイクルの中間にあるアプリケーションの小さな開発者チームを管理しています。残念なことに、これはプログラミングタスクが「その他の技術作業」に30/70に分割されていることを意味します。この作業には以下が含まれます：
- DBA/Unix /ネットワーク/ロードバランサーチームとのさまざまなタスク
- さまざまな地域でのハードウェアまたはインフラストラクチャの注文と管理
- CIにまだ移行されていないテストの実行
- 分析
- サポート/調査
開発者は全員、これらのより平凡なタスクを実行するのではなく、コーディングを好むと言うのは公平であるため、楽しいプログラミングジョブをチーム間で均等に配布するようにしています。
チームのほとんどが採用されたのは、独自のコンパイラー、ゲームエンジン、高周波トレーディングシステムなどを作成するためのエリートプログラミングスキルを持っていないかもしれませんが、「仕事をこなす」ことができ、他のチームと協力する優れたコミュニケーターであるためです。 、そしてここで複雑な官僚機構をいくらかナビゲートします。彼らは優れた開発者ですが、総合的な技術スタッフとしても優れています。
ただし、チームの1人のメンバーは、平均以上のコーディングスキルを持っている可能性がありますが、平均以下のコミュニケーションスキルを持っています。従来、前の開発マネージャーは、上記のようなありふれたタスクではなく、プログラミングタスクを彼に与える傾向がありました。ただし、大企業のIT部門で一般的に必要とされる、総合的なスキルセットを開発する能力を示したチームの他のメンバーにとって、これは公平だとは思いません。
この状況ではどうすればよいですか？私が彼にさらにプログラミング作業を与え続ければ、それはより速く行われることがわかります（そして逆に、彼が他の作業をより遅く完了することを期待します）しかし、それは私の原則に反し、嫌いな仕事が苦手なだけで「快適なニッチ」を切り開くことができるという考えを促進します。
私は恨みのためにこの問題に対処しようとしていないこと、または前述のように「肩にチップ」があることを明確にしたいと思います。幸せでやる気のある、バランスの取れたチームを維持する方法についてのアドバイスを探しています。この質問に対するさまざまな答えを観察することにより、これを達成する方法についてはさまざまな意見があるようです。
丸みのあるindividualsを作成するのに労力をかけすぎて、丸みのあるteamを作成するのに十分な努力をしていません。
何かが得意であることには何の問題もありません。実際、彼が採用されたのはおそらくそのためです。まず、プログラミングが得意な人に感謝します。
あなたは述べました：
...それは私の原則に反し、嫌いな仕事が苦手なだけで自分のために「快適なニッチ」を切り開くことができるという考えを促進します。
もし彼が平凡なプログラマだったら、私はそれに同意するでしょう。しかし、あなたはそれを言わなかった。あなたは彼が良いプログラマーだと言った。彼はそれらから抜け出すための他のタスクが苦手ではありません-彼は単により良いプログラマになることに彼の努力を集中させただけです。それには何の問題もありません。
マネージャーとして、全員が「よく丸められている」ことを確認するのはあなたの仕事ではありません。 s ***が完了したことを確認するのはあなたの仕事です。そして、あなたはそれをしていません。実際、あなたはstoppingの決定を下しています。
どのような問題があっても、それを乗り越える必要があります。つまり、チームの生産性が低下します。
あなたはこの男について「何かをする」というあなたの決定に対する他の答えでここでいくつかの熱をつかんでいます、しかし私はあなたが言っていることを完全に理解します。他のチームメンバーが「これらのより平凡なタスクを実行するよりも、コーディングを好む」場合、彼らはあなたが貧しいコミュニケーターの悪いパフォーマンスに報いるを与えるだけでイライラするでしょう誰もが望むタスク。
あなたがチームの「コミュニケーター」の1人であり、そのスキルが問題の開発者に匹敵すると想像してください。あなたは上司がそうするように言っているので、あなたは電話を処理し、キーボードからマウスをほとんど知らない他の非ITスタッフと協力し、ユーザーのサインオフの計画を書きます。一方、不機嫌そうな開発者は、「コミュニケーション能力が低い」ため、「楽しい」ものだけに取り組んでいるユーザーを無視して、一日中キューブに座ることができます。
さて、不機嫌そうな開発者は「平均以上」のスキルを持っていると言いましたが、彼が最高だとは言っていませんでした。つまり、チームの3分の1、つまり不機嫌そうな開発者のスキルレベル以上の優れたコミュニケーター開発者は、すべてうんざりしています。
BEST PERFORMING STAFFの生産性を少し落とす価値はありますか？あなたが決める必要があります。
あなたがその男を解雇したくないのでなければ、私はあなたがこれらのアプローチの一つを取ることを勧めます：
1）彼をよりよいコミュニケーターになるようにメンターしてください。これが可能かどうかはあなただけが知ることができます。あなたは彼の手を少しだけ握ると助けになるかもしれません。一部の人々は、正式なビジネスの相互作用に恐怖を感じ、それを行うように求められたときに腹を立てることによってそれを表現します。
2）「良いコミュニケーション」にインセンティブを与える、お金またはその他のメリットのいずれか。あなたが実際に優れたコミュニケーターを大切にしていることを明確にしてください。そうすれば、開発者はそれほど煩わしくはありませんが、報酬は現実的で意味のあるものでなければなりません。 「地区マネージャーとの昼食」はそれを切りません。一枚の紙だけの「スタープレーヤー/クドス/アタボーイ」賞もありません。その余分なお金、余分な休暇、いくらかのフレックスタイム、昇給を管理する上級者による深刻な認識などが必要です。
まず第一に、チームメンバーを非難することは、管理能力の低下を意味します。
つまり、彼が本当にコミュニケーション能力が低い場合、私は彼の社会生活を非常に残念に思っていますが、実際には、これはこれほど問題ではありません。あなたのです。それに直面してみましょう、彼は実際には退屈あなたの鈍い作業環境、または彼のパフォーマンスに影響を与える私的な問題、またはあなたをすべて殺すために密かに企んでいる。
コミュニケーションには少なくとも2つ必要ですが、結局のところ、人のスキルが低いのはあなたかもしれません。残りのチームメンバーはかなりうまくやっていることを気にしないでください。彼らはすべて、あなたが持っているコミュニケーションの欠陥を（無意識のうちに）補い、幸いにも無視しています。
とにかく、あなたから3つの机に座っている人々についてインターネットに尋ねて回らないでください。その章に行って、本当に何か問題があるのか、それが解決できるのかどうか尋ねてください。 （または最適化または改善できる鈍いもの）
たぶん、彼は自分の机の位置を嫌っています（トイレに面していますか？）。
ヒント：彼は人的資源ではなく知性ある人間のように、答えを聞いてください。
（例：特定の実践の必要性と特定の決定の意味を詳細に説明してみてください。彼らは船を崖に追いやっていない船長がいるような感覚を彼らに与えます）
人は違う。管理者は、チームを最大限に活用するために、人を別の方法で扱う必要があります（ただし、公平です！）。
とはいえ、ソフトスキルが低い開発者が作業するのはおそらく良いことです。開発者が楽しんでいる（またはしたい）コーディング以外の、ソフトスキルの多くが関係していることを理解します。彼らにその仕事に従事してもらい、理想的には副作用としてソフトスキルを向上させるでしょう。
多くの場合、人々は仕事から抜け出すために何かが下手ではありません。彼らはそれを楽しんでいないか、適性を持っているので、彼らはそれが苦手です。あなたは後者を助けることができないので、前者に取り組みます。
30/70 splitが問題の始まりです。開発者がそのような分割に満足しているのを見たことがありません。
開発者が10、15％その他の作業に満足していることを確認しました（doseが右）しかし、30％は多すぎます。他のチームメンバーは、「他の30％の仕事」を嫌う人が1人だけいるのではなく、他のチームメンバーが自分の心を話さないほうがよいと思います。
また、「生産性の計算」をより現実的な数値に調整することも重要だと思います。 「コンテキストスイッチ」での不可避の損失のため、合計が100％になることはありません。
- 30 + 70は、プログラミングと他の作業を切り替えるときに合計100％の生産性を実現し、実際には起こりません。約20 + 50または20 + 40である可能性が高くなります。コンテキストスイッチは、ソフトウェア開発者にとって特に痛いです。興味がある場合は、この記事をチェックして、理由を説明してください。 プログラマーを起動しないでください！
生産性を重視するプログラマーは、当然、そのような損失に不満を抱くでしょう。
running testsジョブの一部について、それをテスターに渡すことを検討しましたか？プログラマーができるという事実（経験豊富なプログラマーなら誰でもできるはずだと思います）は、すべきとは限りません。テスターもそれを行うことができ、彼らはそれをよりよく行い、「コンテキストスイッチ」での生産性の損失に苦しむことはありません。
QAリソースをどのように利用するのか不思議に思うもう1つのポイントは、Support/Investigationについて言及していることです。私が一緒に働いていたプロのテスターは、そのようなことで「最初の発言」をする傾向があります。
- 私自身元テスターとして、私はそれらをかなりよく理解しています-（テスターとしての）プロダクションの問題は、テストカバレッジについて学ぶための非常に貴重なデータソースでした（「この問題は私のテストで適切にカバーされていますか？」）。欠陥の優先順位付け（「大丈夫、テストでカバーされ、リリース前に報告されましたが、適切な優先度/重大度を設定しましたか？」）。
優れたテスターにとって、サポートの問題の調査をいつ開発者に渡すかは非常に簡単ですが、これはそれほど頻繁には起こりません。これで開発者に負荷をかける理由は、単に私の心を逃れるためです。私がすでに書いたように、彼らは確かにそれをできる（私は通常、上級開発者がQAのことを行う方法を知っていると期待します）が、それは彼らがすべき。
私はこれについて2つのことを言う必要があります
コーダーまたはソフトウェア開発者を採用しましたか？
ソフトウェア開発者を検討しているとき、あなたが言及したすべてのことはソフトウェア開発の一部であり、特定のタスクだけに採用しない限り、これらを無視することはできません。 IMOの全ソフトウェア開発の50％はコーディング、残りはすべて設計、分析、テスト、文書化などです。完璧な人間は生まれません。
すべてが上手な人を見つけることができないだけです。あなたは彼らを奮闘させ、彼らに物事を学ばせなければなりません。
マネージャーとして、あなたは彼らから最善を尽くさなければならないことに同意しますが、長期的には問題に直面する可能性があります。 私はこれが苦手です/これをする余裕がないという気持ちを彼らに伝えます。何よりも、チームから最も効率的な出力を得るすべての人を平等に扱います。
スタッフ全員が同じタイトル/ジョブの説明を持ち、ジョブの説明にリストされたすべてが含まれている場合、このプログラマーは、他のプログラマー以外のタスクをより多く割り当てることにより、これらの他のスキルを磨く必要があります。同様に、他のスタッフは、プログラミング以外のタスクに継続的に取り組む必要がある（使用するか失う）場合、プログラミングスキルを研ぎ澄まされません。
しかし、私はあなたの主な優先事項はおそらくあなたの締め切りを満たすことであるべきだと私は思います（仕事を均等に分配しながらまだそれができるかもしれません）。
編集：小さなチームの場合、おそらくすべてのメンバーが複数の帽子をかぶることができるのは理にかなっています。十分な規模のチームがある場合は、さまざまな分野を専門とするグループを設けることはおそらく理にかなっています。あなたの投稿から、スペシャリストのグループを作るのに十分な規模のチームがないようです。
元の投稿から、この開発者のコミュニケーションスキルについて何が欠けているのか明確ではありません。会議に行くことや計画/調整タイプの仕事をすることに関心がないことは、必ずしもコミュニケーション能力が低いことを示しているわけではありません。たぶん開発者は、このタイプの仕事はマネージャーの仕事であると単に感じ、開発者としての彼の生産性を削減しますか？あるいは、組織のオーバーヘッドが多すぎると彼は感じており、これは彼が感じているものに対する抗議の一種であり、全体的な時間の浪費だと思いますか？結局のところ、人々が終日話し、何も成し遂げられないという反対の問題も、オフィスではかなり一般的です。
この開発者と非対立的な方法で話し、理解しようとすることが重要ですなぜ彼は非プログラミングタスクを回避します。それはおそらく単一の理由ではありません、彼は異なるタイプのタスクがあるのと同じくらい多くの異なる理由があるかもしれません。会話の目的が、チームの生産性とすべてのチームメンバーの仕事の満足度を効果的に向上させる方法を学ぶことができるようにすることを彼が理解していることを確認してください（彼に気を取られていない）。これはあなたが耳を傾けるべき時であり、ひざけりの反応に対する彼の懸念を議論したり、それに対処しようとしたりする時間ではありません。あなたはおそらく他のチームメンバーとも会うべきです。多分彼らは、この人が職業のチャットティア側に集中している間、この人に重い開発作業をさせることで完全にうまくいくでしょう。
このミーティングの後、少し時間をかけて会話について考え、この従業員の視点をオープンな心で検討してみてください。多分あなたの最初の気持ちは正しかったし、彼はあなたが彼を発達させるためにプッシュすべきいくつかの重要なスキルを欠いている。または、彼はあなたの仮定にいくつかの有効な挑戦をしました。おそらく、他のチームと協力して、いくつかのプロセスを形式化し、冗長なコミュニケーションの必要性を減らすことができます。多分他のチームは彼らの重みを引っ張っていない、そしてあなたはtheir管理者との友好的なチャットをする必要がある。あなたが考慮していない可能性がある多くの可能性があります。
最後に、そして最も重要なこととして、個人とのフォローアップ会話、または適切な場合はチームミーティングを行います。影響力の範囲内にある実際の組織の問題を特定した場合は、従業員に、仕事の状況を改善するためにとるべき行動について伝えます。それでも個々の従業員が間違っていると信じている場合は、彼と一緒に座って、彼からどのような変更が必要か、そしてその理由を説明してください。開発者は、論理的/実用的な説明によく対応する傾向があります。 「すべての楽しい仕事をあなたに与えることは仲間にとって公平ではありません。すべての人が純粋な開発者であることを望みますが、それは状況の現実ではないので、私たちはくだらない仕事の重荷を共有する必要があります。」
もちろん、この男が不機嫌そうなだけである場合、彼が不幸である理由、理由に応答しない、同僚から十分に尊敬されない理由をあなたに伝えることを拒否します...まあ...パフォーマンス改善計画の時間です。
あなたはチームを管理しようとしていて、全員にやる気を起こさせ続けたいと思っています（公平感があると助かります）が、最高のプログラマープログラミングを持たないことでプロジェクトを犠牲にしていますか？つまり、これがポイントではありません。
十分な活用ができず、最良の開発者を失うリスクを負っていませんか？あなたの仕事は、すべての人からこれらの種類の義務を試み、和らげることです。
平等に扱われるからといって、誰もが同じように扱われるわけではありません。他の人がより多くのプログラミングタスクを割り当てられるように非プログラミングの任務を緩めたい場合、どちらも上手くいかないリスクを負っていませんか？
編集：個人的な感情以外は、問題を特定していません。ある時点で、コミュニケーションの欠如はプログラマーを妨げます。他の人たちは恨みを示し、彼らの仕事は苦しむかもしれません。これまでのところ、問題を抱えているのはあなただけです。他に共有していないものがない限り、
編集2結局、誰もが特別な好意を求めるでしょう。この人はコミュニケーションを減らし、コーディングを増やします（すべてのアカウントで行う必要があります）。他の誰かが少し遅れて入ってくることを望んでいます。もう1人は、締め切りを満たすために会議をスキップする必要があります。グラフィック担当者はより大きなモニターを手に入れます。得点をつけることに力を入れすぎると、大切なことを忘れてしまいます。
私は多くのスクリプトを作成する不機嫌なLinux管理者であり、コミュニケーション能力が低いことがわかっています。私はあなたの男のように聞こえます。実際、それは私がパフォーマンスレビューで気に入る唯一の分野です。一方、私は革新と問題解決においてチームを継続的にリードしており、私たちが展開している新しいプラットフォームを作成し、その道へ導き、チームと多くの時間を節約しました。自分自身であることを許されることによってたくさんのお金。
私の上司は彼の家族/妻と私たちの会社の上級管理職に彼の立場を去るように頼まれました...彼は責任を公平にバランスさせるために精力的に働き、多くの負荷を自分で引き受けました。学部外の人とのやり取り中に、彼に戻ったコミュニケーションの誤解があった場合、彼はそれを迅速に、ああ、懲罰的に修正しました。彼は「上向きの管理」が苦手だったため、緊急になるまでリソースを入手するのが私たちのチームの最後でした。その後、同社は、テストされていないハードウェアの巧妙なセールスピッチでベンダーに過剰な支払いを行い、それらのツールを使用するチームに相談しませんでした。 「バランスのとれた」チームを作成するために、彼は私たちのタスクリストをマイクロマネージメントし、タスクのバランスを取り、チームメンバーが優れていない分野でスキルセットを改善できるようにしました。不完全に設計された実装。著者以外の人々は、壊れたコードに対して「学ぶ」ことができるように具体的にサポートタスクを割り当てられましたが、不十分に設計された実装、コード、およびテストによって、チームメンバー間に多くの悪意が生じ、実際には増加しました「非難ゲーム」の発生。これは、有毒なチームの状態への迅速なルートです。
現在の上司は、ジュニアアドミニストレーターの役割からやってきた、落ち着いて集められた個人です。彼は適切な決定を行い、チームメンバーに大きく依存して独自の優先順位を設定します。彼は優れたコミュニケーターであり、私のチームが表明したコミュニケーションの問題、アイデア、またはニーズに対して、落ち着いて上司と協力して対応します。彼は精力的に「上向きに働きます」。彼は大きなアーキテクチャの変更を行うのが遅く、私たちの環境に変更を加える前にチーム全体と徹底的に相談し、チームメンバーの専門に頼ることに慣れています。
新しいマネージャーの下で、ダウンタイムはほぼゼロになり（サポートタスクに費やす時間の割合も約40％から約10％に減少しました）、チームの満足度が高まりました。 「3〜5年ごとに新しいハードウェアを使いこなす」から5年間で年間約100万人を節約できる継続的な買収計画に移行する予定です。その計画は、前のマネージャーの下では決して起こらなかった草の根プログラムでしたが、新しいマネージャーによって積極的に上級管理職にプッシュされ、チームのスキルセットで多くの相乗効果を見つけることに依存していました。 CIOから非公式に、私たちが今では本当に「一緒に仕事をしている」唯一のチームであり、彼は私たちの作業環境にできるだけ干渉せず、問題のある領域に向けてできるだけ多くのリソースをシャッフルすることになると言われました可能な限り特定します。これは真実であり、他のチームのワークロードを混乱させましたが、サポートの「コスト」をさらに押し下げています。しかし、それらのチームのサポートの「コスト」も押し下げています。
見て、開発者がスキルセットを向上させる場所は学校か自分の時間です。彼らが物を生産する場所はあなたの会社の時間です。物事を生み出す最善の方法は、彼らが最もよく知っているものを生み出すことです。 1人の開発者が不快な領域で作業するときは、専門の2人目の開発者を引き入れてチームで作業するか、専門の開発者がコードを記述してドキュメントと図を作成する必要があります。コードを書いた人にサポートタスクをルーティングします。はい、これにより「バス要因」と呼ばれるものが増加します。つまり、スペシャリストがバスにぶつかった場合に、部門がスピードバンプにぶつかる可能性が高くなります。 （またはレイオフ、またはジョブの切り替え、または...）その真実は、その恐怖による生産性の損失は、「バスイベント」が発生したときの実際の損失よりも桁違いに大きいことです。 「バスイベント」中に一般的に起こることは、スペシャリストの仕事の継承者がそれを最も効果的にサポートできるように自分のイメージに再作成することです。オン。
最善を尽くすことができる人に物事を割り当てます。彼らに彼らの仕事をサポートさせ、文書化させなさい。彼らの創造性を育み、気を散らしたり、細かい管理をせずに集中できるようにします。それ以外はすべて管理学校のBSであり、残念ながら会社が水泳をしているように見えます。これは、チームが水泳をする必要があるという意味でもありません。
会社の観点から見ると、優れたマネージャーは会社の価値観を促進し、その価値観に従ってタスクを実行します。 IT従業員の観点から見ると、優れたマネージャーはチームができることをできる限り迅速かつクリーンに行うことができ、週末のMBAクラスで学んだ価値観を部下の喉に押し付ける上級管理職に対する糞便の障壁として機能します。あなたは会社の人であり、それはあなたのチームにとって最善ではないかもしれません。 「良い」コミュニケーション能力を持つ人はそれを言うには丁寧すぎる。
- 従業員が自分の職務説明にとってコミュニケーションスキルがいかに重要であるかを知っていることを確認してください。彼/彼女と協力して改善してください。
- 彼らがそのような仕事で他のチームメンバーと同じくらい優れていると主張しないでください。
- 自分が信じている原則に従ってタスクを割り当てます。スキルへのタスクの効率的な割り当てと公平性/楽しみのバランスを見つけます。
これらは単なる要約のアイデアです。うまくいけば、誰かがこれらのポイントを盗んで、他の答えの1つにまとめます。 ;-)
パフォーマンスがすべてです。彼にプログラミングタスクを与えます。これについて、部署の残りと話し合ってください。必要に応じて、comタスクを実行するために誰かを連れてくるか、comタスクのみでタスクを実行します。楽しいプログラミングを考えないでください。あなたの視点からすべてが「楽しい」です。
そうしないと、管理するのが非常に難しく、実際よりも効果が低い状況が発生します。
すばらしい質問ですね。それは、すべてのチームリーダー、スーパーバイザー、技術者のマネージャーが考慮すべきことです。私はあなたのアプローチが好きです、誰もが「楽しい」仕事を得るべきです。さまざまなタスクをピックアップでき、クロストレーニングを受けたチームをさらに設けることで、ピータービルトの原則が「不可解なチームメンバーがチームを去る、またはgasp休暇を取る」という大混乱を引き起こすのを防ぎます。
現在、多くの投稿で指摘されているように、仕事は公平ではなく、公平であるべきではありません。マネージャーは、どれだけの価値ある仕事が行われるかについて測定されます。
- マネージャーは、スキルに基づいてタスクを個人に一致させます。
- 優れたマネージャーは、チームのスキル、成長、関心、生産性の構築に基づいてタスクを一致させます。
- 優れたマネージャーは、少しのヘルプとガイダンスでチームにこれを実行させます。すなわちマネージャーがそれに一日を費やすことなく。
上手なプログラマと話し、彼に学びたいことがあるかどうか尋ねてください。彼が他にどんな仕事を受け入れるか…彼にとって最も不愉快なものでさえ。彼は他のチームメンバーのプログラミングを支援できますか...はい、私はコミュニケーションが問題であることを知っているので、おそらく彼はそれに取り組んでいるはずです。
これをパッケージ化するもう1つの方法は、タスクのリストを用意し、各スタッフが何かを選択できるようにすることです。あなたのよいプログラマーが最初に選ぶようにしてください。もし彼に事前に警告して、タスクのリストをもっとよく見せれば。
あなたがほとんど常に変化で行う抵抗を得るなら、彼にとって価値のあるセールスポイントを見つけてください、なぜ彼は利益を得るでしょう。最後に、あなたは彼にチームのためにそれをするように言うことができます。
また、間違いや生産性の低下が始まることを期待してください。これは、人々が学んでいる兆候です。このプロジェクトは苦しむかもしれませんが、次の方が良いでしょう。
最後に、物事が確実に完了するようにすることはあなたの仕事ですが、スタッフを増やし、プロセスに彼らをよりよく関与させることができるかどうかも同様です。物事が確実に完了するための最善の方法は、何を行う必要があるかを理解し、結果を所有するチームであると言う人もいます。
編集：ああ、試してみてください、上記のアドバイスは何年もミスをしてきたことから来ていますが、私は常にチームの成長を助けたいと思っていたので、生産性が重要であることを知っていたので、最後の試みが失敗したときに新しいことに挑戦し続けました。
ベストアンサーはすでに受け入れられていますが、マネージャーが作業できるのは「タスクの割り当て」だけではないことを誰も指摘しなかったことに驚いています。 「平均以上のコミュニケーションスキル」も備えた「平均以上のプログラマー」は、他のすべての条件が同じであれば、同様のプログラミングスキルと弱いコミュニケーションスキルを持つ人よりも給与が高く、上級の開発者である必要があります。これは、チームから認識された「お気に入り」を相殺するのに役立ちます。 （一部の組織では、「要件分析」で平均以上のスキルを持ち、他の分野で平均以下のスキルを持っていることは、行われている作業のタイプにより、会社にとってはるかに価値があるかもしれません。マネージャーとして、これを処理する方法を決定する必要があります。）
もう1つ注意する必要があるのは、問題の人にプログラミングタスクだけを与えることは、長期的な孤立につながることです。必ず他のタスクのいくつかを与え続けるようにしてください（ただし、彼らはうまくいくことができ、否定的なフィードバックを設定しないでください!!）。それらは、他の部門/チームからも見えるようになり、他の部門/チームから見えるようになります。
最後に、他のチームメンバーと定期的にチームの割り当てにanyの不平等があるかどうかを確認します。これはあなたにとって大きな懸念かもしれませんが、他のすべての人のリストでは＃15です。