Many engineers use code snippet managers to quickly auto-complete repetitious and predictable keystrokes. I have used Dash for many years to autocomplete test cases, import React from 'react' and to correct things I always misspell (in case you ever see it, my full name is Katherine not Kathering — why do I do this?).
Having learned a lot of strategies for effective communication, I started building snippets to keep them top of mind. These snippets help me to focus my thoughts, keep my audience in mind, and help me stop procrastinating. Whenever I had to create a presentation, write up a technical proposal, or to deliver constructive feedback.
Creating Presentations: Think of Your Audience First
I attended a workshop on “executive presence”. It was information dense, and I learned a tremendous amount about how to optimize your message for your audience. Much of the workshop centered on public speaking, so I also learned how to connect with your audience during a presentation, how to manage Q&A, and how to build and deliver a slide deck that enhances your message rather than distracts from it. Knowing that I would quickly forget many of these strategies, I distilled them into a snippet. I type `start, and my blank document is replaced with this template:
--------------------------------------
Goals
Audience: name your stakeholders and their currency
3 key takeaways
Call to action
--------------------------------------
Tell them what you will tell them.
Tell them.
Tell them what you told them.
--------------------------------------
Evoke emotion
Cut to the point
Arrange message for memorability
--------------------------------------
1. Agreement: provides a baseline and direction; big picture
2. Context: What is the problem and what is the pain? Brings the big picture closer
3. Story: narrative demonstrating a change from pain to no-pain
4. Connections: use analogies to explain and metaphors to highlight
5. Conclusion: summarize what was learned, and make your call to action.
--------------------------------------
Visuals should accentuate, reinforce, and repeat your message
--------------------------------------
Don't answer the question "what is X?",
answer the question "why should I care about X?"
Going from less understanding to more understanding,
don't be afraid to cover the basics:
it accounts for everyone and validates the experts.
---------------------------------------This snippet ensures that I start with the goal in mind, that I aim my content at the right audience, and that my takeaways are clear.
Writing Technical Proposals: Exploring Multiple Options
One of the common asks for a technical lead on a software team is to provide technical estimates and options for upcoming projects. These requests happen so frequently, I came up with a formula that made my communication clear and my results consistent. I type `tech and my blank document is replaced by this template:
# Technical Problem Writeup Template
## Problem
High level overview of the problem.
Determine your audience.
Summarize the problem at the right level of detail --
* Executives: describe the WHY in terms of risks to the
roadmap, team, reliability.
Do not include technical detail.
* PMs: describe the above but with some technical detail
* Engineers: describe the technical challenges
## Options
* Include at least three options, one of which is to do nothing.
* List Pros and Cons of each option and be specific:
“link from X to Y requires an extra query which will
impact performance” rather than “bad customer experience.”
* Make a recomendation
* Include a level of effort
* Considered and Rejected
* If any options were rejected, itemize and bullet
point the reasons they were rejected
## Resources
Links that didn’t fit into the Details section,
including other documents that describe or
reference the problem at hand.Using this snippet has leveled up my ability to communicate technical trade-offs to the right audience at the right level. I have been using it for almost two years, and I believe this strategy is one of the main accelerators of my career from senior enginer to architect.
Delivering Constructive Feedback: Stick to the Facts and Stay Curious
Delivering constructive feedback is hard, and there are more ways to do it wrong than to do it right, which is probably why we avoid it. After reading Resilient Management by Lara Hogan, I learned some incredible strategies for how to construct feedback that emphasizes empathy and improves the odds that your feedback will land as you intend. It doesn’t nearly do justice to Hogan’s beautiful blog, but when I need to carefully consider the impact of the feedback I need to deliver, I type `feedback and my blank document is replaced by this template:
-------------------------
## Feedback equation
Facts + impact + open question = good feedback
Keep asking "what is the impact of THAT" until you have the real impact.
## Frame the impact in terms of what THEY care about:
* Belonging? It makes you seem unapproachable...
* Improvement/progress? It slows down the project...
* Choice? It reduces our options...
* Equality/fairness? Others have to pick up the slack...
* Predictability? It disrupts the routine...
* Significance/status? It makes us lose trust...
-------------------------
## Open questions
* What are you optimizing for?
* What are you hoping to accomplish?This snippet ensures that I am framing my constructive feedback in a way that will be most effective for the person receiving it. I consider their core needs, stick to the facts, and remain open to learning more about how they perceive things.
As a brief aside, I recently read “Difficult Conversations” by Douglas Stone, Bruce Patton, and Sheila Heen. They say very wisely that if you think you have all the information about a situation, then you are not ready to have a difficult conversation. This snippet is a good place to stick a reminder to get and stay curious about where someone else is coming from: I think I will add it so that I will remember it for next time.
Snippet managers are useful for more than just code completion
I use Dash, but there are many different code snippet managers out there. Find one that works for you and you will bring your written communication to the next level.
In case you are curious, here is the result of the snippet template I used to write this blog post:
--------------------------------------
Goal: To persuade the reader that snippets are useful outside of the code editor.
Audience: Software Engineers and Engineering Managers
3 key takeaways:
* use snippets to remind yourself what questions to ask
* use snippets to craft and focus your communication
* use snippets to break through writers block through prompts and structure
Call to action:
Use Dash or some other snippet manager to remind you of strategies you tend to forget.
--------------------------------------
...
Don't answer the question "what is X?", answer the question "why should I care about X?"
Why should they care about using snippets?
Snippets are a means to an end: providing consistent, clear communication builds trust with your peers and managers.
Career growth beyond an individual contributor role requires strong communication skills.
Building trust with your organization is good for your career growth.
---------------------------------------