Soft Skills: Controlling your career

I came across this article on SSC by David Poole titled “Soft Skills: Controlling your career.” It spoke to me in a big way, as it pretty much sums up my career in a nutshell. It’s a good read, and I encourage you to go click the link.

I’ve said before that I’ve made an entire career out of adapting to my environment. Soft skills are the key to being able to adapt.

All of my SQL Saturday presentations revolve around soft skills. I’ve been asked before about why I speak at SQL Saturday, when my talks don’t talk about data topics. The fact is, soft skills are important. You can know everything there is to know about data storage systems, recursive structures, or nuclear physics, but often, soft skills are ultimately what sets you apart.

Advertisements

Stop treating technical writing like a second-class citizen

File this under another technical writing frustration.

Imagine that you are an application developer. You finish an app for a client that you send for review. The app is clearly labeled as a “testing version,” and includes source code (yes, I know this last part doesn’t happen, but just humor me for a bit). You are meticulous with your updates, keeping track of version control and changes. You ask the client to review it and get back to you. You move on to work on other projects, forgetting about the request. A few weeks later, you remember the project, and realize that you hadn’t heard from the client. You contact them to follow up, and are chagrined to learn that not only are they using your test version app in production, they also changed the source code for what they need.

Sounds outrageous, right?

Now, substitute the following words and phrases: “technical writer” for “application developer,” “document” for “app,” “draft” for “testing version,” and “MS Word” for “source code.” Welcome to my world.

This is an actual workplace scenario that happened to me a while back, and I was reminded of this recently when the same client asked me for an MS Word version of a document (that I had sent as a PDF — I was never, ever going to send them an MS Word doc again) so they could make changes. I refused, and I told them why.

The client in question had taken my Word document — the one that I had asked them to review — and I will add that I had DRAFT stamps all over it — and were using it in their production environment. Not only that, they had made changes to it for their purposes.

Well, I found and incorporated their changes, removed the DRAFT stamps (they were obviously okay with the document), and slapped a version number on it.

I also told myself that I was never sending them a Word document ever again. They were only getting PDFs from me.

I’ll be honest. What the client did absolutely pissed me off. By “changing the document for their needs,” they completely compromised and undermined my work, they blatantly stepped on my toes, and they completely disrespected what I do.

Most of the clients I work with aren’t like this, which is why I usually don’t have a problem sending a Word document (with DRAFT stamps) out for review. Thankfully, the scenario I just described is, in my environment, the exception, not the rule. Sadly, however, there are still too many people who hold this attitude that documentation is just a side item, and treat it like a second-class citizen.

This is one of the things that drives me to do SQL Saturday talks. This is why I do my presentations. This is why I rant about poor treatment of documentation. And this is why I actively tried to leave a job.

I’ve said this time and again. Document development needs to be treated in the same way as software development. The life cycle, including version control, is no different. Not doing so undermines what documentation is. It’s a critical function in application and professional development. And as someone who has had experience in both application and documentation development, I demand: stop treating documentation like a second-class citizen.

First drafts are ugly

“The secret to life is editing. Write that down. Okay, now cross it out.”

William Safire, 1990 Syracuse University commencement speech

“No thinking – that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

William Forrester (Sean Connery), Finding Forrester

“Just do it.”

Nike

I will confess that this article is a reminder to myself as much as anything else.

Raise your hand if you’re a writer, and whatever it is you’re writing has to be perfect the first time around. Yeah, me too.

How many times have you tried writing something, but in doing so, you hit a wall (a.k.a. writer’s block) because you don’t quite know how to put something in writing? Or how often have you written a first draft, only to take a second look at it a second time and say, “what a piece of s**t!”

(And speaking as someone with application development experience, this happens with writing code, too. Don’t think that this is limited to just documentation. This is yet another example of how technical writing and application development are related.)

Someone (I don’t know whom) once said, “one of the stupidest phrases ever coined is, ‘get it right the first time.’ It’s almost never done right the first time!” In all likelihood, you need to go through several iterations — review, editing, rewriting, etc. — before a draft is ready for public consumption. It’s called a “draft” for a reason.

The fact is, nobody has to see what you write the first time around. If you’re trying to get started on a document, just write what’s on your mind, and worry about making it look nice later.

Don’t tell me how to build the clock! Just tell me what time it is!

This article’s title comes from something that a former manager used to tell me all the time — often enough that he seemed very fond of saying it. Nevertheless, it’s an important message. This is not the first time I’ve written about this issue, but it’s something that occurs all too frequently. It is a problem in technical and business communication, and the issue is something that bears repeating.

