SushiSwap前CTO:作為SushiSwap領導者的失敗


近日,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 不再參加我們的日常技術同步,讓其他前端開發人員爭先恐後地處理要完成的任務。有了下線的威脅,我們本可以保持團隊溝通,提高開發效率。

2.節奏

其次,我沒有與社區進行足夠的溝通,因此當遇到需要與他們交談的問題時,我不再願意參與其中。因此,事後看來,我會更頻繁地與社區交談以增加我們的關係。

3)公共關係

作為在以太坊社區工作了4 年的人,我利用我的個人推特來發送有關Sushi 的消息。這最終是一個錯誤,因為我應該通過官方渠道轉移。

此外,我在成為公眾人物之前在推特上的行為已經發生了很大變化,我無法適應新的溝通方式。我認為對我認為DAO 的運作方式保持真實的感受是可以的,這是一個錯誤的假設。

我應該看看我尊重的人,比如Sam Bankman-Fried 或Joe Lubin,我以前認識他們,他們經營著自己的Twitter,但顯然已經將他們的公關交給了代理機構或助理。在我的下一個項目中,我將利用公共關係專業人員來推動溝通。

結論

最後,由於我的多方面失敗,我最終未能履行職責。我將把此知識納入我的下一個項目。我認為Sushi 的不完美誕生導致了額外的問題,在我的下一個項目中,我將有能力構建一個組織來授權貢獻者。感謝你們讓我帶領Sushi 度過這段時光,並祝Sushi 好運。 Sushi 萬歲。

資訊來源:由0x資訊採集自互聯網。版權歸作者“區塊律動BlockBeats”所有,未經許可,不得轉載

Total
0
Shares
Related Posts