5 ms·
This is indeed a beautiful book and especially useful for those who are new to the industry. I have a nit to pick about one of the points listed in the article.
by tapanjk 4y ago
This is indeed a beautiful book and especially useful for those who are new to the industry. I have a nit to pick about one of the points listed in the article...
> Every meeting should create an artifact (ideally, a shared document or at least a record).
I have come across this sentiment often but there is no point in creating new artifacts just to record a meeting. What if the meeting was useless and nothing came out of it? Please do not create a document for this meeting. Such records only create an illusion that you are not leaving out those who could not attend the meeting, but creates mountains of documents or records which would be impossible to navigate in order to draw any conclusion later on.
- leksak 4y agoSounds like labeling, tags, or some token in the filename could be used to distinguish this. The purpose of always creating an artefact is that it'll become habitual and then it is less likely that the meeting that halfway through becomes interesting has meeting notes.
- Sakos 4y agoWhy are you having meetings that are useless? I can't imagine not having a meeting without some resulting document. Even the poorest meetings I've had have resulted in documents changing to reflect the shitshow. edit: I don't think every meeting needs its own document though. If there's a meeting, it needs to be associated with some document(s) in some way which will change as a result. If it isn't, it should be cancelled, imo.
- neilv 4y agoYou can do it in a lightweight way. When you schedule a meeting, you create a wiki page named like "2023-01-02 Fooproj UX Meeting with Marketing", and include the URL in the calendar invite. If there's a written agenda, it goes into the wiki page, in whatever state it's in. If someone is typing notes during the meeting, it goes into the wiki page, in whatever state it's in. Someone might screenshare the wiki page during all or part of the meeting. If there's a meeting video recording or videoconf/calendar SaaS page, the URL gets put in the wiki page. Anything bout that meeting that does get captured somewhere, can be gotten to from that one wiki page, so info not lost. If no info at all ends up being captured around the meeting, then the wiki page might only ever be a title. But even then, it's still something to wikilink to (like `[2023-01-02 Fooproj UX Meeting with Marketing]`), when referring to the meeting, such as citations in design documents and project plans. (Note: This works if you have a policy of "everything goes into the code repo or the wiki". But if you're thinking of the wiki as yet another of countless SaaSes where people are dumping write-only stuff that no one will ever find, then adding to that mess won't seem useful.)
- pydry 4y ago>When you schedule a meeting, you create a wiki page named like "2023-01-02 Fooproj UX Meeting with Marketing" These are the kinds of wiki pages I come across when I'm searching for docs that are actually useful. I dont think anybody reads them.
- neilv 4y agoWhere does the docs/info you need end up being?
- pydry 4y agoUsually in someone's head.
- neilv 4y agoYeah, ideally all that information would be captured, but it never can be. So there's also a role for a wiki to capture information about who to talk to about a particular topic.
- tremon 4y agoIt's one of the first things that I put up on our wiki: a referral list indicating who to ask for questions about which domain. Actually, there's two columns: the first is the operational lead(s), or "who should I ask questions about X"; the second column is the tactical/architecture lead, or "if we disagree on a solution for X, who has the deciding vote?" The latter has avoided countless hours of bikeshedding, or so I'd like to believe.
- 12345hn6789 4y agoNobody reads them, is it because they aren't useful? Maintaining wikis is a culture thing. If most of your employees don't use the wiki it's basically useless since it'll be falling out of date.
- theshrike79 4y ago"Mountains of documents" is not a new problem, you just need to organise them properly. But if you have a meeting and nothing about it was written down, who knows what was decided if it's not written down? 1) Every meeting must have an agenda and any material linked must be read before attending. You're wasting everyone's time by reading the material during the meeting. 2) Every meeting must create an artefact, otherwise you're just chatting with coworkers.
- ThePadawan 4y ago> I have come across this sentiment often but there is no point in creating new artifacts just to record a meeting. What if the meeting was useless and nothing came out of it? I might be a huge cynic, but that seems to me to be the #1 reason to create a post-mortem document to explore how to avoid another meeting that was a waste of time like that. If the meeting was useless because the participants weren't prepared, make a note to hand out preparatory notes beforehand. If the meeting was useless because everybody shouted over each other, make a note for more moderation. If the meeting was useless because no one had political power to follow up on any decisions, cancel the meeting altogether. Having a meeting that goes nowhere and then taking no time to publicly settle on actions as a consequence seems incredibly neglectful to me.
- sys_64738 4y agoEvery meeting should have an agenda. No agenda = cancel meeting.
- marniewebb 4y agoThe artifact we often use is “zoom recording of the meeting.” Which is less than useful. For non-sensitive meetings, we record to otter and then edit the transcript using highlights, marking to dos, etc. We’ve got an otter folder structure that mimics our other folder structures. We most commonly do this for document review meetings (I work for an NGO. We write a lot of grants.) This takes time but it creates good notes, allows everyone to be a participant in the meeting. We have other meetings — like weekly target review meetings — that use Asana as the basis for capturing notes. This works well for things that are really tactical.