STRIPES: Perseverance Means Performance

Note: This post is an installment in the STRIPES series. For more background on what STRIPES is, check out the July 15, 2020 post.

You can almost smell the grit.
No joke, though - there are some great restaurants on this street.

As I’ve mentioned before, I have spent most of my career at UMass Lowell - a public research university of just about 20,000 students in Lowell, Massachusetts. Lowell is an industrial-revolution city with an abundance of what people around here call “grit.” Lowell has had a tough history and the people in this area have grown mentally tough because of it. Knock a Lowell resident down, and they’ll pop back up barely noticing that they fell. This is one of the things that I really like about living in this area. It may not be a full consolation for having no palm trees, but I like that people around me don’t expect that anything they need to do will be easy.

Consequently, I’ve been excited to write this post since I started the STRIPES series almost a month ago. I think perseverance is the most important trait to predicting success on the job and in life. Almost everything worth doing is hard, almost everything worth doing will cause pain to do it well, and those who can push through that can achieve amazing things. While this is true in almost every area of your life, this blog is about IT careers - so I want to focus on that.

Over the course of my time in the office, two stories have left a lasting impression on me and I use both with folks on my team to explain what I mean about grit. These are both completely true stories, but I have of course changed some details and names to protect everyone’s identity – except mine. I’m writing the blog, so it would be awfully tough to delete myself from the story.

Some time ago, I had asked an engineer, Mark to write a script that would push a certain patch to every computer that had Office 2016 installed. If the computer had Office 2013 on it, the script should instead upgrade the application to 2016 making sure to keep the same application packages installed, particularly Visio and Project. A week later, Mark’s supervisor, Joanna (who is my direct report) came into my office to tell me that Mark was saying that it couldn’t be done the way I had asked for it to be done. She rolled her eyes a bit and said, “He’s saying it’s just not possible… again.” Mark had done this a few times – he would hit a technical hurdle or stumbling block and just throw his hands up in the air and quit. This was the IT equivalent of hitting a speed bump in your car, saying “screw it”, throwing your keys out the window and just walking the rest of the way.

Pictured: An answer machine.

I raised an eyebrow and asked Joanna what she thought. She said it was “bunk” and could absolutely be done. She said she was almost sure how she’d do it, because the documentation was pretty clear and the only real hiccup was having the script ascertain what version of Office was installed.

I told her to see what she could do with it, and less than a full day later she came back to tell me it was working. I asked Joanna what Mark thought of it and she told me that he hadn’t seen it yet. I think she wanted me to know that she had done it without any of Mark’s help. I told her to close the loop with him and get the code pushed out. Mark didn’t take it well because clearly he had been proven completely wrong – not only was it possible, it was working live in the environment. Back to our car analogy, Joanna drove by Mark as he was walking to the destination. She may have waved courteously on the way, but she drove over the speedbump and drove on by.

I’d like to contrast that story with another one that I talk about in a few of my sessions at VMUG UserCons. It remains one of my favorite IT stories from my career.

In a research environment it is very common for the folks doing the research to purchase a bunch of different technology for their lab without any IT assistance or consultation at all. Generally, this doesn’t bother me aside from some obvious concerns about data security because often these systems require no support from my team and are necessary for whatever they’re working on in the lab. About a year ago, I became aware of a request from an on-campus customer that they needed some assistance with a Synology storage array that they were using for large datasets.

At the time the request came in, the entire admin team was fully occupied with a few mission-critical and time-sensitive projects that they needed to be fully focused on. I was about to tell the folks that we could look at once we were past some pressing milestones, but that we couldn’t help right away. Almost as I was typing the email, Sarah, the manager of the call center support team came in and told me that Jamal who was on her team was looking for some projects because he had some time between calls on most days and wanted to make sure he was helping out wherever possible.

