停滞は症状であり、診断ではありません。何か対策を打つ前に、根本的な原因を特定してください。一見すると同じように見えるエンジニアの停滞でも、原因が動機付け、スキル不足、職務適性、仕事以外の生活、単なる退屈など、異なる場合があり、それぞれの原因には異なる対応が必要です。
誠実で、プレッシャーをかけない1対1のミーティングを活用してください。オープンな質問をして聞き耳を立ててください：「最近の仕事についてどう感じていますか？」「今週で最も良かったことと最も悪かったことは何ですか？」よくある根本原因には以下が含まれます:
| 根本原因 | 役立つ傾向があること |
|---|---|
| 退屈 | 新しいチャレンジ、より大きなスコープ、ストレッチプロジェクト |
| スキルギャップ | 的を絞った学習、ペアリング、サポート |
| 動機付け | 仕事を影響力と目的に結び付ける |
| 職務適性 | 責務を自分の強みに向けて組み直す |
| 生活 | 柔軟性と忍耐力、一時的に基準を下げる |
明確で具体的な成長目標を設定して、進捗が見える状態にしてください。サポート付きのストレッチワークを与える — 再び取り組みを促すほど難しく、圧倒されないようにスキャフォールディングします。本当に新しいチャレンジを提供してください。具体的で頻繁なフィードバックを与え、進捗を声に出して認めることです。勢いは小さな目に見える成功で育ちます。
優秀なエンジニアが静かになり、出荷が減少しました。1対1のミーティングで、彼らが退屈していて、仕事が日常的になっていることが分かりました。彼らが一度も触れたことのない厄介なパフォーマンスプロジェクトを手渡します。数週間のうちに、エネルギーが戻ります。彼らが怠け者だったからではなく、彼らが充分にチャレンジされていなかったからです。
停滞をパフォーマンス問題として扱い、プレッシャーを加える本能があります。これは通常それを悪化させます。最初に実際の原因を診断することが、停滞したエンジニアを再び成長するエンジニアに変え、そしてしばしば失う可能性があった人を救うのです。