Tag Archives: email

Episode 101 — Effective Email

BlackberryEmailElectrical engineer Bob Schmidt joins Adam, Carmen, Brian and Jeff to talk about the importance of making a good impression, and delivering the intended message, with effective email.

  • Jeff readily admits that he doesn’t use newer communication channels such as WhatsApp or Facebook Messenger.
  • Rather than use Instagram, Jeff has a Kodak carousel projector in his basement for showing slides. (An episode from the TV show Mad Men gave rise to a demonstration of the carousel projector.)
  • Brian has fond memories of filmstrip projectors from his school days.
  • Our guest for this episode is Bob Schmidt, an electrical engineer who joined us previously for episodes about Troubleshooting and Ideas Without Words.
  • As with most career professionals, it is important for engineers to be effective in their use of email.
  • Bob’s book about troubleshooting, An Engineer’s Guide to Problem Solving, continues to do well for him.
  • Some of our guest’s recent experiences confirm the notion that “a picture’s worth a thousand words.”
  • Brian is continuing to make use of Microsoft OneNote, having recently delved into it’s collaborative features.
  • Bob has a list of five keys for delivering effective email:
    1. Spend some time on the subject line
    2. Know to whom you are speaking
    3. Check it twice, read it thrice
    4. Oh, those miserable attachments
    5. STOP, CAUTION, and YIELD signs along the road ahead
  • Brian admits sending emails with a blank subject line, but Bob says that’s inconsiderate to coworkers who must interpret the email’s subject and importance on their own.
  • Carmen and Bob “tag” their emails by topic or project to ease subsequent sorting and identification of important information.
  • Go ahead and change the subject line to fit the current conversation, suggests Bob.
  • Our guest points out that blind carbon copy (Bcc:) recipients do not receive replies to the original email on which they were copied.
  • Send carbon copy (Cc:) emails to individuals needing to know of an action or decision, but who are not directly involved in carrying out the action or decision.
  • Send Bcc: emails to individuals needing a high-level alert that progress is underway, but without burdening them with subsequent discussion details. As a courtesy to other recipients, make a note in the email about who is receiving the blind carbon copy.
  • Commenting on the dangers of using the “reply all” button, Brian mentions an email storm circulating at Time, Inc.
  • Bob suggest that engineers never send an “angry” email, noting that Abraham Lincoln would write “hot letters” that were never sent.
  • Jeff and Brian wander into a discussion of whether electromagnetic pulses (EMPs) could wipe the hard drives on which emails are often stored.
  • A great deal of corporate data from Sony Entertainment was made public in 2014.
  • Brian has declared email bankruptcy.
  • The group is general agreement that “SMS-speak” is not appropriate for professional email.
  • Carmen shares his brief experiences with Slack, a cloud-based team collaboration tool.
  • Bob suggests using HTML effects sparingly in work-related email.
  • Carmen uses disposable email addresses from Guerrilla Mail to lessen the amount of spam that shows up in his mailbox.
  • Jeff mentions the self-destructing tape player featured in old episodes of the TV show Mission Impossible.
  • Bob can be reached via his Pretty Good Problem Solver website.

Thanks to Ian Lamont for use of the photo titled “BlackBerry email on the BB 8330.” Opening music by John Trimble, and concluding theme by Paul Stevenson.

Episode 89 — Early Lessons

compassIn this episode of The Engineering Commons, we discuss the lessons we learned during our first two or three years of working as engineering professionals.

  • Adam considers himself a fast learner, although he finds that pain occasionally increases the rapidity of his learning.
  • In this episode, Adam, Brian, Carmen, and Jeff discuss lessons learned early in their engineering careers. (The raspy voice belongs to Carmen!)
  • Carmen learned that organizational change comes slowly, and requires a consistent and concerted effort to alter behaviors and attitudes.
  • It was news to Jeff that technical issues of great concern to him individually could be of such little concern to his employing organization.
  • Although Jeff felt he was given a great deal of technical autonomy early in his career, Adam found that his activities were a bit more tightly controlled until he acquired his professional engineering license.
  • Carmen discovered his job is largely troubleshooting and experimenting, as he is expected to sort out unexpected system behaviors.
  • Robert Erickson’s book, Fundamentals of Power Electronics, is a bit too theoretical for Carmen’s taste.
  • Jeff recalls learning that upper-level managers have to make semi-educated guesses about critical business issues such as market size, customer demand, and resource availability.
  • Survivorship bias can cause us to overlook conditions and situations that may lead to organizational failure.
  • HexBright was a programmable open-source flashlight design that seemed to be a good idea, but was unable to survive long-term as an ongoing business.
  • Brian was a fan of the Zune media player, despite its lack of market success.
  • One of the best ways to learn quickly, Brian reports, is to chat with others who have substantial experience dealing the technical issues you are trying to understand.
  • Jeff discovered that vendors are willing to supply technical information, but they expect reciprocity when purchasing decisions are being made.
  • There can be multiple distributors for a particular product in a given region, and Jeff has irritated a few salespeople by buying goods from the “wrong” distributor.
  • When meeting with someone who is typically pressed for time, it’s good practice to ask about their availability as soon as your “brief” conversation looks like it might drag out longer than you originally anticipated.
  • Be cautious about sharing technical problems, Brian notes, as rumor and fear can quickly spread if technical concerns are evaluated outside of their intended context.
  • Whether you like it or not, says Adam, you have to be aware of (and frequently participate in) the political games of your employing organization.
  • Jeff notes that answers are rarely found at one’s desk; if you want to learn about a problem, go to the manufacturing floor, or the machine shop, or a customer’s site.
  • Brian suggests that, whenever possible, engineers should avoid sending emails. On the other hand, Adam finds email a useful tool for documenting agreements with others.
  • Adam finds meetings to be a particularly effective means for arriving at a decision when multiple people need to participate in the process.
  • Jeff recommends that young engineers not promise too much, as the desire to please must be balanced by an ability to deliver.
  • Loading tests on the Boeing 777 wings illustrate delivering exactly what was promised, says Brian.
  • Brian and Adam mention the “rule of pi” for estimating the time and cost of first-time projects, as discussed in this podcast’s very first episode.

Thanks to Pete for the photo titled “Project 366 #233: 200812 A Sense Of Direction.” Podcast theme music by Paul Stevenson.