Want to get ahead? Don’t get comfortable

“Moving me down the highway, rolling me down the highway, moving ahead so life won’t pass me by…”
— Jim Croce, “I Got A Name”

“It’s important to be able to make mistakes.  If you don’t make mistakes, it means you’re not trying.”
— Wynton Marsalis

“Don’t look back.  Something might be gaining on you.”
— Satchel Paige

“Insanity is doing the same thing over and over again and expecting different results.”
— unknown

Late last Friday afternoon, our manager stopped by our workspace for a chat.  Some of it was just small talk, but he also wanted to give us a reminder of something, which is what I want to write about here.  I don’t remember his exact words, but the gist of what he said went something like this.

“We want you to develop personally and professionally,” he said (or something to that effect).  “The way you do that is to take on tasks that you know nothing about.  Volunteer to do things you wouldn’t typically volunteer.  If you see a support ticket, don’t worry about looking to see whether or not you know what it is or if you know how to handle it.  Just take the responsibility.  That’s how you develop.  If you want to move ahead, you need to step out of your comfort zone.”

Indeed, these are words to live by, and it isn’t the first time I’ve heard this.  I have had countless experiences where I’ve been told that I need to step out of my comfort zone in order to improve.  In my music experiences, especially in my ensemble performance experience, I’ve often been told by good music directors that I need to attempt playing challenging passages to get better.  When I first started doing CrossFit, one question we were asked was, “would you rather be comfortable or uncomfortable?”  The point was that in order to get better, some discomfort would be involved.  I also remember one of the points of emphasis back when I took a Dale Carnegie course; each week would involve stepping a little more out of our comfort zone.  We would do this gradually each week until we reached a point where we had drastically improved from where we had started.

Falling into a rut is common, and while it happens in all different facets of life, it is especially easy to do in the workplace.  Sometimes, the work environment can slow down, and you have a tendency to fall into a routine.  I’ve had this happen more often than I want to admit, and more often than not, I’m not even aware that I’m doing it.  Every once in a while, a pep talk or some kind of a jolt (such as a kick in the butt — whether it’s from someone else or myself) reminds me that I need to branch out and try new things if I want to get (and stay) ahead.  I am well-aware that I need to step out of my comfort zone to get ahead, but I am also the first to admit that I will sometimes forget about this, myself.

Too often, I see people who fall into ruts themselves, and who have no desire to step out of their comfort zones.  As much as I try to tell these people to at least try to do something about it, they insist on remaining where they are.  These people strive for mediocrity, which is a major pet peeve of mine, and something for which I have no tolerance or respect.  People want to remain in their “happy place,” but what I don’t understand is how these same expect to get ahead, yet refuse to leave their comfort zones to do it.  These people will be stuck in a rut forever, and they have no right to complain about it.

Everyone has a dream, or at least some kind of goal they want to achieve.  The fact is, if you want to reach that goal, or at least take steps toward it (whether you reach it or not), you need to get uncomfortable to do it.

Advertisements

Want to learn about a topic? Try writing about it

Every now and then, I’ll peruse the forums on SSC.  In addition to people answering questions about SQL Server, there also tends to be some banter, which is probably not unusual in many forums of this nature.  One of the comments I’ve seen time and again is something like, “I learn more about subjects by answering people’s comments on these forums.”

There is more truth to this statement than people realize.  In my experience in writing about technology, I often find that I end up learning about the technology about which I’m writing — sometimes to the point of becoming a subject matter expert.

Several years ago, I taught part-time at a local business school (roughly equivalent to community college level).  I taught primarily general mathematics and a few computer classes.  I was once asked to fill in for another instructor who taught statistics.  My problem: I didn’t know much about statistics.  So, I read up on it (along with the syllabus that I would be teaching that day).  I wanted to at least be able to sound like I knew what I was talking about.  As it turned out, by teaching that class, I actually learned something about it.  The students were not the only ones who got an education that day.

