The linked article is quite helpful. Especially the section about meetings is intriguing. Having a meeting with no set goal initially and all information present is never a good idea. It only leads to a follow-up meeting in the future.
The person who called the meeting is responsible for contextualizing the outcomes and porting relevant snippets to relevant GitLab issues and/or merge requests.
By placing this burden on the meeting organizer, it acts as a filter for whether or not a meeting is truly necessary.
I like this idea, whoever wants to have a meeting is also required actually to make sure the documentation afterward is present. And having a meeting where the outcome is not written down is too bad as nobody remembers its results.
A common frustration in large organizations — regardless of what stage of remote they’re in — is the chaotic splintering of communication. Projects frequently end up strewn across email, chat, text messages, unrecorded meetings, design tools, Google Docs, etc. While there are a litany of unified communication tools available which attempt to wrangle all of that, you’re best served by choosing a single system for communicating project progress.
Yep, all documentation needs to be at a single point. Otherwise, chaos ensues.
No comments received yet.
- Write your comment on your on page and link it to this page with the following link:
- Insert the permalink to your post in the form below
- Submit the form
Alternatively you can reach me by email to: firstname.lastname@example.org