Sushiswap's former CTO reflects: Why did my leadership at Sushi lead to failure?
Source: Joseph Delong's Twitter
Compiled by: Gu Yu, Chain Catcher
Recently, the internal strife at Sushiswap has attracted widespread attention from the crypto community. Sushiswap CTO Joseph Delong ultimately chose to resign to calm the community's dissatisfaction. Early this morning, Joseph Delong posted on Twitter to reflect on his journey with the Sushiswap team and to analyze the specific reasons behind various issues. Below is the compilation by Chain Catcher:
Failure to Scale Plans After Adding New Team Members
After new team members joined, the demand for organization, roadmaps, and planning increased. A competent team of 5 to 7 people can fully self-coordinate. Therefore, when I expanded the team size beyond this number, the need for coordination increased significantly, and I failed to equip the team with the tools and plans necessary for success. Upon realizing the issue, we increased the frequency of synchronization for the development team to daily.
When I worked at USAA, I was part of two independent teams that had very capable SCRUM masters, which, in hindsight, made the development process smoother and less chaotic. In my next project, one of the initial 5 employees will be a highly qualified SCRUM master.
Additionally, as someone who dislikes management overhead, I fell into the trap of trying to artificially maintain low overhead, which ultimately harmed the team. When the team grew to 12 people, significant failures began to occur without centralized project management or sprint planning. When I failed to be an effective planner, Rachel Chu took over that role.
Organizing Teams Based on Skills Rather Than Product Lines
The development team was organized based on the skill sets of the developers, namely: frontend, Solidity, devops. Sushi adopted a team approach, which I believe is a perfect model for a DAO.
However, because the team focused on their skill sets rather than product lines, it reduced the team's ability to concentrate on multiple product lines. In my next project, the team will be separated by product lines with minimal overlap.
Not Quickly Removing Problematic Contributors
Earlier, when Maki brought me onto the project, there had already been internal strife between BoringCrypto, Keno, and LevX. In hindsight, this tension ultimately led to the major internal conflict that followed. I believed that separating the two warring parties and conducting a code review of LevX based on performance improvement plans would be sufficient to quell the infighting.
If I had to do it all over again, I would have removed LevX earlier and isolated Keno and BoringCrypto. Although the project was still in its early stages and Maki had taken over as CEO, I was able to exclude problematic contributors with his approval.
However, after he left, for whatever reason, I lost the authority to remove problematic contributors. This brings me to my next point, which is my biggest failure as a leader so far: communication.
Communication
1) Being Direct
Communication was a key factor in my failure. When I lost the ability to engage external developers, I should have reached out to the Sushi community to inform them. It is impossible to manage a development team without the ability to exclude problematic developers. For example, Matthew Lilley stopped participating in our daily technical syncs, causing other frontend developers to scramble to handle tasks that needed to be completed. With the threat of going offline, we could have maintained team communication and improved development efficiency.
2) Rhythm
Secondly, I did not communicate enough with the community, so when issues arose that required discussion with them, I was no longer willing to engage. In hindsight, I would have spoken with the community more frequently to strengthen our relationship.
3) Public Relations
As someone who has worked in the Ethereum community for 4 years, I used my personal Twitter to send messages about Sushi. This ultimately was a mistake, as I should have communicated through official channels.
Moreover, my behavior on Twitter has changed significantly since becoming a public figure, and I struggled to adapt to the new communication style. I assumed it was acceptable to maintain my genuine feelings about how I believed a DAO should operate, which was a flawed assumption.
I should have looked at people I respect, like Sam Bankman-Fried or Joe Lubin, whom I knew previously, who manage their own Twitter but have clearly delegated their public relations to agencies or assistants. In my next project, I will utilize public relations professionals to drive communication.
Conclusion
Ultimately, due to my multifaceted failures, I failed to fulfill my responsibilities. I will incorporate this knowledge into my next project. I believe that the imperfections of Sushi led to additional issues, and in my next project, I will have the capability to build an organization that empowers contributors. Thank you for allowing me to lead Sushi through this time, and I wish Sushi good luck. Long live Sushi.