1. 程式人生 > >管理者必須知道的:你真的會懲罰你的團隊嗎?

管理者必須知道的:你真的會懲罰你的團隊嗎?

前言

前段時間寫了一篇團隊激勵的文章,今天再來說說“懲罰”的話題。

有一次跟一個雷厲風行的管理者聊天,聊到了員工管理的話題。他很苦惱的說,他的下屬平時工作態度還算挺不錯的,對公司也有一定的歸屬感。但經常有個讓他很惱火的情況,就是他在安排了一件事之後,下屬沒有深入思考就反饋說做(或解決)不了。但在他看來,那些都是非常容易解決的事情!

所以,這位老闆跟我探討:這個情況下,是否應該懲罰這個員工?

這個問題暫且先放一邊,我們來看一下另外一個問題:就是下屬說問題無法解決,上位者應該怎麼辦?

我的看法是,有些問題下屬說無法解決,可能是因為下屬沒有意識到他們可以申請更多的資源來解決,也可能是下屬沒有深入尋找問題的根源而導致無法解決。這個時候若作為管理者,應該分清楚不能解決的問題的根源,針對不同情況作出不同的判斷,並引導員工調整自己的思路。當然,如果是老闆,可能方式可以更粗暴一點:不幹,gun!

作為管理者,如果只是簡單粗暴的採取懲罰措施,可能並不能真正解決問題。

說說以前我經歷的一件事。

背景

以前有一個下屬,平時表現很不錯,積極、主動、很少犯錯。

但有一週,她負責的系統出現好幾起漏測bug,而且嚴重程度很高。找她瞭解完情況後得知,原來她剛跟男朋友分手,所以這幾天工作不在狀態,測試的時候甚至都搞不清楚自己到底在做什麼。

這種情況應該怎麼處理?

應該懲罰嗎?沒有處罰的話,這名員工還可能多少心存愧疚,如果處罰了,反而可能會怨恨我和公司不近人情。出了這種事,公司和領導一點都不關心她,同情她,反而懲罰她。如果他對公司產生了不滿的情緒,以後表現是不是可能更差?

應該放任不管嗎?這名員工雖然平時表現還不錯,但如果大家都像她這樣,出了質量問題也沒有任何懲罰,可能以後還會出現這種情況,那質量就沒法保證了。如果其他下屬出了問題,也找一些我無法核實的藉口怎麼辦?

要不就警告一次,然後象徵性的罰一點現金?

可這樣的懲罰手段真的有用嗎?

懲罰以後,事情會變好嗎? 能保證以後不會再出現這個情況嗎?

處罰的目的是什麼?

處罰的目的,應該是警示員工,讓員工不再犯類似的錯誤,是這樣吧?

回過頭來想,假若我對這名下屬進行懲罰,能阻止她再犯類似的錯誤嗎?不能吧。說句不好聽的,假設她下次又出現感情問題,她能放下感情問題然後集中精力到工作中來?顯然不太現實。

從這個角度想,只期望通過懲罰措施來避免類似問題的出現,是不現實的。

既然懲罰這名員工達不到我們的目的,我們應該怎麼做?

怎麼辦?

這個問題現在已經轉化成:我應該怎麼做才能減少或避免下屬出現這個問題。

假設某個下屬再次出現這樣的情況,如果繼續讓他負責當前的工作,可能無論我平時怎麼強調質量、認真工作都沒有用,因為絕大多數人在那種情況下都無法控制好自己的情緒。所以有兩個選擇,換一個人來暫時替代他的工作,同時加強檢驗。

後來,我在組裡宣佈了這樣一個制度:當經歷重大變故無法很好的完成當前工作時,主動跟我反饋,可以申請調休或申請其他工作。我來重新調整工作安排。否則,因為個人原因導致出現質量事故,按公司要求進行處罰。

讀到這裡,可能有讀者會疑惑:會不會有員工借這個理由來怠工啊?

我覺得不用擔心。作為一個管理者,手下是什麼樣的人,我還是能掌握一些情況的。如果真有人想鑽制度的漏洞(或者經常性出現“重大變故”),這個人也就不合適工作了。而且,如果申請調休,是沒有工資的,正常人都不會在這個制度上犯渾的。

總結

