你可能團隊中也有這樣的程式設計師，只想一整天能專心地寫程式，不管公司的願景、也不想知道自己的程式與公司的業績有什麼關連。你急著需要一隻程式可以去跟重要客戶交差，但是這位程式設計師卻總是顯得事不關己？
《Habits That Harm Your Technical Team》的作者 Marcus Blankenship 他說：錯不在程式設計師，錯在你們這幫主管。以下為他的文章摘要：
我在面試 Jamie 的時候，他看起來就像一位狂熱的工程師。技術技能可靠，對流程和產品改進有想法，也有著很好的團隊合作態度，是個很明顯的好選擇。
但是，不過2年後，Jamie 就變成了「那個傢伙」。你懂的，就是那個只想不被打擾、埋頭寫自己程式的傢伙。
我本來應該注意到跡象。現在回想起來：他沒有站出來說過話，他沒有像我預期那樣貢獻自己對流程或產品的想法，而他最初在面試時顯示的「團隊友好」型互動，表現出來卻通常是挖苦別人。他經常說我們缺乏創新，而他的評論和反應，都充分顯示出他已經深受「我早就告訴過你了」的情緒之困擾。
結果呢？
結果就是，又一位只想著寫程式的程式設計師被孤立了。
環境塑造人
太多主管認為，問題出在Jamie自己的身上：如果他是一位好一點的員工、有奉獻精神的員工，或者至少多一點關心其他人的話，都不會發生這樣的事情，對吧？
不幸的是，不對。
冰凍三尺非一日之寒，熱忱的程式設計師變成偏執的程式設計師不是一夜之間的事情。但是事情的發展速度比你想像的要快。
第一次建議非常重要
你如何看待新程式設計師的想法會發出重要信號。不管好壞，這決定了他們會不會在將來分享更多的想法……或者閉嘴不再多管閒事。
當然，這些程式設計師提供的一些想法在你的環境未必可行。有的可能需要「等我們沒那麼忙」的時候再進行討論。有的想法看起來很好，但跟企業環境的潛規則是有衝突的。
不管是什麼理由，鄙視或者貶低你的設計師的想法，尤其是在他們剛來的幾個月內做出這種舉動是糟糕的做法。
滿腔熱情被潑冷水之後，他會試著換種方式表達自己的想法，如果還是好心被當成驢肝肺的話，他就會意識到唯一的取勝之道就是不玩了。
這恰恰是你不希望你的程式設計師吸取的教訓。
他不再提出想法，不再要求跟客戶見面，不想試圖去理解業務。到最後就變成了雙輸的局面。
你否定他們的想法，其實是在否定他們「這個人」
記住，你的程式設計師在提出新想法的時候其實是在冒險。想法越大，風險越大。
為什麼是風險？因為我們的想法反映了我們自己、我們的觀點以及我們的熱情。我們不會推動自己不關心或者認為不可行的想法。我們把自己最好的想法貢獻出來，希望能夠被接受。
這需要有暴露脆弱的勇氣，我們只有在相當確定不會受辱的情況才會大膽吐露自己的想法。如果我們認為自己的想法不會被接受的話，就不會再說出去了。
你對他們想法的回饋，塑造了他們的行為
如果你否定他們的想法，那麼程式設計師回過頭去，自然會選擇只做能讓自己成功的事情，也就是寫程式，就是很自然的事了。
令人悲哀地，他滿腔的創造、創新和開發熱忱都沒了。
他對市佔率、公司業務的擔憂已經被對頭銜和工資的擔憂所取代。他變得更加關心自己賺了多少，自己的頭銜是什麼，以及自己 LinkedIn 的形象怎麼樣。
他對改變世界的熱情已經被對開發過程的挑剔所替代。
不過更糟糕的是，他對「我們沒有開發正確的東西」的擔心會被「我們沒有把東西開發正確。」的擔心取代。
他已經學會了不對要「開發什麼」提供意見，於是他開始對「怎麼去開發」變得痴迷。
對於他來說，你的文化已經變成了適者生存。
如果你不喜歡這樣，就改變自己
如果你不喜歡自己看到的東西，那就去改變它。一個企業文化的塑造，靠的不是命令。而是學習、榜樣以及模仿。
作為主管，值得別人效仿是你的工作。
因為企業文化造成的錯誤，不是 Jamie 的錯。企業文化的錯誤，是團隊主管、軟體經理以及 CTO 的錯。
所以，別再指責 Jamie 了，開始做出你的文化需要的改變吧。越快越好。
有錯一定不是他的錯