很多人都知道軟體專案最難解決的是人的問題，但對超理智型管理者來說，人的問題不算什麼。實際上，超理智者經常視人而不見，因此根本不認為他們需要解決人的問題。就像某位長官一心想改變架構，卻拒絕承認架構變動會造成風險升高的衝擊，明顯的駝鳥心態；以為把頭埋在沙堆裡，看不到人，就沒有人的問題。
故事是這樣開始的，最近長官找 SA 及同人討論系統架構如何因應某項作業不同的需求。因為該項作業會新增額外的申請人，和其它作業最多只會有兩位申請人，亦即在進入交易前使用者輸入的申請人。
現有設計架構是兩位申請人和交易資料放在同一個資料表，如果要容納兩位以上的申請人，似乎應該把申請人資料抽出成為另一個資料表，然後建立交易資料和它之間的一對多關係，這樣就可以讓一個交易容納多個申請人資料。
但考慮到對現有功能的衝擊，這樣大幅改變架構恐怕不是明智之舉，因為原來做好的功能都需要重改和重測，但它們本來就沒壞為什麼要改動它？只因為一個作業需要增加當事人，我認為有比較務實且風險較低的架構調整對治之道。
同人的方法是存放申請人資料的架構不變，但對於特定作業需要增加申請人的需求，另外設計一個額外的申請人資料表。然後設計共用業務元件來提供新增申請人以及顯示所有申請人的功能。這樣就不用改動到原來已寫好的元件與作業功能，所以也沒有需要重新測試的問題。只要針對增加的功能開發元件和作業處理即可。
然而長官卻認為同人的構想是疊床架屋，卻堅持要改動資料結構與元件。我表示這會讓團隊陷於高風險，讓五月到六月花兩個月測試及除錯使元件穩定的過程重頭再跑一次，我主張已經穩定的元件不應該輕言改變，除非發現錯誤。
豈知長官反駁我的意見，說原來的元件需要加入新功能，質疑怎麼說可能不修改既有元件；既然元件會被修改，那翻修架構自然不應該會提高風險。這簡直是強辭奪理，長官說元件需要增加功能的部分，程式早就開發完成了，只是業務情境尚未演練，還沒有經過整合測試驗證。以後就算整合測試後發現程式需要除錯和修正，也不大可能會變動架構。因為系統架構是針對納入這些功能而設計的，因此已經開發完成功能的除錯和修正不會改變架構，怎麼能和元件架構翻修造成的衝擊相提並論呢？
不過，同人意識到討論已經失焦變成意氣之爭，我已經不想再跟長官爭執下去了。於是用平靜的語調表示再討論下去也不會有結果，我已經清楚表達我的想法，我不想爭執對與錯，就讓彼此冷靜下來再好好想清楚該怎麼做。後來同人在長官與其他 SA 討論其它問題時默默離開了會議室，據聞我離開之後長官很激動，但最後還是接受 SA 們的決議採用我的作法。
同人主張的解決方案並不是疊床架屋，相反地，長官堅持改變資料表結構來因應少部分的特殊需求，卻是在架構上自廢武功的行為。為什麼長官寧願自廢武功也不願意面對現實採用靈活彈性的設計策略呢？這固然是期待設計必須滿足情感上的需要，而使他沒有面對現實。但為什麼他不能意識到自己應該面對現實，而認為變更架構不會對專案帶來什麼大問題？同人發現他原來是個超理智型的管理者，人在他的世界中根本就不存在，因此也就不會有人的問題。
同人提到原先開發元件的人將要離職，如果在這個時候變動架構，會造成接手的開發者無法順利維護元件的風險。長官卻質疑如果發現元件出錯，接手的開發者能夠不去修正它，難道他可以說：「我不敢改程式」嗎？同人反駁長官顛倒了因果關係，管理者有責任不該讓團隊處在高風險的情況下，只為滿足個人對設計偏好而不是面對現實。長官說專案由他負全責，同人則是質疑到時候開發者功能做不出來，他如何負責，難道是是把責任全部推給開發者，責怪他們能力不足？
從長官以上的反應，同人清楚看到超理智型管理者是如何不面對現實，用理性來當做自尊低落的屏障。在表相虛幻理性的背後，同人發現長官的道理不是根據事實，而是根據信仰；但他的信仰可不容許被人戳破，當你明白指出「人的問題」的時候，他只會告訴你，現在這裡沒有任何人，所以人的問題根本並不存在。看到這樣清楚地表演超理智型管理者言行不一致的情況，與其爭辯還不如見不賢而思自省；對於看不到外面的世界的真相，只住在自己想法洞穴的人而言，無知讓他意識不到自己必須面對現實。
