There should be books written on this topic. Many, and all with fewer than four paragraphs or no one will finish them.
Manage email subjects
Whenever someone is compelled to label something as “common sense”, everyone agrees even though it is clear that it is not all that common because it had to be called out. That can apply to just about anything I have to say about email. So here are a few common sense concepts about email:
Keep the email to a single topic
While some people are good at making context shifts in a conversation, there are many people who find switching topics difficult. In verbal communication a missed context switch will often result in a response being framed in the previous context. The same can happen in emails, or (worse) the new context is simply ignored. Why is it worse when ignored? Because when a subsequent email requests a response to the ignored/skipped topic, the recipient will either again miss it or reply that they have already responded. This is neither obstinance nor resistance; it is how their brain perceives it. Keeping to a single topic may initially seem inefficient (and it is if you know for a fact the recipient is good at context management) yet it is far more efficient to write three emails and get a congruent response to each than to write one email followed by a chain of a dozen follow ups that may or may not conclude in everything being answered.
When the thread changes topic, change the subject.
Even congruent email chains can move from one topic to another. If you are the one writing the email with a topic change, change the subject in the email, even if you do retain the earlier thread as a related reference. If someone else changes the topic, update the subject in your reply with [New Subject] (was re:[Old Subject]. When you go to search your email for a thread several weeks later, you will be glad you did.
Trim to fit
When replying to an email where many people are on the thread, remove the list of recipients from the original email, especially when updates are inline (another bad practice).
Our wiki is our guide. We support our wiki through comments and additions.
Without updates, our wiki will become outdated. Team members will become frustrated when information is missing or no longer correct. Being a good team member includes being a contributor to the wiki.
That cool reference you found that you will always remember? One day, when you need it most, you will forget it.
That awesome solution to a code or design issue that is perfectly clear and understandable now will look like a foreign language in 2 years (months, weeks, sometimes even hours). Add an explanation to the wiki.
When in doubt if something should be added to the wiki, add it. It can always be deleted later.
This is your wiki. Keep it clean but not too lean.
(Disclaimer: this article is not about what Agile is, the term is used only for blatant marketing purposes. Some principles were violated in the writing of this post)
A colleague of mine recently said something to the effect of “the goal of agile is faster delivery”. This is a common misconception fostered by the improved velocity that agile teams can achieve in the context of enhancing software with new or improved features. The goal of agile is higher quality software, where quality is defined as meeting the intended functionality in a reliable manner. (lots of paraphrasing there, so please don’t flame me about accuracy). Another root of this misconception is that people who do not participate in agile projects (sometimes referred to as chickens) want agile to be about time-to-market (I’m working on a longer rant on that topic alone). Just like some people want agile to eliminate the need for planning and documentation, not be because these things are not critical (apologies for the double negative), but because they are tedious. They are certainly not mindful, because one focuses on the past and the other on the future, and we all want our features right now. Agile without planning and documentation leads to technical debt (something I grumbled about recently, with more to come).
Technical debt is the driver behind this particular rant, as I recently observed the creation of an equivalent jumbo mortgage with an early balloon payment due. In the same recent article linked earlier I mentioned how sometimes a platform migration is driven by a desire to get out of unacknowledged tech debt. In this instance, I witnessed the debt being incurred as a result of the migration. Specifically, the approach was taken to manually migrate data that was in immediate use while configuring the application without documentation in order to get into production as quickly as possible (the root cause of most tech debt). The idea was to migrate the rest of the data later. This migration, like many these days, was from one SaaS to another. The secret to a maintainable and extensible SaaS application is including flex fields in the data model. These are fields that have no pre-defined purpose so that customers can use them for customization and the vendor can avoid the hairball that results from customizing for each customer. The downside to this data model is that if the customer changes default labels and makes heavy use of the flex fields without documenting all of these changes, the data migration effort increases several-fold.
So, here is a real-world example of the impact of technical debt in a compressed timeline that is easy to follow: Short cuts were taken to quickly “realize value” from a new platform, and then to fully taken advantage of the platform subsequent efforts are increased, resulting in a much higher total cost and longer timeline to completion to get that short term win. None of this is the result of bad people or malicious intent, in fact, quite the opposite. It is the result of a “modern” business culture that has evolved to focus on quarterly earnings. It also explains why businesses that really want to innovate either do so before their IPO or go private to get back on track. It’s not because software can’t be done right in a standard corporate structure, but that “Continuous attention to technical excellence and good design enhances agility”.