以一個組織的形式完成專案、任務或實現某些目標，這被稱作公司，這需要有完善的資訊流轉機制和長期的規劃。過程管理在這種組織裡是一個非常複雜的問題。這就是為什麼這些年會出現了大量的諸如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說的：這種方法可行性很大。如果你能理解這點，你可以在團隊或部門裡試驗一下。通常在小公司裡當某方面出現問題時你能相當很快的對其作出反應，這能讓你更容易的避免重大事故的發生。
簡言之，不管你的管理方式是什麼樣的，永遠要記住，在公司組織結構的深處有一種叫“人的因素”的東西，它在等待著你去照顧，它能摧毀你所有美麗的計劃。唯一你防止這種災難發生的辦法就是要認識到：你在跟人打交道，不是機器。
原文：Michał Wyrobek 譯文：外刊IT評論