I was reminded of this during our daily status update meeting this morning. The gist of this regularly scheduled meeting is that everyone has a short time — usually no more than a minute, if that — to provide a brief update of what they have going on. The key word here is brief.

One person proceeded to go into detail about some of the projects he had going (he has a tendency to do so). He’s been pretty good about keeping his updates short and to the point, but he wasn’t always like that. It took several long meetings and complaints to the manager to get him to tone it down.

For whatever reason, this morning, he reverted back to form. He started getting into details about his projects that, while important for the projects themselves, were unnecessary for status updates. It got to the point that I stopped listening to what he was saying and pretty much just zoned him out. I don’t know how long he took, but I’ll guess that he took three times longer than anyone else. Or at least it seemed that way.

This is something that everyone does (yes, I admit to doing it, too — ironically, even this very article may be too long). And it is a big problem in communication.

A part of the issue stems from human nature. We all have a limited attention span. The length of that attention span varies, but for the purposes of this discussion, let’s assume that it’s short — say, no more than a minute (sometimes, that might even be too long). If we’re communicating something, we need to make sure that it’s short and simple — and it had damn well better be efficient.

This is why people in roles such as technical, business, UX/UI, media, and marketing communication have jobs. They are in the business of taking large amounts of information and boiling it down into a format that most people can understand.

Whenever I’m writing a user or step-by-step guide, I follow a general rule of thumb: if an instruction cannot be understood within a few seconds, it has failed. That’s when I go back and rewrite the instruction.

Most of the time, people don’t want — or don’t need — or don’t care about — details. Unfortunately, too many people trying to communicate ideas don’t understand this (and worse, they often don’t care). As a result, horrible documentation (or, in some cases, absence of) is pervasive.

Too many people don’t understand that reading is work. It takes effort to read and comprehend documentation. One of my big pet peeves is any time someone tells me, “it’s right there in the documentation,” yet when I look at it, the information I need is buried someplace where I have to fight through the noise of other irrelevant text to find it.

This issue is the basic tenet of my presentation about talking the language of technology. People don’t want detail. They just want the information they need. If they need more information, they’ll look for it.

Good communication makes it easy for a recipient to quickly get whatever information (s)he needs. Don’t make someone have to work to understand communication. Don’t tell someone how to build a clock. Just say what time it is.

Want to get started with speaking? Try your local user group!

Usually around this time of the month — a week before (my user group‘s) monthly meeting — I’d be posting an announcement about our upcoming meeting.

I still will do so — as soon as I find out who’s speaking.

As I write this, I’m guessing that our speaker will be Greg Moore, but I’m not completely sure. One way or another, I’ll post an announcement later today.

Which brings me to the subject of today’s article.

Have you ever wanted to speak publically or do presentations? Consider doing so at a local user group. It’s the perfect place to do so!

There are many advantages about speaking at a local user group. If you’re a first-time speaker, it’s an opportunity to practice your presentation skills. If you’ve been a part of a user group for some time, you can do so in front of a familiar audience. If it’s your first time at a particular user group, it can serve as an introduction to the group. Either way, it’s a wonderful experience that is generally less pressure than presenting for the first time at, say, a SQL Saturday.

I’ve told this story plenty of times. In 2015, I came up with a presentation idea that I first presented at my user group. I had been involved with this user group for a while, I was among friends, and I felt comfortable about presenting to this group. Ever since that initial experience, I’ve spoken at several SQL Saturdays, and this coming November, I will be doing that same presentation for PASS Summit! My experience with speaking has also passively helped my career in numerous ways, including (but not limited to) expanding my network and improving my own professional self-confidence. I’ve come a long way since that initial start!

And if you’re still not completely comfortable with speaking, but still have an interest in doing so, there are other resources available to get you started. Look into groups or courses such as Toastmasters or Dale Carnegie. (Disclosure: I have friends who are involved with Toastmasters, and I, myself, am a Dale Carnegie grad.)

If you’re interested in speaking, consider starting at your local user group. You never know where a small start could lead!

P.S. if you’d like to speak for our user group, feel free to drop us a line!

Coming up with presentation ideas

As a followup to yesterday’s article, I thought it might be fitting to talk about presentation ideas.

Despite the fact that I speak regularly at SQL Saturday, none of my presentations (up to this point) have anything to do with SQL Server or even anything data-related. My topics revolve mostly around documentation and communication. So how do I go about coming up with presentation topics?

