只要是人都會抱怨，然而只要是有經驗的主管，一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣，而且對團隊，對個人都沒有任何好處。
抱怨有分不同的層級，如果僅只是抒發心情，發發牢騷當然無妨。其界限在於，在平常閒聊，抱怨的只會佔不到1/3的時間，而在平常正式討論事情，正式的會議上，抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨，大部分應該不用特別處理，畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關，更有可能的是潛在的問題，必須要試圖檢討解決。
案例一：工程師E技術能力向來不錯，然而跟他一起工作的同事，總是會反應他是個悲觀的人。追究原因發現，E無論如何都在抱怨，抱怨目前的現況和組織的做法，抱怨福利薪資等等。過了一段時間之後，團隊成員有些會受到影響，跟著開始抱怨，有些則會忽視他的抱怨。
案例二：在跨國團隊中，另一個國家的工程師會抱怨無法取得某些系統權限，而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。
主管處理嚴重的抱怨有幾個方式：
(1) 了解抱怨的事實，根據事實決定行動
如果軟體主管覺得這個抱怨的人其實是為了組織好，而且，大部分的時候抱怨者其實不那麼常抱怨，也不是士氣低落的人，他除了反映工作困難之外，也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。
以上面的案例二，雙方雖然都有道理，但主管進一步了解事實後，會發現其實某些系統的權限並沒有分group，這會讓該系統只要有權限的人統統都是最高的管理者權限，所以表面上是合作問題，其實是個技術問題，應該讓系統有不同層級的權限，另一個國家工程師也不是真的想管理這個系統，只是為了工作必須要直接使用，透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用，只是考慮安全性不應該給很多人管理者權限。
(2) 擁有改變的力量，而不是擁有「叫別人改變」的力量
許多抱怨的工程師常常會忽略「在公司裡面，我是來解決問題，而不是製造問題」
對於主管來說，如果抱怨者其實績效能力都很好，那麼應該化抱怨為力量。舉例來說，當團隊成員抱怨「現在的某系統在部署常出問題，害我需要做額外的工作」。那麼就可以先就事實詢問：「你覺得這對你很重要嗎？這是不是我們應該先解決的問題？」如果是的話，進一步應該跟抱怨者溝通：「既然這樣，你現在在做的是XXX和XXX，這兩件事就先不做，先來把某系統的部署改善，這樣以後你就不用做額外的工作」
讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了，也可以清楚地塑造團隊會往解決問題方向前進，而不會只抱怨問題。
(3) 概念性問題：先記錄並且追蹤
概念性的抱怨是指對公司政策概念的抱怨，例如：為什麼我們公司沒有work-from-home(在家工作)的政策，為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係，然而，不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。
對於概念性抱怨，應該先行記錄，並且追蹤對團隊成員的影響。舉例來說，對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因：例如需要專心工作，還是需要兼顧家人。如果是需要專心工作，可以提出會在他需要專注的時候。幫忙直接訂一個會議室，或者讓他在距離公司很近的咖啡廳工作，並且記錄一整個月，看看有沒有實質影響。也許，他以後就不想真的work-from-home，也許他會覺得在咖啡廳工作也很好。
重點在於，概念性抱怨其實應該轉為實際可追蹤執行的內容。
主管對於團隊成員的抱怨絕對不能做以下的事情：
(1) 隨意附和，隨意認同抱怨： 表面上這似乎可以拉近團隊與主管的感情，事實上，一起抱怨對大家都沒有任何實質好處。
(2) 忽略重大抱怨：如果這個抱怨是很嚴重的，忽略拖延也沒有好處
(3) 不查證事實根本原因就行動：雖然所有人都知道要查證事實，然而許多事實的根本原因其實不那麼簡單。