The other day, I began writing a draft article regarding a subject about which I’d like to learn more: BI (edit: the now-finished article can be seen here.).  I’ve dabbled in BI a little bit; I worked a previous job where I was asked to perform some data analysis (which is how I learned about cubes and pivot tables), and I took a course in decision-support systems in grad school.  I’m seeing more SQL Saturday presentations about BI; indeed, there are even SQL Saturday conferences dedicated to BI topics (usually indicated by the words “BI Edition”).  It is a topic about which I do have some interest, and it’s something about which I’d like to learn more.

My friend, Paresh Motiwala, who was one of the organizers for SQL Saturday Boston BI Edition a while back, encouraged me to apply to speak at the event.  I said to him at the time, “the only thing I know about BI is how to spell it!”  (His response: “Hey, you know how to spell SQL!”)  On hindsight, I probably should have applied; it turns out that even BI Edition conferences accept professional development topics, under which nearly all of my presentations (so far) are categorized.

So if I claim to know so little about BI, why did I decide to start writing about it?  Well, I’m trying to learn about it, and I’d like to pass along what I learn.  But, I want to place a greater emphasis on the first part of that statement: I’m trying to learn about it.  Writing about it makes me learn something about it a little more in-depth.  And by doing so, I discover that I have a better grasp of the topic.

Hopefully, relatively soon, you’ll see an article from me about BI.  Hopefully, I’ll have learned enough writing about it that you’ll be able to learn something from me.  And hopefully, I’ll have demonstrated that I’m learning something new, and improving myself in the process.

If you want to learn something new, try teaching it or writing about it.  You’ll be surprised how much you, yourself, learn in the process.

Always ask someone to test your product

This morning, one of my colleagues posted this message to our Slack channel:

please ask someone else to test your code before pushing it

It brought to mind an important thought (and more ‘blog article fodder): any time you produce something, regardless of what it is — a software application, documentation, a presentation, a music composition, a dish you cooked, etc. — always ask someone else to test it out before you send it out for public consumption.

That testing could take several different forms — it could be an end user trying your application, somebody reading your document, listening to your presentation or your music, trying your dish, and so on.  Testing results in feedback, which results in improvements to your product.

Whenever we produce something, we have our own vision — and our own biases — as to how the product should come out.  We expect our products to be perfect as resulting from our own visions, and we expect (and demand) that the consumers adhere to our visions and how we expect the products to be viewed or interpreted.

Unfortunately, we are blinded by our biases.  The world does not share our same visions.  People who use our products will never, ever, perfectly interpret how our products should be consumed.  More often than not, we’ll find that what we produce will be used or interpreted in ways that never occurred to us.

Even in my own workplace, I write and edit a lot of online documentation.  Much of what I write comes from other sources, often about topics about which I know little (or, sometimes, nothing).  I try to write material based on the information I have at hand.  Very often, I come across gaps that need to be filled.  I’ll do my best to ask original authors what was intended, or to dig for information to fill those gaps.  But in absence of those resources, I end up making assumptions and using my own intuition to fill in the blanks.  Those assumptions might not necessarily be correct, and what I write could end up being different from what was originally intended.  It is for this reason why I am constantly asking my colleagues, “take a look at what I wrote.  I want to make sure what I wrote is accurate.”

In a manner of speaking, creating products is a form of communication — in that what we produce results from an idea in our heads, and the end users — the consumers — are the ones “listening” to the communication — in this case, the end product.  If you are familiar with the basic communication model, a sender creates a message, a receiver interprets the message, and the receiver reacts to the message in the form of feedback.  Producing a products works in exactly the same way — a producer creates a product, a consumer uses the product, and the consumer reacts to the product, generating feedback.  In between the sender and the receiver is “noise” that degrades the message or the product (it is not literally noise — the “noise” can simply be the fact that the sender’s and receiver’s interpretation of the message are not one and the same).

So, any time you create some kind of product, always ask someone else to try it out.  You’ll find that the person’s feedback will result in tweaks to your product.  And you will end up with a better product.

The art of talking technology to non-technical people

“Eschew obfuscation.”
— unknown

