Recently, I was invited to submit a proposal to the upcoming Society for Technical Communication (STC) conference in Spring 2023. I was certainly excited about this opportunity because:
- I’ve never attended a technical writing conference
- I’ve never given a presentation outside of an academic or business setting
The mid-September deadline came and went. At least, that was until they had extended the deadline to the end of the month. Great! They are thinking of my people: the Chronic Procrastinators. Two weeks is plenty of time to come up with a proposal, right?
The deadline came and went.
And here we are. I would say that I’m embarrassed, but I’ve navigated all of my life in this way. I do a great job… eventually. And all at the cost of my sleep hygiene and general stress levels. I’m still working on this, so don’t think that I’m about to give some advice on how to deal with this level of general life management.
But if what I’m saying feels relatable—I see you, friend. You’ve got this! Just know that this doesn’t make you bad at what you do, so please don’t be too hard on yourself.
So, instead of unpacking my procrastination habits, I would rather talk about some of the topics that I would have liked to cover at the conference.
[More] About [Me]
For context (and friendship), you should know a little bit about me that I don’t talk about in About because I don’t think anyone’s job truly defines them as a person, but that’s a different topic. After a false start as a Pre-Med major, I started studying technical writing in college in 2010.
I applied my newly learned technical writing principles to:
- The rest of my classes
- My jobs in web development and marketing
- Grocery shopping
Then, “Technical Writer” officially became my job title in 2016.
In every job I’ve had, I’ve worked with folks in sales, marketing, support, engineering, and every role in between. In technical writing—and any other job—the most important skill you can develop is communication. Yes, this is a vague, generic statement, but it’s also true.
And it’s not actually vague or generic, so I take it back and you should too.
Communication
There is no single answer to communicating with different subject matter experts (SMEs). Salespeople and engineers process information very differently. This applies to virtually any two job titles that you can imagine, so how does communication even work across disciplines?
First, consider the concept of code-switching. You already do this now without realizing it, but it’s what happens when you catch yourself speaking differently depending on who you’re talking to. If you’re anything like me, you speak much differently to your parents than to your friends. And if your parents are your only friends, then you ruined my example.
In the tech industry, I often interact with software engineers and product managers to gather information about the product I am documenting. My communication strategy differs depending on who I interview.
Software Engineer
When I interview engineers for information on a Fancy Widget Feature, I can expect succinct, technical answers to my questions. Typically, I am talking to a person who helped build the feature, so they know exactly what it does and does not do. Sometimes they will give me information about the context of the feature, and sometimes they won’t.
This means that I need to exercise due diligence and research the feature before I talk to an engineer so that I can ask the right questions to satisfy my documentation requirements. This isn’t because they’re gatekeeping information—it’s because they simply can’t answer the questions that I don’t ask them.
Software engineers are my favorite, but don’t tell the product managers.
Product Manager
Product managers (PMs) are the people who have a high-level understanding of how a Fancy Widget Feature works because they’re the ones who conceptualized it and introduced the idea to the engineers.
When I interview a PM, I typically ask them questions based on user workflows and use cases for a feature. I expect their answers to center around how a feature should work, but I may need to verify nuanced details with an engineer or by testing out the feature myself. This isn’t to say that PMs don’t know how a feature works on a technical level, but that an engineer may have accurate, detailed answers.
Product managers are my favorite, but don’t tell the software engineers.
Flow With the Go
In technical writing, you should go with the flow of your specific SME during a demo or interview. Let them talk and try not to ask questions until they finish their thoughts. This isn’t to say that you shouldn’t ask questions, but be prudent about when you ask them. When you realize that the conversation with your SME isn’t giving you the kind of info you need for your document, you can steer the conversation back toward the requirements for your document.
This means that you should begin each SME conversation with a plan, and this is so important that it’s a Future Blog Topic™️.
So, if information gathering and interviews aren’t as productive as you were hoping, either change how you frame your questions or ask your SME if they know who you should ask about what you’re looking for.
And to introduce yet another consideration, think about the channel in which you’re communicating with your SMEs. Some folks are better at writing their thoughts down and other folks are better at explaining things verbally. This isn’t the proverbial Neon Genesis Evangelion situation where the Human Instrumentality Project succeeded and caused our souls to merge as one—everyone is a bit different.
In the end, it doesn’t even matter for better communication with your cross-functional teams, be flexible with how you approach each SME.
And if you find someone that can accurately explain anything that you ask them, never let them go.
What’s Next?
Since I’m not presenting at a technical writing conference in the near future and I clearly have feelings about my job, I plan to continue writing my thoughts down in my blog. It’s 2022 and this is my first post in over a year, so I might as well make the most of my web host and domain fees.
In general, I wanted to present how to write with empathy, but I think that I’ll unpack that idea topic by topic, post by post.
Maybe by the 2024 conference, I’ll have a presentation to submit (on the day of the deadline).