To answer this, I suppose I should go back to the beginning, and (re-)tell the tale as to how I got involved.

Back when I was primarily a SQL Saturday attendee, I knew I wanted to get involved. The question was, how? At the time, I looked around at the people attending the event, and I said to myself, “these people probably know more about SQL Server than I do. What can I present that these people would find interesting?”

In the early days of our user group (I was one of the original co-founders and members), we sought out speakers to present. I thought about data-related topics. I even took a turn one meeting where we were encouraged to bring up SQL-related issues as discussion topics. But when it came to ideas for data-related topics, I kept coming up empty.

I thought about a time at one of my jobs where I became an accidental customer service analyst. As a developer, I was not allowed to speak with end-users, but one day, I received a phone call from a user. It turned out that he had gotten my number from someone who was not supposed to give out my number. I was able to walk him through and satisfactorily resolve his issue. In fact, I did such a good job with it that, from that point forward, I became one of the few developer/analysts who was allowed to talk to customers. It made me realize that I had a knack of being able to discuss technology with end-users without being condescending to them.

During one user group meeting, I jotted some notes down. By the end of the meeting, I had come up with enough material for a presentation. I ran my idea past my fellow user group attendees, all of whom said, “that would make a great presentation!”

I worked on the presentation and presented it at a user group meeting.

Four years later, I will be giving that same presentation at PASS Summit! I’ve come a long way!

While that ended up being a good presentation, I’ve tried not to rest on my laurels. I still try to come up with new presentation ideas. I’ve come up with several since then, and I’m still trying to come up with more.

When I think about presentation ideas, I generally keep these thoughts in mind.

  • Is it a topic that attendees will find interesting?
  • Is it unique?
  • Is it something about which I’m knowledgeable, and I feel comfortable talking about?
  • Is it something I can present within an hour? And do I need to cut it back to an hour, or do I need to fill it in to an hour?

I still remember a piece of advice that Chris Bell, a DBA and fellow SQL Saturday speaker, once told me: “an expert is someone who knows something that you don’t.” That was profound advice, and I’ve never forgotten it. So far, it’s served me well in my speaking endeavors.

So if you struggle to come up with presentation ideas (like I do!), hopefully this will help you get the ball rolling. I look forward to seeing your presentation soon!

What do you do for an encore?

“The reward for work well done is the opportunity to do more.”

Jonas Salk

As a Syracuse alumnus and sports fan, I’m looking forward to this upcoming football season. Orange fans are excited for this season after last season’s 10-3 breakthrough, the first time that Syracuse has won ten football games in a season since 2001. Season ticket sales are up this year (and I’m happy to say that I am one of those season ticket holders). I’m looking forward to attending games this season!

In a recent interview, Syracuse football coach Dino Babers said that getting the team to break through with a great season (after years of mediocre ones) was the “easy” part. The harder part, he said, is maintaining it. As he often puts it, he wants to be “consistently good, not occasionally great.” Breaking through is a great thing, but after you’ve done so, how do you maintain that success?

I thought about this recently in regard to SQL Saturday presentations. One of my friends and fellow speakers gives a great presentation, but I do have one concern about it: it’s only one presentation. I’m not sure how long he’ll be speaking at SQL Saturday if he keeps submitting the same presentation again and again. I’d like to see him do more presentations, and I hope to see him at more events. Yes, he has a good presentation, but what does he do for an encore?

It’s for that reason why I look for more presentation ideas. As of this article, I have a brand new presentation idea that, right now, only exists in the back of my head. I listed it so that I’d remember to work on it. If I come up with what might potentially be a good presentation idea, I’ll set the idea aside so I can work on it. I want to make sure that I have fresh ideas. I love speaking at SQL Saturday, and I’ve been doing it for four years. I want to keep doing so. To do that, I want to make sure I have new material. While I do occasionally recycle my presentations (it’s unavoidable), I try not to resubmit the same presentations over and over to events.

For those of you who are looking to get your career off the ground, the same holds true for career endeavors. A great job that you did on a single project will often be enough to get you in the door. But once you’re in the door, how do you stay there? Breaking through on a project is the easy part; the harder part is sustaining that success. Once you’ve achieved something, can you do it again? And again?

If you are able to sustain success, you develop a reputation as someone who can deliver. That’s how you build a career. Achievements are great, but once you attain them, what do you do for an encore?