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?

Advertisements

Don’t discount old documents

For those of you who have application development experience, how many times have you come across old code that you’d written and said to yourself, “what the F was I thinking?!?”

As someone with development experience, it’s happened to me more often than I can count. And as someone with tech writing experience, I can tell you that it applies to documentation as well.

As a technical writer, I’m often tasked with rewriting old documents that are out-of-date or no longer applicable. In the old days (i.e. before I knew better), I would essentially overwrite old documentation with the new, and often deleted the old. Now that I have more experience under my belt, I know now that that was the absolute worst practice that I could have done.

For starters, I used to have the mindset that the information in old documents was no longer relevant. The processes have changed, I used to tell myself. Why should I keep these documents around?

If you have this mindset, as I once did, I urge you to purge it. It is a poisonous attitude to have. As it turns out, old documents are extremely relevant, even if their information is out of date. Old documents are important for reference. I’ve often found myself referring back to previous versions when rewriting documentation.

I recently wound up a project that involved a rewrite of an application document. The application had been rebuilt from the ground up, and the documentation had to be rewritten to accommodate it. While documenting the testbed, I came across a number of functions that, with the limited testing dataset, didn’t seem to do anything. I went to the predecessor documentation and found what I was looking for.

Old documents are often also important in answering a simple question: why? As in, why was such-and-such process designed this way? What was this originally supposed to do? Why was this function changed? Many of these cannot be answered just by looking at application code; often, the answers are found in old documents.

These days, I make it a point to not overwrite old documentation. I back up old documents and either rename them or put them into an archive folder. I haven’t yet implemented a version control system to archive documents (we use Git in my office). If anyone makes use of version control systems such as Vault, Git, Subversion, or MS Azure DevOps (formerly TFS) to maintain documentation versions, feel free to mention it in the comments.

So if you are rewriting documentation, make sure you set aside the previous versions. You never know when you’ll need them again.

Ransomware and DevOps

Another post by Steve Jones that I think is really important…

Voice of the DBA

Ransomware.

A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.

This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped…

View original post 356 more words

Companies that adapt and survive

I’m working from home today. As is typical when I work from home, I’m sitting in my living room with my laptop in front of me and the TV on (and, every once in a while, Bernard — our tuxedo cat — curled up on the recliner between my legs). If there’s one thing I’ve learned about working from home, there’s nothing good on TV in the middle of the day on a weekday. To steal a line from Bruce Springsteen, how many channels and nothing on? Thankfully, as I write this, Wimbledon is on ESPN, and Roger Federer is putting on a clinic. (He lost the first set, but since then, has been absolutely dominant.)

Well, obviously, as you might have judged by my article title, I’m not here to talk about TV. So what does TV have to do with this article?

A little while ago, I saw an ad for Western Union. For whatever reason, I started thinking about Western Union’s history: it started out as a telegraph and telegram company. It made me think: in this day and age of internet, social media, and nearly instantaneous mass communication, how has Western Union managed to remain relevant?

I looked up Western Union on Wikipedia. I didn’t take the time to read the entire article, but to make a long story short: Western Union adapted with the times. It stopped delivering telegrams a long time ago, but has since become involved in internet communications, as well as financial services. As their ads bill themselves, they’re “the fastest way to send money.”

Western Union still exists because they changed and adapted with the times.

They’re not the only ones. A number of companies continue to exist because they managed to change with the times. Off the top of my head, The New York Times has de-emphasized their print paper and is largely an online news source. While Apple still produces personal computers, they became much more successful after diversifying and becoming a provider of products such as smartphones and music players, among other things. There are countless other examples as well; at the moment, these are the ones that stand out in my mind.

Even from a personal standpoint — I’ve written about this many times before — I’ve practically made an entire career out of adapting to my environment. Even in one of my very first ‘blog articles, I wrote about how change is inevitable.

I’ve said it before, but it bears repeating. Change will happen. The question is, how will you adapt to it? In order to survive, you need to be able to roll with the punches. The environment around you will change. What will you do to adapt?

When you make it hard for your customers to respond

This morning, I had an issue with my LinkedIn account. I was trying to reply to a message, and I kept getting “Send failed.” That was all I got — there were no error codes, additional information, or symptoms. I poked around LinkedIn’s Help section, and came across this page for dealing with messaging problems. I didn’t go as far as to clear my cache, but I did log out and back in, and I tried it in a different browser, all to no avail. In the middle of contacting LinkedIn’s support, the problem mysteriously “fixed itself.” If you work in tech, I don’t have to tell you how frustrating it is for an issue to mysteriously “fix itself.”

However, the issue I had, in and of itself, is not why I’m writing this article. When I heard back from LinkedIn, I got a message saying “go to this page” (the one I’d already found) and use that to troubleshoot. In response, it displayed the interface you see above. As you can see, they only gave me two options: “yes, I’m good,” and “no, I still need help.” The problem was, my response was, neither. No, I didn’t need help at that point, but I also wasn’t completely good, either. I wanted to inform them what had happened in case they wanted to investigate it further. But they did not give me that option. Between those two options, I clicked “yes, I’m good,” which immediately closed the case; I had absolutely no recourse to add more to it. I looked around for ways to send feedback, but I did not find any good way to do it. Replying to the email resulted in a response saying “you responded to an unmonitored mailbox.” The more I looked for a feedback mechanism, the more frustrated I got. The issue quickly went from “I’m reporting a technical issue” to “you guys need to fix your UI/UX.”

