私は実際に、「技術マネージャー」がプロジェクトの日々の仕組みに深く関わりすぎるとどうなるかを見てきましたが、それは見栄えがよくありません。私たちの場合、問題のマネージャーはスクラムマスターではなく、これらの決定の一部を採用しようとしていました。実際にディフェンスをプレイするための独立したスクラムマスターがいなかったら、それははるかに苦痛だったでしょう。
（ちなみに、これは私のマネージャーではなかったので、この点についてはかなり客観的だと感じています。）
主な利害の対立として見たものを検討します。これらのいずれも自分の状況に当てはまらないと思う場合は、両方を行うことができます。ただし、これらの仮定に定期的に再チェックして、これらのトラップに陥っていないことを確認してください。
通常、技術マネージャーは複数のチーム内の特定の役割を担当します。チームが1つだけの場合、それは「マネージャー」というよりも「リード」です。この責任の分散は、チームとの時間とプロジェクト/製品との時間の短縮を意味し、「ヒットアンドラン」スタイルの管理につながる傾向があります。
技術マネージャーには、ビジネスに対する他の多くの管理上の義務があります。彼らは、コーチング/トレーニング、パフォーマンスレビュー、インタビュー/雇用、長期的なインフラストラクチャ/リソース計画などを行う必要があります。これはそれ自体で簡単にフルタイムの仕事になることができ、促進に費やす残りがほとんどないことを意味します。
忙しいスケジュールは、チームに課すこともできます。技術管理者は、チームが不適切と判断した時点でチームメンバーを会議に引き込む必要がある場合があります。通常、中断を管理して排除しようとするのはスクラムマスターの仕事ですが、心配する独自のスケジュールがある場合、そのことについて客観的になることは不可能です。スクラムマスターがチームメンバーと個別に会う必要はほとんどありません。これらのミーティングはすべて事前にスケジュールされているためです（スタンドアップ、回顧など）。
技術管理者は横断的なプロジェクトの懸念に対処する必要があり、ライブラリ、ソース管理、アルゴリズム、レイアウト、色など、すべてを標準化しようとするのが自然な衝動になります。これは実際には会社にとっては良いことですが、最終的にはチームがやりたいことをやり遂げる人を誰も残さず、彼らは何か違うことをしたいという非常に良い理由があるかもしれません。これは、スクラムおよび同様の方法論の基礎となる「継続的な改善」の理想に反します。
自分が管理する役割の専門家のバックグラウンドから来たマネージャーは、仕事をどのように行うべきか、どのくらい時間がかかるかについて、かなり強力なアイデアを持っています。これはマネージャーとしては悪いことではありませんが、スクラムマスターとして、チームメンバーに設計や他の点では同意しなかった推定値にバイアスをかけることを意味することがよくあります。
チームのメンバーは、リクエストと注文を区別するのに常に問題を抱えています。彼らはあなたにこれを伝えず、自分でそれを実現することさえできないかもしれません。単に尋ねているだけで、伝えているのではないことを明確にしたとしても、あなたは彼らのマネージャーであり、「いいえ」と言うことに対するキャリアレベルのリスクがあります。これはおそらく、すべての問題の中で最もinなものです。なぜなら、あなたはそれについて何もできないからです。それは彼らの態度であり、あなたの問題ではありません。
あなたがいる場合は必ずあなたがこれらのトラップのいずれかに分類するつもりは決してしていること、そしてそれのために行く...しかし、私は確かにあなたが作る、繰り返し頻繁に検証チームと話をして、仮定を（および他のチーム/マネージャー！）気づかないかもしれない微妙な、または無意識の状態で発生していないことを確認してください。
前向きな注意として、問題を実際に質問するのに十分に重要であると考えるという事実は、おそらく両方の役割がかなり上手であることを意味することを付け加えます。とにかく私の本の中で、あなた自身のキャリアの野望だけでなく、チームを気遣うことは、おそらく良い経営の半分以上を占めています。
...しかし、両方で良いということは、必ずしもあなたが両方の良いことを意味するものではありません、同時にすべての時間を。それに注意してください。