本文是從 How to manage your Programmers 這篇文章翻譯而來。

　　以一個組織的形式完成項目、任務或實現某些目標，這被稱作公司，這需要有完善的信息流轉機制和長期的規劃。過程管理在這種組織里是一個非常復雜的問題。這就是為什么這些年會出現了大量的諸如Scrum,
Kaizen, Kanban等技術和方法論來盡可能簡化這個過程。簡言之，這些東西都是用來最有效的發掘你的員工的全部潛能的。

你有了一個領導

　　基于此，我們通常會有一個重要人物，他可能是一個領導，一個經理或一個總監，等等。這就有了問題：這些人有什么樣的特征？一個管理者和一個程序員之間的不同之處在什么地方？他們的角色可以互換嗎？

　　為了弄明白這個問題，我們需要從人的視角上去思考。換種方式來說，我需要用到人的因素這個詞。

如果他錯了呢？

　　首先，要想管理人，你需要去理解他們。要做到這些，我們需要有情商。這并不僅僅指只針對我們這部分人。我們做的任何事情中都存在情感，你要從個人角度去體驗它，要熟練掌握，在我們的公司管理中的合作方式上不能忘記這一點。管理并不僅僅指控制和命令，它還包括聆聽，理解，溝通和對復雜的情緒上的問題給出有效的方案，這都是至關重要的。

弄清他們的感受

　　很多人都忽略了管理工作中的這方面問題。有時候會很戲劇化，類似于這樣：“鮑勃，從明天開始你就是一名項目經理了，因為我們的程序員太多了，需要去管理，但不用擔心，你就要去上一個Scrum大師班了”。我們都知道這樣的認證證書是什么樣的，有什么價值。這跟那個10天的ICC培訓課程后成為一名教練的故事非常的相似——這行不通，你要銘記！

　　另一方面，Mark Foster在他的標題為《How to make your dreams come true(如何實現你的夢想)》一書中談到，實現目標有兩種方式：推(Push mode)和拉(Pull mode)。前者是使用一種工藝上的技術來完成一項任務，比如程序員編程，而后者依賴于經驗、直覺和情商，從而選擇最好的方式解決一個問題——這是管理者的視角。當使用這種管理模式時，管理者是不能和程序員進行角色互換的，反之亦然。一些大公司通常使用這種管理模式。而這種方式有時會損失一些員工的潛能，因為在多個級別的管理職位中產生的太復雜的層級關系。

相互協作

　　為什么？很多的小公司都使用敏捷方法論。這是一種基于合作的方法論。上面描述的模式并不能滿足他們的需求。在不同層級上的管理者和程序員之間始終存在著一個隔膜。人們會被分成“腦力勞動者”和“體力勞動者”。結果就是導致我們失去那些同樣有大腦卻從來未被使用的人。如今，所謂使用有效率的員工就意味著把所有人都當作腦力勞動者。

　　Evan Rose 說：

命令/控制(Command-and-control)文化使人們把公司成員分成了腦力勞動者和非腦力勞動者。他們讓腦力勞動者去思考，讓其他人去執行命令。這種文化中，合作沒有基礎。更重要的，信息的流轉應該是多向性的，而不是瀑布式的從高層經過多個管理層流到一線員工。事實上，如今的每個人都有資格成為一個腦力勞動者

　　現在出現了一種稱作自我管理的形式，這種形式本是我們這個世界的基礎。如果我們本來是自我管理的，為什么不更進一步呢？也許我們根本不需要管理者。37Signals 和 DHH都實現了這樣的思想，描述起來如下：

我們同樣也讓我們的團隊管理自己。每周，一個員工會站出來當管理者，他制定簡單的日程計劃，審查其他人的工作，更新公司動態信息，他對于其他同事來說是一個關鍵人物。這種職務輪換每周一次。你知道我們發現了什么嗎？當每個人都知道自己要當一周的國王時，神奇的事情發生了。對管理者強迫自己做某些事情的抱怨消失了，因為職務的輪換讓他們有機會同時清楚的了解了圍欄兩邊的景觀。如果你讓員工們這樣做，這給了他們提高和成長的機會。

找到共識，一起努力

　　但不要想當然。這并不是適用于任何地方任何人。但就像David說的：這種方法可行性很大。如果你能理解這點，你可以在團隊或部門里試驗一下。通常在小公司里當某方面出現問題時你能相當很快的對其作出反應，這能讓你更容易的避免重大事故的發生。

　　簡言之，不管你的管理方式是什么樣的，永遠要記住，在公司組織結構的深處有一種叫“人的因素”的東西，它在等待著你去照顧，它能摧毀你所有美麗的計劃。唯一你防止這種災難發生的辦法就是要認識到：你在跟人打交道，不是機器。