I’ve written before about how critical it is to get feedback, and how design can be a big deal. As much as I like LinkedIn as a business networking tool, I felt that LinkedIn fell short on both of these facets.

Let me start with the UX/UI design. I strongly felt that only those two options, especially if answering “yes” automatically closed the case, was a very poor design. As many people will tell you, the answer often isn’t simply “yes” or “no.” (One of the long-standing jokes among DBAs is that the standard DBA answer is, “it depends.”) And even after I clicked one of those buttons (in this case, I clicked “yes”), the interface was confusing. I was brought to a page that said “click to enter more information” (or something like that). The problem was, click where? None of the “links” allowed me to enter anything else, and there was no clearly logical eye path for me to follow. I had no idea what I was supposed to do once I got to that page. I kept clicking different links, trying to leave feedback. By the time I found a link, I wasn’t even sure that I was replying to my original query. I had no idea to what — or even where — I was responding.

I’ve said time and again that if you’re a technical writer — or a UX/UI developer — you don’t want to make your reader or end user work. Reading is work. Making your end user work is a sign of poor design.

Second, this experience made me question just how seriously LinkedIn takes feedback. True, nobody wants to hear bad feedback. I know I sure don’t. But if you want to improve, you need to know what it is you need to improve. How am I supposed to improve something when I don’t know what it is that I’m doing wrong? Not including a channel for feedback — or making it difficult to do so, as I allude to above — is doing a disservice to your organization and to your clients.

Good communication between you and your client is important. Not only does it help your client, it helps you improve your organization, and it builds trust between you and your customers. Making it difficult for your customers to communicate alienates them — and ends up hurting your business in the long run.

Who has the final say on a service issue?

I recently registered for Homecoming Weekend at the old alma mater. For me, it’s a reunion year ending in zero, so this year is of particular interest to me. (No, I won’t say which one it is. All I’ll say is, I’m getting old!)

While going through my own information on the Homecoming web site, I noticed a minor error. It wasn’t particularly big, and the error isn’t important in and of itself, but the university wouldn’t let me change it online; I needed to email them to get it fixed.

In response, I received a Jira service request notification indicating that it was in the queue. I knew right away that they were using Jira; we also use it in our office, and the email format and appearance is unmistakable.

The next email I got from them, a couple of hours later, is the graphic you see above, and as someone who’s worked in technology his entire professional career, I found it to be particularly irksome. When I received the message, my immediate thought was, “excuse me, but I am the customer. Who are you to say that my issue is resolved and completed?!?”

Sure enough, when I checked my information again, it still hadn’t been updated. I even tried clearing my cache and refreshing the browser. No dice. I wrote back, saying that I didn’t see the change and asking how long I should wait before I saw it. For all I knew, the web server had to refresh before any data changes appeared, so I gave it the benefit of the doubt. I received an automated message saying the case had been reopened (I was responding to Jira, after all). I didn’t get another response until this morning, when once again, it was marked “Resolved” and “Complete.” When I checked my information again, the change was there. I did not receive any other communications or acknowledgements, other than the automated Jira responses.

In their defense, to me, a department called “Constituent Records” sounds more like a data end-user role, rather than a full-blown IT or DBA role (I could be mistaken), so maybe they weren’t versed in concepts such as tech support, support levels, incident management, or support procedures. Nevertheless, I still found this to be annoying on a couple of levels.

First, it is up to the customer, not the handler, to determine whether or not an issue is resolved. The word “customer” can have a number of connotations*; in an internal organization, the “customer” could be a departmental manager or even your co-worker sitting next to you. To me, the “customer” is the person who initiated the request in the first place. An issue is not resolved until the customer is satisfied with it. It is not up to the handler to determine whether or not an issue is resolved. The handler does not have that right.

(*Side thought: the customer and handler can be one and the same. If I come across an issue that I’m working to resolve, I am both the customer and the handler. Nevertheless, the issue isn’t resolved until I, the customer, is satisfied that I, the handler, took care of it to my — the customer’s — satisfaction.)

Second, as a technical communicator, I was annoyed by the complete lack of communication from the person handling the request. The only communications I received were either comments contained within the Jira ticket or automated responses from Jira itself. Not once did I receive any message asking for any feedback or asking to see if I could see the change. The only messages I received — before I responded saying I didn’t see the change — was an automated Jira response acknowledging that they had received my request, and a second message that it had been resolved and closed. Boom. End of story.

I’m writing this article as a lesson for anyone working in a support role. First, feedback is important. You need to know that you’re handling the issue correctly. “How am I doing?” is a legitimate question to ask. Second, it is not up to you, the handler, to determine whether or not the issue is resolved. That right belongs only to the client — the customer who initiated the request, and whose issue you’re handling.

I’m speaking at SQL Saturday Virginia Beach — June 8

Saturday, June 8 is coming soon (a week from this Saturday). How will you be spending it?

For me, I will be speaking at SQL Saturday #839, Virginia Beach that day. I will be doing my presentation entitled: “Disaster Documents: The role of documentation in disaster recovery.” In my presentation, I tell the story of my company and my workgroup — which had an office in the World Trade Center on September 11, 2001. I had written several documents for our organization, and they ended up being critical to our recovery.

Come on out and check out my presentation. I can always use a good audience. Hope to see you there!