Let’s discuss how to tie a tie.  First, you take the tie and put it around your neck, making sure that it lies within your shirt collar.  Make sure the seam is facing toward your body, and the wider end of the tie hangs down roughly two-thirds of the length of the tie.  In other words, the wider end should hang down farther than the narrower end.  Take the larger end over the narrower end.  Wrap it around once so that it forms a knot.  Take the larger end and put it through the knot you created.  Once that’s done, pull it tight.  Adjust your tie by pulling on the narrow end, which should now be behind the wide end.  Your tie should now appear neat and flush against your shirt.

Raise your hand if you actually followed the above paragraph.  And when I say “followed,” I mean that you read (as opposed to skimmed) through the entire paragraph, following every step and not falling asleep while reading it.  I’ll bet that not a lot of hands are up.

Yet this is exactly the way that so many technologists tend to write when they are asked to convey a set of instructions.  They will write (or talk) in lengthy detail, explaining every little thing and believing that the reader (or listener) is soaking up every detail and is in rapt fascination of the subject, holding on to every single word.

Oh, if only that was true.  If that was the case, we wouldn’t have technical writers.

I wrote a couple of articles a while back about tech writing frustration and why design matters.  They provide some thoughts that are directly related to this article, so I suggest you read them before continuing with this article.  If you haven’t read them yet, check them out.  Go ahead.  I’ll wait.

At this point, I’m trusting that you understand at least some of the principles behind good writing and design.  (If you don’t, and you didn’t read those previous articles, shame on you.)  Many, if not all, of them come into play when talking about talking to a non-technical audience.

Giving (and taking) instructions is hard

Let’s talk about that initial tie instruction paragraph for a moment.

This is a demo I use in two of my presentations.  I ask for a volunteer, preferably someone who does not know how to tie a tie.  I hand him or her a tie, and give that person simple instructions: “put it on.”  Of course, if the person doesn’t know how to put on a tie, he or she is likely to struggle doing so.

At that point, I get the rest of the audience involved.  My instructions to the rest of the group: “you folks are the help desk.  Tell this person how to put on the tie!”

I’ve done this demo to varying degrees of success.  In some cases, the audience does a very good job of explaining how to tie the tie, and it ends up looking pretty good.  I’ve also seen demos where my volunteer looks like he or she tried to tie the tie using only one hand, two fingers, and blindfolded.

The point of this exercise is to demonstrate that giving and receiving direction is difficult.  A lot of people mock tech writers, thinking that writing step-by-step instructions is no big deal.  But after putting people through this exercise, they usually end up singing a different tune.

Be patient!

When you’re talking to a non-technical audience, patience is a vital virtue.  People can be intimidated by technology, and lack of patience on your part will only do more to add to their discomfort.  Bear in mind that your audience is not as tech-savvy as you are, and will likely not have a grasp of technological concepts.

Any time you try to do a task you’ve never done before, how do you feel?  Most likely, you’re going to be at least a little nervous.  These people are likely to feel the same way.  Telling them to “click Enter” might as well be telling them to hit the gas pedal while they’re blindfolded.

Speaking of clicking Enter, don’t take for granted that people might not know what some technologies are.  I’ve heard stories of people using mice to different degrees, including using them as foot pedals and holding them up to the screen.  (And by the way, I’m sure you’ve heard the joke about not being able to find the “any” key.  I can tell you from firsthand experience that those are not jokes — the stories are true!)

What you see may not be what the audience sees

I’m sure you’ve seen the classic image below.

rubingestalt

What did you see first: a vase or two faces?  Perspectives matter, and it happens all the time when trying to explain technical concepts.  Don’t assume that your audience sees the same thing that you are.  Even if you and your audience are looking at the same screen, what you and your audience see might not be the same thing.

Having said that…

A picture is worth a thousand words.

Very early in my professional career, I was tasked with writing a document for the nighttime support staff, explaining how to support a WORM drive.  When a customer requested data from an optical platter that was not in the drive, the user needed to insert the new platter into the drive.  I could have written an instruction saying that the A side had to be up, with the A label on the left edge, and the disk slide facing away from you as you put it in the drive.

Instead, I opened my very primitive paint program and drew something similar to this:

disk

