Be Prepared for Meetings

The concept seems like a no-brainer, and maybe it is just my personal experience, but anytime a poll of the meeting attendees is run asking if they reviewed the material sent prior to the meeting, the overwhelming majority response is “no”.

I was reminded of the importance of being prepared while listening to an episode of one my favorite podcasts, “Think Fast, Talk Smart” (please see my YouTube channel for a link to the podcast playlist and subscribe to my channel while you are there so I can finally get a vanity URL). The episode was titled Communicating Our Mistakes: How to Avoid Common Flaws and Make Better Decisions, which I admit was not one of my favorite episodes, but it did spend some time on this topic of preparation, which triggered a confirmation bias response from me. It started with a learning approach where the teacher asked students to complete the lessons before the lecture so that lecture time was spent building on top of that, then moved on to how meetings are more effective if people review the material in advance and discuss in the meeting…

[sounds of wood scraping across the floor as the author pulls his soap box out]

There are corporate cultures where materials are not provided in advance, probably because of the tendency for people not to review them. This makes the problem worse. These same cultures also frequently have meetings schedule with no agenda. I had someone on one of my teams who refused to attend meetings without an agenda. It was difficult for me to fault him, as I agreed with his reasoning.

People hate meetings because they are often inefficient and inclusive. My approach is to go the opposite direction of those who stop sending the material in advance and including agendas: I avoid reviewing the material in the meeting and instead advise those who didn’t to take notes and review it after the meeting. Depending on the purpose of the meeting, I may just reschedule it and advise everyone to come to the next meeting prepared. This may seem anti-[your pet sentiment here], but my experience has been that people become much more productive when they come prepared as a result of the meeting being more productive and few meetings because things were accomplished¬† the first time.

[author returns his soap box to easily-accessible storage location]

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Things to Determine before Projects Begin

This post is a perpetual Work-in-Progress. As of now, it is only starting (stalling would be more accurate, I’ve been playing with it in various forms for over a year now).

Here’s what we have so far (please add your additions in the comments):

Project Type Artifact
All Release schedule
All Release process
All Coding standards
All Other StakeHolders that may be impacted
All Where and how architecture decisions are logged
Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Keep Emails to a Single Topic

Many people could write entire books on email tips. I think the best I could do would be a pamphlet, and the single topic “rule” would have one of those click-bait sub-headings like “if you only learn one thing about writing emails, this is it”, at least as far as value and productivity go.

Before proceeding, a general comment (rant) about rules: Rules are not laws. Laws (at least physical ones) are absolutes. Do this, that will happen. Rules (outside of software) are suggestions based on experience that have proven useful. They are not always true, but they are more often than not and are therefore good guidance when no other factors indicate otherwise.

So, I will start off by violating the rule (to a degree) in describing the rule as having more than one part. The first part of the rule is simple, which is that subject of an email should be focused on a single topic, and the body of the email should not stray beyond that. One reason for this is clarity. If the topic changes within the body of the email, readers may become confused. Confused? Really? Yes. The process is not all that different from The Telephone Game, except that the readers’ attention is all of the players, and everytime there is a distraction it is the same as one person telling the next. Sometimes it will come out as it went in, and other times it will vary, and if it happens enough times the original may not resemble the end. This is especially true for people who have to read many emails throughout the day (or all at once, if you are following some YouTube videos on productivity) read them very quickly, and the topic change may lead them to forget the original purpose of the email (like you may have forgot where this sentence was going with these parenthetical comments of mine that are a habit I may change one day).

Changing subjects in an email can become even more problematic in the event that the email becomes a thread, because the subject in the full inbox will not match the topic in the email and may not be prioritized properly. The other problem with content not matching the subject is when trying to locate the email later. Yes, a diligent search will find it, but how often have you been searching for something only to be distracted when it isn’t found right away and never coming back to it?

The second thing about keeping to a single topic is that many people will treat an inbox as a, well, an in-box. Meaning once the subject matter has been concluded, any further emails will be either given a low priority or ignored entirely as “complete”.¬† And, the distraction phenomenon appears again for the people that live under a perpetual email avalanche, this time when there are multiple action items in the email for a single recipient. Often they will complete one item and consider it “done”, leaving the other items forgotten (frequently because an IM, text, or person distracted them before finishing the message). Email senders not aware of this phenomenon will sometimes wait for the rest of the response in vain. Worse, they may take the lack of a complete response as a personal affront rather than a result of too much information and too little time.

If you only remember one thing from this rambling message, it should be to remember to stick to only one thing in your messages for best results.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Provide Document Feedback for Efficiency

When providing document reviews with comments or track changes, most people start writing their comments as they read through. This is perfectly natural and recommended, as capturing your thoughts immediately is the best way to ensure they aren’t forgotten. That said…

As you read through the document, some of your comments made earlier may be addressed later in the document. If you think the content should be moved, this is a good time to point that out, referring back to your earlier comment. If not, take the time to move the comment to the appropriate point, or revise it accordingly.

Short-term memory varies between person to person and even context to context. A comment provide early in the doc is likely to be remembered and reference back when it discovered at the end that it was not necessary if the review is done in a single sitting or as part of a very focused project. Then again, someone stopping by to say “hi” or an IM popping up immediately after writing a comment can pop the memory out of the short term queue and only invoke vague familiarity if the concept is addressed later. Because of this unplanned and unschedulable variation in memory reliability, I suggest re-reading through all comments prior to submitting them. It will (hopefully) catch those forgotten inputs that should be revised in the context of the entire document so that the sent input is concise.

The value of concise input is two fold: It makes it easier for the person receiving the feedback to apply it where needed, and it avoids the frustration of seeing comments from a review that the author knows are not valid because they are addressed later on.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Replace Auto Dates in Templates

Many templates include a date that is based on the current date. In the good ole days, when a designated file type for a template was used and the file was saved as a standard file, that date would stop updating automatically.

These days, most templates are just a previous file where the original content was stripped and labelled as a template, and even those that are specified as template types still keep the date updating after saving to a file. This makes the date of the content unknown, the opposite of the value of including a date.

For the sake of those who want to keep content in context, please develop the habit of replacing the auto-date with the actual date when publishing documents.

In some templates, fixing the date is hard to do, especially if someone has locked aspects of template with good intentions (and annoying consequences). In that case, overlay text on top of it with the correct date with the background fill blocking out the auto date.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson