團隊中的程式設計師只想寫程式、不想管企業遠景、業務成長錯了嗎?不,錯的可能是主管 你可能團隊中也有這樣的程式設計師,只想一整天能專心地寫程式,不管公司的願景、也不想知道自己的程式與公司的業績有什麼關連。你急著需要一隻程式可以去跟重要客戶交差,但是這位程式設計師卻總是顯得事不關己?

《Habits That Harm Your Technical Team》的作者 Marcus Blankenship 他說:錯不在程式設計師,錯在你們這幫主管。以下為他的文章摘要:

團隊中的程式設計師只想寫程式、不想管企業遠景、業務成長錯了嗎?不,錯的可能是主管

我在面試 Jamie 的時候,他看起來就像一位狂熱的工程師。技術技能可靠,對流程和產品改進有想法,也有著很好的團隊合作態度,是個很明顯的好選擇。

但是,不過2年後,Jamie 就變成了「那個傢伙」。你懂的,就是那個只想不被打擾、埋頭寫自己程式的傢伙。

我本來應該注意到跡象。現在回想起來:他沒有站出來說過話,他沒有像我預期那樣貢獻自己對流程或產品的想法,而他最初在面試時顯示的「團隊友好」型互動,表現出來卻通常是挖苦別人。他經常說我們缺乏創新,而他的評論和反應,都充分顯示出他已經深受「我早就告訴過你了」的情緒之困擾。

結果呢?

結果就是,又一位只想著寫程式的程式設計師被孤立了。

 

環境塑造人

太多主管認為,問題出在Jamie自己的身上:如果他是一位好一點的員工、有奉獻精神的員工,或者至少多一點關心其他人的話,都不會發生這樣的事情,對吧?

不幸的是,不對。

冰凍三尺非一日之寒,熱忱的程式設計師變成偏執的程式設計師不是一夜之間的事情。但是事情的發展速度比你想像的要快。

 

第一次建議非常重要

你如何看待新程式設計師的想法會發出重要信號。不管好壞,這決定了他們會不會在將來分享更多的想法……或者閉嘴不再多管閒事。

當然,這些程式設計師提供的一些想法在你的環境未必可行。有的可能需要「等我們沒那麼忙」的時候再進行討論。有的想法看起來很好,但跟企業環境的潛規則是有衝突的。

不管是什麼理由,鄙視或者貶低你的設計師的想法,尤其是在他們剛來的幾個月內做出這種舉動是糟糕的做法。

滿腔熱情被潑冷水之後,他會試著換種方式表達自己的想法,如果還是好心被當成驢肝肺的話,他就會意識到唯一的取勝之道就是不玩了。

這恰恰是你不希望你的程式設計師吸取的教訓。

他不再提出想法,不再要求跟客戶見面,不想試圖去理解業務。到最後就變成了雙輸的局面。

 

你否定他們的想法,其實是在否定他們「這個人」

記住,你的程式設計師在提出新想法的時候其實是在冒險。想法越大,風險越大。

為什麼是風險?因為我們的想法反映了我們自己、我們的觀點以及我們的熱情。我們不會推動自己不關心或者認為不可行的想法。我們把自己最好的想法貢獻出來,希望能夠被接受。

這需要有暴露脆弱的勇氣,我們只有在相當確定不會受辱的情況才會大膽吐露自己的想法。如果我們認為自己的想法不會被接受的話,就不會再說出去了。

 

你對他們想法的回饋,塑造了他們的行為

如果你否定他們的想法,那麼程式設計師回過頭去,自然會選擇只做能讓自己成功的事情,也就是寫程式,就是很自然的事了。

令人悲哀地,他滿腔的創造、創新和開發熱忱都沒了。

他對市佔率、公司業務的擔憂已經被對頭銜和工資的擔憂所取代。他變得更加關心自己賺了多少,自己的頭銜是什麼,以及自己 LinkedIn 的形象怎麼樣。

他對改變世界的熱情已經被對開發過程的挑剔所替代。

不過更糟糕的是,他對「我們沒有開發正確的東西」的擔心會被「我們沒有把東西開發正確。」的擔心取代。

他已經學會了不對要「開發什麼」提供意見,於是他開始對「怎麼去開發」變得痴迷。

對於他來說,你的文化已經變成了適者生存。

 

如果你不喜歡這樣,就改變自己

如果你不喜歡自己看到的東西,那就去改變它。一個企業文化的塑造,靠的不是命令。而是學習、榜樣以及模仿。

作為主管,值得別人效仿是你的工作。

因為企業文化造成的錯誤,不是 Jamie 的錯。企業文化的錯誤,是團隊主管、軟體經理以及 CTO 的錯。

所以,別再指責 Jamie 了,開始做出你的文化需要的改變吧。越快越好。

 

使用 Facebook 留言

發表回應

謹慎發言,尊重彼此。按此展開留言規則