2020-09-19 - meeting on the horizon!

have you ever been on a meeting at work, and realized that it would be better for everyone if you read a good sci-fi book for that 1h? you'd be fresh-minded and relaxed to solve problems, while after a bullshit meeting you're mentally tired and there was no added value due to it at the end.

setting up a well organized meeting is not a rocket science. it turns out however it is not an obvious thing, either – statistically speaking, at least. different organizations have different culture around it, too. i recall at least once working in an environment, where meetings invitations were flying like crazy: no agenda, 25 ppl invited, and a vogue topic like “discuss last issue in test lab”. over time ppl stopped even looking at the invitation content. very non productive. so how to make things better?

bladder jokes aside, when you organize a meeting, there are a couple of things to remember:

1. meeting must have a purpose (“let's meet and talk” does not count, unless it's one in the evening, over a beer).
2. twice the number of ppl, 1/4 the chance of coming to any conclusion (keep in mind that often “a decision” promptly is better than “the decision” too late).
3. make sure ppl know what shall be prepared upfront.

when i setup a meeting, i try to follow this pattern:

1. define the problem to be solved. eg.: is architecture A preferred over B, for the project?.
2. define expected outcome of the meeting. eg.: selection of 1 of 2 proposed architectures.
3. invite only the key ppl for the topic. the most productive meetings are with around 3-5 ppl. put down why certain ppl are required. eg.: John as system SW architect (can approve), Jack as HW architect (can suggest things that match best provided HW capabilities), Jane as algorithms expert (will we be good with a given setup, performance-wise?), George as subject matter expert (is given setup doable in a first place?).
4. put down meeting agenda.
5. define who shall prepare what. eg. John – existing system overview, Jack – key HW dependencies, Jane – possible algorithms for both A and B solutions, George – domain constraints.
6. provide all required materials, so that participants can prepare. eg.: architecture drafts for A and B solutions.
7. keep it short. both meeting and invitation. stay up to the point and make it fast & easy to read.

when meeting starts, make sure you moderate it so that it does not go off-topic.

i've know that some ppl just reject any invitations that does not meet these expectations. i'm not that hardcore, though i'm far more likely to accept the meeting, that have above plan. “let's meet and talk” is a waste of everyone's time, and typically a total boredom.