I want to preface this saying that I value the work that the Pooltime team has done and I think we have very high quality and competent community management that has been and will continue to be a vital aid to the growth and reach of PoolTogether. I also am excited to see @poptones added to the team to amplify PoolTogether’s voice in socials and partnerships.
I think the endeavors of the team align with the need for growth and community safety at this time; however, I have some reservations relating to the overlap of community management and development of the Pooltime application. Although the close relationship has been expressed as helpful and efficient, the goals and deliverables do not significantly overlap between the two. Although I value both the app and the community management, I would much rather see two teams (Pooltime Team and Community Team) with two separate PTBRs to clearly distinguish the deliverables and cost of both.
@Tjark 's has expressed the following with regards to having a community team:
Being alone on a “community team” feels like a meme
I understand this does not feel right (even though @Tjark often does the work of an entire team by himself). However, it’s my understanding that if the community team were separate from Pooltime, @poptones would be part of this team, right? This uncertainty shows the confusion of roles that is happening on the Pooltime team and lack of clarity for where the resources are going. Is Darby being brought on for socials, community building, and community partnerships or is she being brought on for Pooltime integration partnerships and application marketing? If the answer is both, I still believe the community team is a better fit and that the two teams can collaborate when there is overlap.
Separation of user applications and protocol growth is a positive tactic that will leave room for the development of more user experiences in the future from 3rd parties looking to build on top of PoolTogether. If we intertwine our protocol’s voice with the voice of one application, we suffer the consequences of solidifying our product as an app instead of a protocol.