Networking for introverts

I’m sure that many of my friends would describe me as being outgoing, and even outspoken. I’ve spoken at a number of SQL Saturdays, and (as a musician), I’ve performed in front of audiences (I’ve long since lost my fear of performing int front of a crowd).

So it might surprise some of you when I say that I can sometimes be an introvert.

It mostly depends on the situation. When I’m doing a presentation, I’m expected to be doing the talking, and I can hold my own. When I’m discussing a topic that I enjoy, such as baseball, college sports, music, movies, or CrossFit, I can talk your ear off. When I’m among friends, I can converse for hours.

However, I wasn’t always like this, and there are times when I can revert back. When I’m in a room full of people that I don’t know, I can just as easily be the person sitting off the in the corner all by himself. In years past, especially during my adolescent years (and even for a few years after college), I had trouble with mingling with people and breaking the ice.

So for those of you who consider yourselves introverts, I feel your pain. I get it.

I also want to tell you that if you want to network but have trouble doing so, there’s hope. If you’re shy or introverted, it is possible for you to network with other people.

Let me start by saying something that you probably don’t want to hear: it will likely take some effort on your part. I realize that that can be a scary thing, and it will likely make you uncomfortable. Experiencing some discomfort is a part of growing and making yourself better. As I’ve written before, getting ahead will take some degree of discomfort.

That said, you don’t have to fear being uncomfortable. You don’t have to dive headfirst into the pool without learning how to swim. The process (as any) can be done in a number of small steps.

Let’s start by talking about initiating contact — breaking the ice. This is probably the most difficult — and scariest — part of networking. Once you’ve broken the ice, the rest goes downhill. But it’s easier said than done. So how do you start the conversation?

I’ll start with one of the simplest ways: say “hi!” It might not seem like much, but by using this simple little word, you’ve just broken the ice. You’ve initiated contact. Once you’ve said that, you can build from it and connect. Some suggestions for following up: “How are you?”, “How do you like this event?”, “What do you do?”, “Where are you from?”, and so on.

I do want to point something out regarding these followup statements. You might notice that they all end with a question mark. They ask questions geared at getting to know the other person. If you show interest in the other person, chances are that (s)he will be more likely to engage you. Dale Carnegie (of How To Win Friends and Influence People fame) had a great many quotes about how to engage people. Many of them involve showing interest in the other person.

That said, be careful not to be too personal, deep, or overbearing. Instead of making other people interested, you might end up driving them away. Bear in mind that we’re not talking about how to pick up people of the opposite sex (or the same sex, if that’s what you’re into) at a bar; we’re talking about professional networking. Granted, these approaches will likely work in social situations, but that’s not the point of this article.

Finding some type of common ground to talk about will likely go a long way. If you’re attending some kind of event (SQL Saturday, a class, your kid’s concert or Little League game, etc.), discussing the event in front of you is a natural place to start. If you’re attending the same event, chances are that you’re there for similar reasons, so that makes for something of mutual interest to discuss.

I often find that a fun or neutral topic makes good fodder for conversation. (Note: “neutral” is a key word — more about that in a moment.) For example, I’m a sports fan, and although not everyone is into sports, I usually find that sports is one of the most universally beloved topics that people like to talk about. Whether you’re into baseball, football, basketball, soccer, cricket, rugby, or underwater hockey (yes, that really is a thing — I looked), sports is usually a good, somewhat neutral topic to discuss. Even if the other person is an opposing fan, it could make for fun conversation. I’m a Yankee fan, and I get into the best conversations with Red Sox fans.

I said that “neutral” is a key word. There are some hot-button topics that are verboten and should not be broached. Probably the number one topic to avoid is politics (race and religion are likely a close second). Personally, I absolutely despise politics, and will not talk about them. If you want a sure-fire way to get me aggravated, start talking politics with me. A conversation about politics will drive me away and make me want to avoid you, not engage you. There are some subjects that make me say “get the hell away from me,” and that’s at the top of my list. You’ve been warned. (And, for the record, if you really must know where I stand, I’m a registered Democrat, and I consider myself a left-leaning moderate.)

Bottom line: if a topic is controversial, stay away from it. Don’t even bring it up.

I’ve talked about things you can do to break the ice. But what about a few ways for someone to break the ice with you?

How about clothing? I wrote an article a while back that talks about how what you wear can initiate networking. I often wear T-shirts, sweatshirts, and caps that depict my favorite sports teams, interests, fraternity, and my alma mater. I’ve sometimes been called a “walking billboard.” But in many cases, it’s enough to encourage conversation. Your own clothing can often be a conversation piece.

Being cognizant of your body language can also be helpful. Your own actions often speak louder than what you actually say. Be mindful of smiling, crossing your arms, or making eye contact. Sometimes, it could be the difference between initiating a networking contact and remaining a fly on the wall.

