Elevator Speeches, 30 Second Commercials, and Cocktail Talk
One of the most fundamental, and often underutilized and under thought tools for networking is the "elevator speech". Also known as a thirty second commercial, or cocktail talk, it's a way of talking about what you do for a living. A lot of people don't use them, or if they do, they don't gauge it towards their audience. Ultimately, it's a promotional blurb you share when making conversation, whether you're actively looking for work or not.
I've heard from a variety of sources that everyone should have one. Personally, I think everyone should have three. At least.
Yes, you read that correctly. Think about it. You talk to different types of people with different backgrounds every day. You need to be able to make small talk, even if you're not comfortable with it. This isn't a real speech, it's just a familiar, very short story, that you can share with anyone.
Social networking isn't just for job seekers and sales people. It's someone we all do, and need to do, and really, you should want to do it. You want to leave positive impressions in people's minds, and you never know; that guy you talked with for five minutes at a happy hour may remember you a few months from now when his boss is asking him for names of people who do what you do. Or you may be remembered by the bosses husband as the one who never said anything.
It really doesn't take much, just practice. Start with the one you should rarely use first, because it likely what you'd say on first impulse, with in-speak that doesn't explain what you do well to those outside or field, industry or specialty. That first impulse you have has the seeds of the other two, but is likely going to leave you with the "that's nice" nod.
For the last eight years, I've worked at an outsourced service desk call center, working in various roles, most recently as a Technical Writer focusing on knowledgebase management and process management, ensuring we had all procedures and solutions addressed in the SOW covered, how to handle out of scope issues, develop documentation standards and curriculum, and continuously finding ways to improve performance based on SLA metrics, ISO 9000 standards, and internal standards, which were aligned with ITIL.
Yeah. I fell asleep writing that just now. But once you get the jist of it, you can find ways to pretty it up for the powerhouse Tech writers you meet at a conference.
Once you do that, then make it more generic, so, say, a recruiter or hiring manager, or someone who may have a general understanding of your field can understand what you do.
Most recently I was a technical writer at a helpdesk providing technical support for other companies, which involved taking the contractually agreed support and translating that into procedures for the helpdesk agents to follow. Along with that I'd develop the documentation for the fixes they'd use or other information they'd need to support that client, including reference and training material. A lot of the work involved finding ways to help improve performance based on the Service Level Agreements (such as how fast we answered the phone, how many issues we fixed on the first call, and more). The tools they used had to be written in a way that the helpdesk agent could read the steps they had to follow and the fixes that they could use while talking to the caller, without sounding like they were reading the steps they had to take, or the solutions they had to follow. Along the way I developed a lot of best practices, and created a lot of material that were adopted by other accounts and other centers, including global standards for helpfiles and knowledgebases.
Now this version is understandable beyond that center I worked at, by people who may not work in IT. If I'm really smart, I'll use this version and go back and tweak the In-Speak version.
Lastly, make one that's really generic, that you could use for a "What Mommy/Daddy Does" speech at your child's school. Or while waiting in line at the movies.
You know when you're at work and you have a computer problem and you have to call the helpdesk? I'm the one who writes the procedures they follow, and what they use to find out how to solve the problem, if they don't know it, and wrote the training that they had before they even got on the phone.
Not the most slick answers, I know, but you get the drift, right? Cover what you do, make it understandable, and throw in something that make someone want to keep talking to you. Short and sweet.
Now, if I'm really smart, I should create one that emphasizes more of the transferrable skills that go beyond the tech writer title. But what you should think about after suffering through this very long ramble is, don't have just one 'promo' in your head, have a few, that you can tweak based on the audience.





Comments