Suddenly, the instructions were clear.  The document was successful, and the operators were able to follow it to perfection.

However, be careful — there is a wrong way to use illustrations!  Imagine, for example, that you’re trying to find a Little Caesar’s Pizza or a Home Depot.  You find a site that has a map.  The problem is, the map is an image that’s zoomed in (with no way to expand the map).  The image looks like this:

map

Tell me, on what street are these places?  For that matter, in what city, state, or even country are these located?  There’s no way to tell, because there is absolutely no point of reference or context to this illustration.  A picture might be worth a thousand words, but if you’re not careful, it could be worth exactly zero words.

Use analogies

I once sat in on a SQL Saturday presentation by Thomas Grohser where he was talking about SQL data storage systems and data access.  I’ll admit that I had a hard time following some of what he was saying, until he gave the following analogy:

“Imagine you get on an elevator with ten people.  Each person presses a different button.  Now imagine that the elevator has to go to every floor in the order that the buttons were pushed!

Suddenly, Thomas’s concept was crystal clear!

Another time, I was speaking to a co-worker who had tried to explain to someone that she was trying to store more data on a disk than there was space on the disk.  (This person did not understand that data takes up disk space.)  I told him, “you should’ve said that you can’t put ten pounds of stuff* into a five pound bag!”

(*Okay, I didn’t say “stuff!”)

The moral of the story is that analogies are highly effective in communicating concepts.  If you can effectively explain a concept using an analogy (note: make sure the analogy you’re using is business-appropriate), then go ahead and do so.

KISS!  KISS!  KISS!!!

No, I don’t mean hanging out with your sweetheart.

Make sure you follow the KISS principle: KEEP IT SIMPLE, STUPID!

Technical instructions need to be kept simple.  A lot of technologists don’t understand that reading is work!  It takes work to read and comprehend a paragraph.  What if a set of instructions needs to be understood quickly?  If a person needs to take a minute to figure out what is being said, that’s a minute that was just wasted.

Generally, the rule of thumb I use is, if it takes more than a few seconds for a reader to understand my instruction, then my instruction has failed.  Don’t make the reader have to work.

Realize that this will not happen overnight

Now that I’ve gone through some of the suggestions for talking to non-technical people, understand that not everyone has the ability to convey technical information in a manner that can be understood, and being able to do so won’t happen overnight.  Like everything else, it takes time and practice to get that skill down.

In any case, hopefully, these tips will help you become a better technical communicator.  In the long run, this ability will enhance your skill set — not just as a communicator, but as a technologist as well.

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.

“I lost my job. Now what?!?”

Before any of my friends panic, no, I didn’t actually lose my job (at least not at the time of this article); this is just what I’m using for the title.

Having said that, here’s a little background for what prompted me to write this. A few weeks ago, I saw a Facebook post from a friend of mine. She was (understandably) flustered because her husband had lost his job.  I wanted to help them (and others) out, so I began jotting down my thoughts for this article.  Ironically, I had a Facebook “on this day” memory come up on the very same day that I started jotting down my notes for this article; it turned out that on that day four years ago, I was laid off from a job as well.

Losing your job is always a scary proposition. Very few people (that I know of) wants to be unemployed.  There’s a great deal of uncertainty.  Questions enter your mind; among others: “how long will I be out of work?”  “How will I pay the bills?”  “How will I get by?”

