SushiSwap前CTO：作爲SushiSwap領導者的失敗

閱讀本文需 7 分鐘

SushiSwap前CTO Joseph Delong發文總結了自己在領導Sushi期間犯下的錯誤，對自己的行爲表示抱歉，並給予Sushi祝福。

原文標題：《My Failures in Leadership at Sushi》

原文作者： Joseph Delong

原文編譯：谷昱，鏈捕手 ChainCatcher

近日，SushiSwap 內訌事件引起加密社區的廣泛關注，SushiSwap CTO Joseph Delong 最終選擇離職來平復社區的不滿情緒。今日凌晨，Joseph Delong 在去中心化內容發佈平臺 Mirror 上發文詳細回顧了自己在 SushiSwap 的團隊歷程，並反思導致種種問題的具體原因。

以下爲原文

加入新團隊成員後未能擴展計劃

在新團隊成員入職後，對組織、路線圖和規劃的需求增加了。一個 5 到 7 人的稱職團隊完全有自我協調的能力。因此，當我將團隊規模擴大到超過這個數字時，對協調的需求顯着增加，而且我未能爲團隊配備成功所需的工具和計劃。瞭解問題後，我們將開發團隊同步的頻率增加到每天發生。

當我在 USAA 工作時，我在兩個獨立的團隊中工作，這些團隊擁有非常能幹的 SCRUM（注：用於開發、交付和持續支持複雜產品的一個框架）大師，回想起來，這使開發過程變得順暢且不那麼混亂。在我的下一個項目中，最初的 5 名員工之一將是一名高素質的 SCRUM 大師。

此外，作爲一個討厭管理開銷的人，我陷入了試圖人爲地保持低位開銷的陷阱，這最終對團隊不利。當團隊增加到 12 人時，如果沒有集中的項目管理或衝刺計劃，就會開始出現重大故障。當我未能成爲一名有效的策劃者時，Rachel Chu 接替了這個角色。

根據技能而不是產品線組織團隊

開發團隊是根據開發人員的技能組合組織的，即：前端、Solidity、devops。Sushi 採取了一個團隊方法，在我看來這是 DAO 的完美模型。

然而，由於團隊專注於他們的技能組合而不是產品線，因此降低了團隊專注於多個產品線的能力。在我的下一個項目中，團隊將被產品線分開，幾乎沒有交叉。

沒有儘快讓有問題的貢獻者離開

早些時候，當 Maki 讓我加入該項目時，BoringCrypto、Keno 和 LevX 之間已經發生了內訌，回想起來，這種緊張局勢最終導致了後來的主要內訌。我認爲將兩個交戰方分開並根據性能改進計劃對 LevX 進行代碼審查就足以平息內鬥。

如果我不得不重來一次，我會更早地讓 LevX 離開並隔離 Keno 和 BoringCrypto。雖然該項目還處於早期階段，並且 Maki 接替了 CEO，但在他的批准下，我能夠將有問題的貢獻者排除在外。

然而，在他離開後，無論出於何種原因，我都失去了對有問題的貢獻者進行離場的權力。這帶來了我的下一點，也是我作爲領導者迄今爲止最大的失敗：溝通。

溝通

1）直言不諱

溝通是我失敗的關鍵因素。當我失去了外部開發人員的能力時，我應該聯繫 Sushi 社區告訴他們。如果沒有能力將有問題的開發人員排除在外，就不可能管理一個開發團隊。例如，Matthew Lilley 不再參加我們的日常技術同步，讓其他前端開發人員爭先恐後地處理要完成的任務。有了下線的威脅，我們本可以保持團隊溝通，提高開發效率。