RailsConf 2018: Communication 101
By Steph Skardal
April 19, 2018
The punchline is that I’m writing about Communication: 101 here at RailsConf 2018, but there is no joke. In “Harry the Hedgehog Learns you a Communication”, Laura Mosher presented examples of common pitfalls we encounter in our daily lives as software engineers and 5 tips to mitigate those pitfalls. All of these tips are both helpful in the world of consulting when interacting with a variety of clients and coworkers, but also very personally valuable from the perspective of a parent—I want to exemplify strong communication skills to my children as they absorb everything around them, the little sponges that they are. Here are the tips that Laura went over:
Think, Then Speak
This is the foundation of good communication, and seems pretty obvious, but in the age of chat, direct messages, and instant email responses, it’s easy to fall into the trap of responding immediately with emotion and/or without thinking about what you are going to say. First, consider what you want to say, who your audience is, and how to best explain to that audience.
In consulting, I find this applicable in a couple of scenarios:
- When hearing unsettling or harsh words from a client over dissatisfaction on a project, if you have an emotional reaction, it’s best to wait until you can respond with a level-headed response with a thoughtful explanation of your perspective.
- When receiving technical review on implementation of some feature XYZ from a coworker, instead of responding immediately defensively, wait until you can provide feedback with better perspective.
Drop the Nots
Laura says, “We often reach for denial or communicate in forms of negatives instead of answering directly.” Nots enable misunderstanding. Instead of denial or avoidance, answering directly and taking accountability can ultimately build a better long term relationship between those who are communicating.
Here are some examples of how we might use nots:
- “That’s not my job.” Instead, offer who might have that responsibility, and offer to ping them.
- “That’s not my problem.” Skirting responsibility here can be perceived poorly. Even if you aren’t the domain expert, offering to help anyway will be perceived positively.
- “Not now.” If you are unable to drop everything right now to work on some issue, offer to help prioritize the task and revisit it later.
Drop the Justs
Drop the use of “just” in your communication. Here are examples of how the word “just” is commonly used:
- Elitist just. Examples include: “Why don’t you just?”, “Just do …”, “You can just …”. In this case, instead of dictating, offer an alternative and an environment for back-and-forth communication.
- Diffident just. Examples include: “I just do lighting talks”, “I’m just a developer”, “I just ran a 5k”. The diffident just represents your own lack of self-confidence and/or imposter syndrome, and you undersell your own abilities.
- Diminutive just. Examples include: “You’re just sad”, “Why can’t you just be happy?”. Similar to the diffident just, but directed at others, this diminishes others and invalidates others’ feelings.
Watch Your Phrasing
Common phrasing pitfalls are:
- Self-deprecating. Examples: “I’m fine”, when you’re not. Be honest about your feelings.
- Stereotyped. Examples include: “Ladies and gents”, “Heroes to men”. “Man up”, “You act like a girl”. Such phrases are commonly said, and they perpetuate stereotypes that are exclusionary.
- Ambiguous. Ambiguous phrases, often used in humor, are phrases that can be interpreted in two or more ways. Be careful using these in communication when asking for support or involvement—it’s better to be direct when asking for the specific support you may need.
Praise in Public, Critique in Private
The final bit of advice that Laura gave was to praise in public and critique in private. Praise is recognition that is motivating on the receiving end. Everyday praise is valuable.
Critiques are best given and received in private, not guided by emotions. Remember that the person receiving critiques may not yet realize what they said or did was not ideal, so be kind and patient to that person. Again, I see this as very applicable in both the context of code reviews and parenting. The author of a new feature may not be aware of best practices in the specific code framework, just like a child may not realize that coloring on furniture is not the best practice use of crayons.
Thanks, Laura, for your talk!
Stay tuned for a summary post up about RailsConf with references to many of the technical nitty-gritty talks I’ve attended.
Comments