Now Jamal had always struck me as pretty bright, but his job was to walk people through Outlook configuration issues or connecting to printers in their office over the phone. This was not in his wheelhouse, nor did I think he’d have the skillset to immediately resolve the issue - but I didn’t have an admin free. Ultimately, I figured it couldn’t hurt to send Jamal to take a look, so instead of writing the lab manager that we couldn’t engage I told him that Jamal would reach out soon when he freed up. I chatted with Jamal to let him know what the most important goal was: lose no data. So long as that priority was accomplished, I told him to move on to find out why no one can connect and see if he could fix the issue. I moved on to other things.

Two days later, the manager of the admin team came in to see me and told me I had to see something. He put a small white object on my desk and asked me if it looked familiar. I told him it looked like a key to a server cabinet or something. He smiled and told me the full story:

Jamal had gone over to the lab to get some information about the device and physically examine it. He then went and started reading some documentation and found out how to directly connect to the device with a laptop. Then he found out that the Synology has some diagnostics it can run to give you an idea of what was wrong with it. One of the early steps was to remove the drives from the drive bays, and so Jamal went to do so - and found out that they drive bays were locked.

So here was a phone support technician in front of a device he’d never seen before without a set of keys. He asked around the lab and no one even knew there was a key - let alone where it could be. He checked in with the system admin manager, but because we had no other Synology devices on the campus he didn’t have one. So Jamal did what almost no one else would bother to do. Jamal made one.

I keep this key on my desk - not because I need a Synology key, but because of a reminder that perseverance is the determining factor for outstanding results.
However, it would look a lot cooler in dark gray.

I’m not kidding. Jamal found pictures of a Synology key online, and build the pattern in CAD. Then to find scale, he measured the slots on the drive bay, took some photos and reverse engineered the key dimensions. Then he 3D printed a few with slightly different dimensions – just in case.

The following day, he came in, unlocked the drive bays, performed diagnostics, replaced a bad drive, rebuilt the RAID array, performed a backup, and got everyone up and running.

Let’s rewind a minute here – Jamal was a phone support technician. If you wanted your password reset, you called Jamal – but you didn’t call Jamal when you absolutely, positively needed your storage array online. At least you didn’t at the time. You do now – because weeks later Jamal was promoted to the systems administration team. You do now because Jamal proved that he wouldn’t lay down and die. He wouldn’t fail. He hit more than one stumbling block. He had never seen a Synology. He had never worked with a RAID array. He certainly didn’t know how to run diagnostics on one. And he was physically without the tools to fix it. Yet fix it, he did*.

Jamal exhibited the kind of perseverance that I wish I could bottle and give to everyone working on my team. You don’t have to be the most educated person on the team. You don’t have to be the most talented. You just have to be willing to plow through obstacles to get to the goal. If you can stay the course and not get discouraged, you will be successful and the sky’s the limit. There is a way over, under, or around virtually every problem. Sometimes designs need to change to accommodate an issue, but that doesn’t mean you should give up on the goal of a project.

If you’ve ever been sitting in front of a problem that you just can’t seem to solve – do you think “this isn’t possible” or do you think “there’s got to be a way – I just haven’t found it yet”? If you think the former, you’re setting yourself up to look like Mark. You’re going to throw in the towel and then when someone else gets it done, you’re going to feel foolish – and frankly look foolish, too. One of the key things I and most other IT leaders want out of anyone on an infrastructure team (or really any IT team) is to be able to look at a problem and find a way out of it – not just report to me that there’s a problem.

I’ll end this post with this thought: the only thing stopping you from persevering – and therefore succeeding - is you. You don’t need to have the top-of-the-line certification to persevere (though you need to persevere to get said certification). You don’t need to have the most experience. You don’t need to have seen the problem before. You just need to want it. And you can decide each and every time you hit an obstacle.

Are you going to lay down and die, or get up and go kick the problem’s ass? It’s up to you.

Okay, time for reflection:

• Who is the person in your office (or your life) who just gives up when they hit a roadblock? What do you think of that characteristic?

• When did you last encounter a problem that got you totally frustrated? Did you give up? Did you solve it?

• How can you encourage yourself to get up and take another pass at a problem when you can’t solve it right away? How do you stay motivated?

*Special thanks to Jamal for reminding me why I love this career. I still have this little key, because it’s such a great reminder of how we can all solve problems that we didn’t think were possible.