These days, even if you’re uncomfortable with meeting people face-to-face, you have the option of networking online. With the advent of social media, even introverted people can often break the ice online.

And as I previously wrote, it’s also helpful to have business cards with you, ready to be handed out.

So if you feel socially awkward and are uncomfortable with networking, be aware that you are capable of joining the conversation. It might take a little time and practice, but even people who are shy or introverted are capable of networking.

Testing something? What’s the test plan?

Imagine if you will that you’ve been asked to test a product. The product could be anything — software, a car, a kitchen appliance, a piece of sports equipment, whatever. For the purposes of this article, we’ll say you’re working at some company, and you’ve been asked to test a piece of software.

You’re told to go into an application, and you’re given this instruction.

“Okay, test it and see if it works.”

That’s it.

How would you feel? Vague? Confused? Frustrated? Abandoned? All of the above? Something else?

Well, I, myself, have been put into this situation more times than I care to admit. It’s one of the most frustrating job situations I’ve ever been thrust into.

What, exactly, constitutes “see if it works”? I could simply start the application, see if it starts, and say, “okay, it works.” I suspect that that’s not what the people who make the request are looking for. Yet time and again, I get a request from a developer or a designer to test something, and that’s the only instruction I’m given.

And it’s frustrating like you wouldn’t believe.

What’s even more frustrating is when (not if) the application comes back with some kind of problem, and the people who asked you to test come back with, “you said you tested this! Why is this broken?”

Want to know why there’s so much friction between developers and QA personnel? This is a likely reason. This is something that definitely falls under my list of documentation pet peeves.

The fact is, if you develop a product, and you need to test it for functionality, you need to specify what it is you’re looking to test. You need to define — and spell out — what constitutes a “working product” from one that’s “defective.” Just because a car starts doesn’t mean it’s working. You still need to put it in gear, drive it, steer it, and make sure that it can stop.

If you are creating a product, you need to describe what parameters are required for it to pass testing. If you’re asking someone in quality control to test your product, provide the tester with guidelines as to what should be checked to ensure the product is functional. Better, provide him or her with a checklist to determine whether or not your product can be released. If you discover additional items that need to be tested, then update the checklist.

(If you want to know more about checklists, I highly recommend The Checklist Manifesto by Atul Gawande. It’s actually a surprisingly excellent read.)

So any time you release a product for testing, tell the testers what it is that constitutes a “good” product. Don’t just send it off with vague instructions to “make sure it works” and expect it to be tested. More often that not, that will result in a failed product — and defeat the entire purpose of why you’re looking to test it in the first place.

Dont rite so gud? Don’t let that stop you

Eye no that a Lot of ppl dont Right to gud. That shudnt keep ppl frum Riteing. Lot’s of ppl dont Right gud.

Did you have trouble reading that paragraph above? I actually had trouble writing it. The late Harry Chapin had a song called Six String Orchestra in which he intentionally plays badly. I once said that if you’re an accomplished musician, one of the most difficult things to do is to intentionally play something badly. If you’re a writer, I suppose the same is true for intentionally writing something badly. I remember reading a novel, Flowers for Algernon, in which a mentally-retarded man, writing in the first person, increases his intelligence after an operation. It was interesting reading the account as his intelligence and his awareness increased, and I can only imagine as to how challenging it might have been to write.

Anyway, in my technical writing presentation, one of the points I try to make is that not being able to write well should not discourage people from contributing to documentation.

I’m the first to admit that I’m a grammar snob. I’ll often be that person who is “silently correcting your grammar.” I cringe anytime someone doesn’t know the difference between “your” and “you’re.” I have to hide my eyes anytime someone uses an apostrophe-S as a plural. And I still believe that anyone who says “irregardless” should be flogged.

That said, I understand that not everyone is a good writer. Just because someone does not write well doesn’t mean that person should be discouraged from writing.

For one thing, as I said before, everyone has to start somewhere. Someone once said that “one of the dumbest quotes ever coined is ‘do it right the first time.’ It’s almost NEVER done right the first time.” And the one sure-fire method to improve is to practice. The more you write, the better you’ll get.

If I had to offer a piece of advice to someone who wanted to get better at writing, I’d suggest reading material by your favorite author, then try emulating that author’s style. For example, a few of my favorite authors include Stephen King, Tom Clancy, and Terry Brooks. I enjoy their books and their writing style. After reading their works, I found myself wanting to emulate how they write. I discovered that, over time, my writing kept getting better.

For another thing, an inability to write well doesn’t mean a person lacks intelligence or knowledge in a subject. That person often contributes to documentation as a subject-matter expert (SME). An SME has a great deal to contribute, but knowledge transfer can be challenging. To be fair, this is not an easy thing to do; one of the most difficult tasks is to communicate knowledge to other people. (I even have an entire presentation about this.) People often have valuable information to contribute; the challenge lies in how to convey that information. If someone with information doesn’t write well, that shouldn’t stop him or her from doing so.