員工犯了錯,我們習慣性思維就是對員工進行懲罰。但不要忘記,懲罰不是目的,改善問題和減少以後出錯概率才是處罰的目標。如果兩個目標都無法實現,處罰就沒有作用。要求員工實現自己根本無法實現的目標只會激起員工的反感。管理者在對員工做出懲罰時,需要時刻牢記這個原則。

相關推薦

管理者必須知道真的懲罰團隊

前言 前段時間寫了一篇團隊激勵的文章,今天再來說說“懲罰”的話題。 有一次跟一個雷厲風行的管理者聊天,聊到了員工管理的話題。他很苦惱的說,他的下屬平時工作態度還算挺不錯的,對公司也有一定的歸屬感。但經常有個讓他很惱火的情況,就是他在安排了一件事之後,下屬沒有深入思考就反饋說做(或解決)不了。但在他看來,那

雲端計算之必須知道的幾個議和雜誌

雲端計算現在被大家炒的熱火朝天,那麼很多人也想更多瞭解雲端計算。那麼我就給大家介紹幾個雜誌和網站。 IEEE International Conference on Cloud Computingh

知道CPU結構也影響Redis效能

啦啦啦,我是賣身不賣藝的二哈,ε=(´ο`*)))唉錯啦(我是開車的二哈),我又來了,鐵子們一起開車呀! 今天來分析下CPU結構對Redis效能會有影響嗎? 在進行Redis效能分析的時候,通常我們會考慮下面這些方面,如:   1. 縮短 key 的長度   2.

又一年沒有中國隊的世界杯,熬夜打call?網友的回答亮了

俄羅斯 .... 評論 一個 fff CA 圖片 通過 mage 作為足球界的第一盛宴,2018年俄羅斯世界杯將於明天點燃戰火,持續整整一個月。Giiso小智就想問,真球迷、假球迷、或是偽球迷,你們準備好要陷入這四年一度的狂歡了嗎? 根據公開的信息,目前可以通過央視、優酷

真的用二分查詢

二分查詢寫起來真的簡單嗎?未必! 嗯,其實最簡單的二分查詢寫起來還是挺簡單的,稍微注意下可能出錯的地方即可。用迴圈還是遞迴都可以,我這裡先寫一個 你們也可以搜一下有沒有更好的寫法 /** * 二分查詢 * @param a 源陣列 注意這個陣列的值一定是經過排序的有序陣列

真的搭建測試環境

經常在面試過程中,面試官總要問一句,熟悉linux命令麼? 同時在很多招聘的JD上都有明確指出需要測試人員會搭建測試環境,而且這不僅是體現在高階測試工程師的崗位要求,同時初級測試工程師同樣也被要求了。 1.什麼是測試環境 測試環境(Testing environment)是

海天醬油揭祕人工智慧能產生“自我意識”?

人工智慧不是人的智慧,但卻是像人那樣思考、也很可能超過人的智慧,本身就是基於對人的意識、思維資訊過程的模擬。那麼,未來擁有自我意識和情感的超級人工智慧到底會不會出現?人工智慧是否真的能發展出“意識”,讓人類生存受到威脅?海天味業來揭祕。 事實上,它們不會有任何意識。科幻小說常常把智慧和意識混

真的寫二分查詢

1 二分查詢   二分查詢是一個基礎的演算法,也是面試中常考的一個知識點。二分查詢就是將查詢的鍵和子陣列的中間鍵作比較,如果被查詢的鍵小於中間鍵,就在左子陣列繼續查詢;如果大於中間鍵,就在右子陣列中查詢,否則中間鍵就是要找的元素。 (圖片來自《演算法-第4版》) /** * 二分查詢,找到該

真的用Google搜尋引擎

對於一個搜尋引擎的演算法,搜尋的頁面是匹配所有的關鍵詞,還是僅包含關鍵詞的任意次就可以,稱之為搜尋引擎的布林邏輯預設值。搜尋引擎可以使用布林邏輯與:AND(搜尋到所有關鍵詞),或者使用布林邏輯或:OR(搜尋到任意一個關鍵字即可)。就是搜尋引擎預設布林邏輯也不是說只能用這種邏輯,可以通過一些特殊的命令來執行其他

程式設計師開發學習利器篇(上)之百度搜索-真的用百度

以下內容,開發初學者看,熟手略過。 論語有言: 工欲善其事 必先利其器 ,意思是工匠想要使他的工作做好,一定要先讓工具鋒利。比喻要做好一件事,準備工作非常重要。 這對於我們程式設計師做開發時也是這樣,充足且好的準備工作,不但可以提高我們的開發效率,同時也可以讓我們事半功倍

真的寫單測?TDD初體驗

前言:   昨天讀到了一篇文章,講的是TDD,即Test-Driven Development,測試驅動開發。大體意思是,它要求在編寫某個功能的程式碼之前先編寫測試程式碼,然後只編寫使測試通過的功能程式碼,通過測試來推動整個開發的進行。這有助於編寫簡潔可用和高質量的程式碼,並加速開發過程。   初讀之時,瞬間

C#刨根究底必須知道的.NET》讀書筆記系列

wid 最終 table bsp 圖解 萬能 展望 應用 light 一、此書到底何方神聖?   《你必須知道的.NET》來自於微軟MVP—王濤(網名:AnyTao,博客園大牛之一,其博客地址為:http://anytao.cnblogs.com/)的最新技術心得和感悟,

必須知道的.NET》讀書筆記一小OO有大智慧

實現 職責 可靠性 基本 code cfile 生存 最好 min() 此篇已收錄至《你必須知道的.Net》讀書筆記目錄貼,點擊訪問該目錄可以獲取更多內容。 一、對象   (1)出生:系統首先會在內存中分配一定的存儲空間,然後初始化其附加成員,調用構造函數執行初始化,這

關於JAVA必須知道的那些事(三)繼承和訪問修飾符

今天乘著還有一些時間,把上次拖欠的面向物件程式設計三大特性中遺留的繼承和多型給簡單說明一下。這一部分還是非常重要的,需要仔細思考。 繼承 繼承:它是一種類與類之間的關係,通過使用已存在的類作為基礎來建立新類。其中已存在的類稱為父類(或基類); 建立的新類稱為子類(或派生類)。簡單的就是子類繼

關於JAVA必須知道的那些事(二)封裝

時隔近一年,我突然想起來這個文章還沒有發完,所以就繼續開始寫。也不知道自己上次寫到哪裡了,不管了這裡從面向物件的三個特性說起。 類和物件 在這之前,我們先了解什麼是物件,已經什麼是面向物件?物件:萬物皆物件,現實中實際存在的事物都可以看成一個物件。而面向物件就是人在關注物件, 關注事物的資訊

關於JAVA必須知道的那些事(四)單例模式和多型

好吧,今天一定要把面向物件的最後一個特性:多型,給說完。不過我們先來聊一聊設計模式,因為它很重要。 設計模式 官方的解釋是,設計模式是:一套被反覆使用,多數人知曉的,經過分類編目,程式碼設計經驗的總結。說人話就是:軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。 常見的設計模式可以

高效能Spark作業基礎必須知道的調優原則及建議

在大資料計算領域,Spark已經成為了越來越流行、越來越受歡迎的計算平臺之一。Spark的功能涵蓋了大資料領域的離線批處理、SQL類處理、流式/實時計算、機器學習、圖計算等各種不同型別的計算操作,應用範圍與前景非常廣泛。在美團點評,已經有很多同學在各種專案中嘗試使用Spark。大多數同學(包括筆者在內),最初

必須知道的React的知識點單向資料流,高效能虛擬DOM,元件間的資料互動,事件與資料的雙向繫結,生命週期鉤子,fetch資料請求等

1、React除錯工具:React Developer Tools 2、React開發工具:Atom 3、React UI庫:Material-UI / Ant Deaign 4、React適用場景:資料不斷變化的大型應用程式 5、前端UI構建方式:資料模型、UI介面

分享必須知道的H5加速器九大常識!

日前,Layabox、Cocos2d-JS、Egret均宣佈即將聯合各大瀏覽器和APP釋出HTML5(簡稱H5)加速器。困擾H5產業的效能問題終於得到階段性解決。在大家紛紛談論H5加速器時,你最好知道以下常識:   Q:什麼是H5加速器?   ​A:用以提高瀏覽器或A

史上最透徹為什麼TTL邏輯驅動CMOS要接上拉電阻?知道

除了前一節討論的拉電阻基本使用方法外,上拉電阻也可以提升高電平的電壓閾值,以便於前後級訊號相匹配, 我們經常會看到網上有這種說法:TTL邏輯電平驅動CMOS邏輯電平時,我們通常會新增一個上拉電阻R1,如下圖所示: 大多數人會這麼想:哦,我知道了,下次如果用TLL邏輯驅動CMOS邏輯的話