Workflow Principles

QuoteComment
>> We recommend a weekly flow like this to get your work done and stay roughly in sync with everyone else (though to be clear, we require zero synchronous communication).
It is always good to split and plan the work in chunks. Periodic check-ins ensure everybody is on the same page and all the critical blockers are raised and resolved in time. One week is an optimal period for slowly moving products.
>> Do all work that is blocking other folks.
This is a critical part. Even the smallest blocker can delay a feature release by days. During one of my projects, the new team member didn't know the login credentials. It took more than 2 days for him to reach out to the team and access the system. Everyone was busy fixing bugs on production.
>> If you're running out of work, move some tasks from Notion to GitHub
I assume that GitHub is used for day-to-day task management and has a backlog of tasks for the nearest few days. And Notion is for high-level feature planning and contains the roadmap with most of the user stories. It is a good solution.
>> Try to tackle 1 technical debt issue a week
I assume the "technical debt" is one of the important types of issues that have to be resolved regularly. It is a good practice to have explicit categorization like this
>> Look at issues marked priority on GitHub
Although understanding high-level prioritization is important, knowing what to focus on day-to-day is vital as well. Having certain prioritization labels for GitHub tickets is a must
>> Address any outstanding questions in #support in Slack
I assume that everyone from the product team has access to the customer support channel. That's a good practice and helps the team become closer to the users — know what the common issues are, what kind of questions are asked, etc.
>> Provide a weekly update in #updates-log in Slack
It is good to keep all the updates in the same place so that the team members can efficiently discuss them
>> Resume ongoing work!
One of the mistakes of amateur development teams is to switch the focus too rapidly. Whenever a new request arrives from the product owner, sometimes the team switches their attention to it — leaving work-in-progress abandoned. It is inefficient as it takes a lot of time to recover the stuff left behind.
>> We don't have teams. Everyone works on individual projects. If an idea requires a "team," it is broken down into at least two projects (e.g. design, front-end, back-end).
It is an interesting idea. However, for it to work nicely, team members should have a complementary set of skills that would allow them to work effectively as individuals.