Granted, if a piece of writing needs to convey a “good face” (say, client documentation or marketing materials, for example), then it’s important for it to be well-written. But if it’s a mere matter of knowledge transfer, it’s more important that a concept is written down rather than not be written at all. If an idea needs to be cleaned up, go ahead and write it down, and let someone else do the grammatical heavy-lifting. Not being a good writer should not be an impediment to writing at all.

Why design matters

“A user interface is like a joke. If you have to explain it, it’s not that good.”
— unknown

There are two elevators in the building where I work, including one that doubles as a freight elevator — it has front and back doors for access.  This particular elevator has a bank of buttons shown in the photo below.  The buttons for the rear door are denoted by the “R” next to the floor number.

elevator_buttons

Here’s why these buttons frustrate me.  Quickly, tell me which open and close door buttons work for the front and rear doors!  Yeah, I can’t tell, either!  You would think that the upper buttons control the front and the lower ones control the rear, but you can’t discern that from the way it’s laid out (and I’ve found that it isn’t necessarily the case).  I have had multiple occasions where I’ve tried to hold the door open for someone rushing to catch the elevator, and ended up hitting the wrong button.

Had these buttons been properly laid out, the open and close door buttons would both been placed under each respective door button column — i.e. the open and close door buttons that control the rear door should have been placed under the buttons marked “R,” which would clearly indicate that those buttons are used for the rear door.  That would make sense, wouldn’t it?

Raise your hand if you’ve ever been frustrated by a product simply because the user interface was poorly designed.  I would expect every hand in the room to be up.

Don Norman, an academic researcher considered to be an expert in usability design, talks about this phenomenon in his book, The Design of Everyday Things (disclosure: at the time of this article, I have not read this book — yet).  One very common example involves doors.  How many times have you come across a door with a handle, leading you to think you need to pull it to open the door?  Yet when you try it, it turns out that you need to push, not pull it, to open.  It’s extremely frustrating, and it happens more often than you think — so often, in fact, that it even has a name: a Norman door.

If you don’t think good design isn’t a big deal, there have been documented cases where poorly designed interfaces resulted in a significant loss of life.  I did a Google search for “disasters resulting from bad design,” and the results were startling.

This subject is of particular interest to me, speaking as someone whose job revolves extensively around technical communication, technical writing, and front-end development.  In my line of work, design and layout are a big deal.  I have seen many examples on the job of horrible documentation and bad interfaces — and poor design was a major factor.  I mentioned in an earlier article that I came across illustrations in a company document that were completely useless.  Pictures may be worth a thousand words, but if they’re not properly used — and yes, there is a wrong way to use them — they can be worth exactly zero words.  Likewise, one of my current projects is working on how to make an internal corporate social network work for my department.  I’ve discovered that I have a love/hate relationship with it; while I have no problem with the concept, the execution leaves a lot to be desired.  One of the most basic questions I have with this system which it fails to answer — and which should only be answered by the interface design without having to look up instructions — is, “where am I supposed to begin?!?”

Interfaces exist in just about every facet of our lives, including, but not limited to, application front-ends.  Good sensible design must be involved in creating them.  More often than not, they’re just “thrown together” without any thought as to how they should be laid out and how they are to be used.  The consequences of poor design abound.  In the best of cases, such as with Norman doors, they are just annoying.  But in the worst cases, they can have disastrous and fatal results.

Blind spots

“All I want from tomorrow is to get it better than today…”
— Bruce Hornsby (or Huey Lewis — whomever you prefer)

“You’re only human; you’re allowed to make your share of mistakes…”
— Billy Joel

One of my favorite books is The Sword of Shannara by Terry Brooks.  For the benefit of those of you who’ve never read it (spoiler alert: if you’ve never read it and want to, I suggest you stop reading this paragraph and move to the next one, because what I’m about to say doesn’t get revealed until near the end of the book), the book involves a magic sword that has the ability to reveal truth.  When the sword’s magic is invoked, both the wielder and the recipient are forced to confront the truth.

There are many times that I wish I had a Sword of Shannara.  I can think of many people who would benefit from its magical power.  And I put myself at the top of that list.

An incident that occurred last night served to remind me of the blind spots that I have.  I don’t care to talk about the incident (the details aren’t important here, anyway), except that I felt as though I’d taken a big step backwards.  It’s not the first time that I’ve taken a step back, and as much as I try to avoid it, I suspect that it will likely not be the last.

