Communication: Did we talk about that?
This post originally appeared in my LinkedIn newsletter, “The New Admin”.
Salesforce released a set of 14 skills that they have identified as essential to a successful Salesforce Admin called the Salesforce Skills Kit. I’m going to be writing about each of the 14 skills as if they are being discussed in the context of an interview for a Salesforce job. Whether you are looking for a new job or writing job descriptions for open positions, be sure to check out the Skills Kit. This is also the first issue of my new LinkedIn Newsletter. Be sure to subscribe so you don’t miss any articles.
Let’s take a look at the first skill: Communication!
Question:
Can you give us an example of how you have collaborated with a team internally and an example of how you have trained users?
Answer:
In 2020 shortly after COVID caused all live events to come to a stop I was offered a position on the QA team at my old company. This was a new position for me within the actual team structure, but not unfamiliar work for me. I had done similar work in the past before an actual QA team existed, but I worked mostly in a silo back then. On this new team, I was the only remote person, which meant daily stand-ups over Google Meet every morning to go over work from the previous day and the plans for that day and constant Slack conversations and Huddles.
This was my first introduction to the Scrum workflow and learning how to work within a structured team and on a sprint schedule. My main responsibilities included writing new test cases and testing new features for platform parity before writing up test cases. Throughout this process I was improving my ability to write detailed and easy-to-follow bug reports in JIRA, discuss feature mismatches with development teams on Slack in product channels, and provide feedback similar to what would happen during UAT.
Each of these responsibilities required a different type of communication. For test cases, I have to be able to clearly communicate steps so that someone unfamiliar with a feature could come in later to test it. For bug reports, I needed to be able to provide accurate steps that a developer could follow to replicate the bug and reach the same result. I also needed to explain the expected results based on my understanding of the feature or based on a platform difference and explain the actual results that I was seeing. I also learned how to communicate a lot of information with the right GIF in Slack.
My main job for the last eight years has been in live events. I’ve worked on all kinds of things from corporate meetings to concert tours. After a couple years off the road due to COVID, I have been back on the road for a tour in the fall and again this spring. I’ve really been thinking a lot about how communication is important in setting up for a show and how it’s really similar to working with new users in a business environment.
I had a call recently with someone and I started talking about this example and admitting how it’s one of the areas I sometimes struggle with. When I’m leading stagehands through building an LED wall there are about five or six steps that have to be followed, and they are repeated in the same order until we’re done building. My expectation is that I only need to give the instructions one or two times and then everyone will be able to work together and repeat the steps. When things don’t go this way and I find myself repeating the same instructions over and over I start to get frustrated. When I start getting frustrated my ability to communicate with my stage hands starts failing. This isn’t good for anyone. It doesn’t benefit them and it makes me look like a jerk.
On a good day, I can step back and reset and slow down. I try to make sure I have more good days than bad ones! I remind myself that I have been doing this kind of work for more than a decade and have learned a lot over the years. When I started I did a lot of things wrong and had to be shown how to do the same thing several times. I also work with the same equipment over and over. Something I can do with my eyes closed might be something a stagehand has never seen before. It isn’t their fault that they aren’t as experienced as I am and I have to remember to be patient with them.
The same goes for a new user. By the time I get to training users on a new feature or answering their questions about why it isn’t working the way they expect, I have likely already spent several days if not weeks testing the feature, writing test cases, going back and forth with developers about how things should work, and looking at the feature from every possible direction. While I may have domain expertise over this feature, the user is brand new to using it and learning the different ways it can be used. They might have even found a “new” way of using it that we never expected.
Successfully communicating with users requires being able to put my technical experience into easy-to-understand answers and an immense amount of patience to answer the same set of questions from users, even if it’s the 100th time explaining it to them. And honestly, if I’m having to explain something that many times, maybe it’s a sign that my way of communicating something isn’t working and I need to find another approach.
Responses