Having been there and done that, I empathize with people who find themselves jobless.  For those of you who find themselves in such a situation, here are some tidbits that helped me through these tough times.

  • Above everything else, control your emotions.  When you lose your job, your emotions run wild.  Most likely, you (understandably) get scared, depressed, angry, frustrated, and so on.  The worst thing you can do is lose control of yourself.  If you need to do so, find a safe way to blow off steam and keep your feelings in check.  It isn’t healthy to keep those emotions bottled up, but at the same time, it is absolutely critical that you keep your head on your shoulders.  Find a healthy way to get those feelings out of your system, but don’t let those feelings control you.
  • Keep a positive attitude.  It is very easy to get down on yourself when you lose a job.  Strangely, the last time I lost my job, I actually felt invigorated.  I looked at it as an opportunity.  It wasn’t so much that I’d lost my employment as much as I was being offered a chance to try something new.  I wrote a while back that a positive attitude can be a powerful thing.  Rather than dwelling in what was, focus on what might be.
  • Take advantage of your free time.  A friend of mine who’d lost his job at one point told me that he took advantage of his suddenly-acquired free time to spend time with his family, play golf, and do things he didn’t have time to do because he was at work.  While he did focus efforts on his job hunt, he also made it a point to balance his time between searching for a job and having fun — which brings me to another thought…
  • Looking for a job is a full-time job.  Back in the good-old “answering help wanted newspaper ad” days, quantity was quality (there might be some recruiters who disagree with me on this, but I digress).  I am, admittedly, old school, so a part of me still subscribes to this mindset.  There were job hunts where I averaged about ten applications a day.  There’s also doing your homework — researching companies and potential employers, sizing them (and yourself — again, more on that in a minute) up, getting addresses, making phone calls, polishing your resume and your cover letters, and so on.  That makes for a lot of time and effort, and it will tire you out.  Make the time for your job hunt endeavors — but don’t forget to balance your life as well.
  • Find something to hold you over.  No, flipping burgers isn’t sexy, but it’s a source of income.  Even minimum wage is better than, say, zero (and it might also be better than unemployment benefits, which, in my experience, usually pays squat).  There is no shame in taking a temp job to hold you over until you land on your feet again.
  • Get involved, and keep yourself busy.  Number one, it’ll get your mind off your situation.  Number two, it’s a chance for you to network (again, I’ll expand on that in a bit).  Number three, you might learn something new that would make you marketable.  For more thoughts on getting involved, check out my article on getting involved with user groups, as well as an article I wrote about using your skill set for speaking at conferences.
  • Be honest with yourself.  When I started getting down on myself about my job situation, I asked myself a few questions, including: “where do my strengths lie,” “what am I capable of doing,” and “what do I really want to do?”  I identified my own skill sets and my interests; this, in turn, helped me identify positions for which I was qualified, as well as developing my own professional persona that helped me with interview skills.
  • Be creative.  As part of my job search, as well as a tool for networking, I created business cards for myself.  However, these were no ordinary business cards.  I remembered a scene in Mr. Baseball where Tom Selleck’s character learned that Japanese businessmen networked by exchanging business cards.  He gave them his baseball card.  That got me thinking: “Business card…  baseball card…” and I put the two together.  The result is what you see in the picture below.
    raysbizcardpic
    My networking business card

    The picture is a souvenir photo I got on a trip to Cooperstown (they dressed you up in the uniform of your choice and took your picture with a stadium backdrop).  I took that photo and made it into the business card you see above.  The back side has my contact information, and inside (it’s a folded card) contains a mini-resume with my career information.  I always get great reactions from people when I hand these out; someone even once said to me, “if I was in a position to hire, I’d hire you right now just because of this card!”  People will remember you, and it makes a great conversation piece.

    You don’t have to come up with a baseball-business card (hey, my idea, darn it!), but by all means, tap into your creativity to get yourself noticed!

  • Network, network, network!  Did I mention that you should network?  These days, networking is probably the best way to find a job.  Someone who knows of a job opening can probably tell you about it long before the open position becomes public knowledge.  That extra time could very well be your foot in the door.
  • Take advantage of available resources.  In this day and age of communication, you have no excuse not to make use of social media.  LinkedIn is specifically designed for professionals, and many online resources (including and especially job-hunt and networking resources) ask if you have a LinkedIn account.  If you’re looking, you can’t afford not to have an account.  While Facebook isn’t specifically geared toward professional networking, it is still another resource you can tap.
  • Don’t limit yourself.  Would you consider moving or taking a job outside your geographic area?  Would you consider working from home?  What about a different line of work?  Would you work part-time, odd hours, or a contract position?  If you’re in a jobless situation, you may very well need to keep your options open.

These are just some of my thoughts regarding surviving a jobless situation.  Did I miss anything, or do you disagree with any of my thoughts?  Feel free to comment below.