We all have blind spots; it’s a part of being human.  More often than not, we aren’t aware that those blind spots are there — hey, there’s a reason why they’re called “blind” spots.  There is no magic sword to reveal those blind spots.  The best mirror we have for those blind spots is each other, in how we behave and react around one another.  If someone is smiling, laughing, or nodding his or her head around you, you’re probably doing something right.  If that person is frowning, yelling, or criticizing, then probably not.

As much as we try to do our best, inevitably, we will stumble somewhere down the line.  I admit that I’m probably still dwelling on it — I probably wouldn’t be writing this article, otherwise.  I’ll eventually get over it.  All we can do is to recognize our blind spots — once we recognize that they’re there — keep an open mind, learn from our mistakes, and keep moving forward.

The checklist manifesto

Some time ago, I came up with a new presentation idea that I tentatively titled “The magic of checklists.”  The idea is to demonstrate how checklists can improve tasks in any organization.  I have a number of ideas regarding this presentation, and I’ll expand upon them in a future ‘blog article.

As preparation for this idea, I assigned myself some homework.  My friend, Greg Moore, recommended a book to read: The Checklist Manifesto by Atul Gawande.  I borrowed a copy from the local library and started reading.

The book (which I’m still reading) is turning out to be an excellent read: so much so that I’m considering purchasing my own copy, instead of just relying on the one I borrowed from the library.  (This way, I can use a highlighter and scribble my own notes in the book.). Yes, it reinforces my ideas about using a checklist to improve upon workplace tasks.  But I’m also discovering that there is so much more.  Reading this book has enlightened me on numerous ideas that had never occurred to me.

The book hits upon numerous concepts, each of which is worth an entire presentation in their own right.  Among them: the importance of communication, organizational structure, teamwork, crew/team resource management, keeping an open mind, empowering a team, following instructions, making adjustments, and doing the right thing.  (Since I’m not yet finished with the book, there are likely a number of other concepts I haven’t mentioned that I haven’t yet come across.). When I first picked up the book, my initial thought was, “how much can there be about a simple checklist?”  I’ve since learned that a checklist — any checklist, no matter how small — is not simple.  And while a checklist is an important tool, it is also a big part of an even bigger process.  All the ideas I listed several sentences ago are all part of that process.

I’d like to relay a story I came upon in the book.  David Lee Roth of Van Halen was famously known for canceling concerts if his instructions for leaving a bowl of M&Ms with the brown ones removed in the dressing room were not followed.  Many people — myself included — decried him for these seemingly cockamamie instructions.  However, there was a method to his madness.  It turned out that this was a test.  If that instruction hadn’t been followed, then it was possible that another critical instruction — like, say, installing bracing to ensure the stage didn’t collapse — had not been followed.  (And before you think instructions like these can’t be missed, they can, and they have — sometimes, with disastrous consequences.) It goes to show that there is always more to the story.

Once I finish reading this book and can organize my thoughts, I’ll put out another article and another presentation (hopefully, coming soon to a SQL Saturday near you).  In the meantime, I highly recommend this book.  Maybe it’ll change your perspective the way it has changed mine.

Two books that influenced my life

“Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that.”
— Martin Luther King, Jr.

“Hold me now; it’s hard for me to say I’m sorry; I just want you to stay…”
— Chicago, “Hard to Say I’m Sorry”

I play the piano in a Catholic church every Sunday morning.  (I consider myself spiritual, not religious.  I have some thoughts regarding my own faith and beliefs; this might be another article subject for another time.)  This morning’s scripture and homily had to do with forgiveness.  As the good Father was going through his homily this morning, for whatever reason, two books that influenced my life suddenly came into my mind.  While these two books are only partially related to forgiveness, they nevertheless made me think about how life should be lived.  I credit these books with teaching me about life’s lessons and helping me grow.

The first book is How To Stop Worrying and Start Living by Dale Carnegie.  Although Dale Carnegie wrote this book back in 1948, all the principles about which he wrote are still applicable today.  Anyone who’s taken the Dale Carnegie training courses will recognize the principles outlined in the book (I, myself, have taken the Dale Carnegie course; if you have an opportunity to take the course, I recommend it highly).  In his book, he talks about how worry can make you unhappy, adversely affect your health, and cause stress in your life.  I’ll admit that I don’t always stick to his principles (I’m human, after all), but his principles make perfect sense, and they make for a good fallback whenever things aren’t going my way.

The second book is Tuesdays with Morrie by Mitch Albom.  When Mitch discovers his old mentor, Morrie, is dying from Lou Gehrig’s disease, he makes it a point to visit him each Tuesday (hence, the book’s title) until Morrie succumbs to the disease.  With each visit, Mitch’s old mentor teaches him about life’s lessons, leaving Mitch a changed man.  It’s a good read that provides a good perspective about what life is about.

These are two books that, I believe, can make the world a better place, and I recommend them highly.  Hopefully, they’ll influence you the way that they influenced me.