Diary of a Network Geek

I know it’s been quite a bit since I’ve written here or updated my status. Thankfully, I do have a new job. I started as the Director of IT Operations for UHY in April.
It was a longer process than anyone would have liked it to be, but I’m incredibly happy here. Even knowing that I was a bit over a barrel financially, I was offered a very competitive salary. The benefits are as good or better than any I’ve had and the commute to the office is about 10 minutes. A 10 minute commute in Houston is practically unheard of, and I’m one of those weirdos that like going into the office, even though I could work from home several days a week. I just feel like I get more focused time to get things done and then I can separate from work and relax. It’s really been a better job than I could have hoped for last year when I found myself suddenly looking.

I’ve got a small team that reports to me and I get to be at least a little hands-on still, which is kind of unusual for this level of role. It’s been a real blessing and I’m absolutely thankful to have landed the role.

So, I’ve been putting off making this announcement for about a week, but I’ve been laid off from my last job. My very kind Director, who I hadn’t worked with for very long, was good about reassuring me it had nothing to do with my performance and that it was 100% about cutting costs and trying to increase margins. He also volunteered to be a good reference for me. In fact, he said it while HR was still on the line with us. So, I’m in the market again, a little sooner than I’d hoped, but, well, job change rarely happens on our timetable, does it?

Of course, when I started this blog more than 20 years ago, before blogging software was a thing and, really before blogging was much of a thing, I did it because I was changing jobs. It was my attempt to “game” the search engines into ranking my website and, therefore, my resume, higher in the hopes that a recruiter would see me and reach out. Now, of course, we have sites like LinkedIn, and you can find my profile there. I’ve got no idea where I’ll land this time or how long it will take to find a new gig. I know the longest I was out of work was a year back at the end of the dot com bust, starting between when Compaq and HP merged and when Enron went under because they got caught cooking the books. It was rough because so many people in technology were out on the street all at the same time. From what I understand, things are better now, at least in Houston where I am. And, it’s easier since I’m more than willing to work either a hybrid schedule or go back to being in the office all the time. I don’t mind either way, as long as the commute isn’t too bad.

So, anyway, there we are. I’ll be making a similar plea for help on LinkedIn, too. If you know of anyone hiring experienced IT Managers or Directors, send them my way!

Or, things I’d want to know before I seriously applied for, or took a new job.

The other day, a recruiter emailed me a super vague job description and we had a brief exchange about it. It was a little interesting, but, mostly, it was a mystery, because they just didn’t have a lot of details. Frankly, it sounded like the client wasn’t quite sure what they really wanted, except that they wanted to move all their IT support in-house instead of continuing to pay a managed service provider to maintain their systems. I made a post on r/ITCareerQuestions asking the question “What do you want to know before considering a job?”. I shared in that post these questions that I’d want answers to before being submitted for an open opportunity:

• How many users? And how are they distributed at multiple locations? (IE. How many end users in what city and state?)
• How many people are going to be hired, ultimately, to be in the IT Department? (I generally think one support person per seventy-five or fifty end users is a good ratio, if I can swing it. I always seem to support more than that, but it’s a goal!)
• What servers are they running? What do they all do?
• Where do those servers reside? (ie. On-prem or offsite data center or cloud)
• Are they ALL virtual? On what? If VMware, what version? What OS are the virtual machines running?
• What kind of physical host or hosts are the virtual machines on? Is it a cluster? Is there shared storage (ie a SAN)?
• If there is more than one site, how are the sites connected?
• How is email being handled now? On-prem Exchange? Hosted? Office 365?
• What is the IT budget currently? How do they expect to see that expand?
• Where is the main business headquarters? What’s the commute if I’m coming from [part of town where I live]?
• How have they handled COVID-19?
• What problem am I being hired to fix? Why are they looking for someone?
• What does the compensation look like? What are the benefits? Is there a 401k and how much matching is there? What does the health insurance look like? Is there a bonus structure and how is that determined?

Hopefully, I wouldn’t have to ask them all of the recruiter, since the job description would normally include some of this information. Also, these questions assume that I wouldn’t be relocating across the country. So far, one Redditor came up with just one additional question that I’d want to know the answer to; How often are performance reviews done and what does that process look like?

So, dear readers, what about you? Anything you typically want to know about a job before applying?

Advice from your Uncle Jim:
"Live truth instead of professing it."
   --Elbert Hubbard

“Managing up” has to be one of my least favorite business buzzword phrases, and the most condescending.

I’m grateful I don’t hear this phrase as much as I used to earlier in my career. The last time I heard someone use it, they were commenting on how little they thought about their direct supervisor’s ability. When you think about it, the phrase, and the idea behind it, is pretty insulting. The implication is that I know better than the person above me in the company organization chart and, essentially, have to do their job for them because they’re incapable of managing me. For one thing, it starts from a false premise, though one that a lot of technical people seem to buy into, namely that my work requires knowledge and abilities beyond the management layer above me. I’ve never found that to be actually true.
I prefer the term “managing expectations”. It’s more accurate and applicable to all levels of the org chart. It’s also something I do regularly. For instance, if I’m working on a project for someone, I want to make sure they know what’s involved and the kind of time that might take so they have some idea why I’ve set a delivery date. Or, more importantly, why the delivery date the stakeholder might expect is unreasonable. There are times, of course, that I find myself able to deliver well within the expected time, but, unfortunately, that’s much more unusual.
The other way I manage expectations is in what can be delivered at all. I will grant that to many the computer systems I work with on a regular basis are a bit like magic. Black boxes of mysterious abilities that miraculously produce information and reports when working correctly. Or, evil, possessed infernal machines that are blamed for keeping some other department from producing results when they aren’t working well. Obviously, my goal is to make sure the technology in my care is always working well, but that’s not always possible. And, when I’m asked by someone to produce something new, I want to give them an accurate idea of what precisely I’ll be able to deliver to them on whatever timetable is likely. Of course, like most technical people, I follow the lead of Montgomery Scott, Chief Engineer of the starship Enterprise and do my best to set expectations low so that when I am able to exceed them I seem like a miracle worker. Like the time I told someone I’d “do my best” to recover some of the more than three terabytes of engineering drawings that the previous IT person had lost to a cryptolocker virus, then found a decryption tool after everyone else had left early for a long holiday weekend that restored all the lost data.
Yes, I worked what seemed like a miracle, but before I did, I set the expectation that the data was going to be lost because the last tech hadn’t tested the backups. So, rather than “managing up”, manage expectations of what kind of results, and when those results, can be delivered. Everyone, not just your managers, will appreciate it more.

This post originally appeared on my LinkedIn profile.

Clear goals make for more successful projects.

There is no way to guarantee a successful project, but I can sure tell you the best way to make one fail; don’t set a clear goal.
When I was in Boy Scouts, I earned my Eagle Scout award. That was a long time ago, and I know some things have changed since then, but one requirement that hasn’t changed is running a successful service project. At the time, the bar for success was set pretty low, and, of course, I had lots of help from Scoutmasters and advisers on how to set up and run my service project. What I learned in Scouting, I carried forward into my working life and still use to this day. The single best way to stack the odds in your favor of success is having clearly defined goals that include a deadline. My goals, whether personal or professional, need to be so crystal clear that I can express them to someone not involved in the project in thirty seconds or less. If I can’t do that, I need to rethink whatever project I’m gearing up.
For instance, as a technical specialist focused on IT infrastructure, when I’m getting ready to refresh datacenter hardware, I should be able to tell my CIO or CFO what servers and drive arrays are being replaced, how the data will transfer from the old hardware to the new equipment, what the time involved will be and what my fall-back plan is in case of catastrophic failure at some level. Simple, clear and direct. And, I should be able to state that in a non-technical way for non-technical staff who might need to know. If I’m upgrading a wide-area network from a series of point-to-point connections in the old-fashioned spoke-and-star configuration with a software-defined WAN configured with a mesh of redundant connections, I need to be able to clearly describe that end result, with the advantages and disadvantages and any potential risks, to non-technical executive staff.
I need to be able to do all that not only so they can hold me and my department accountable for our success or failure, but also so that I can keep everyone on the project focused in the right direction. This is the lesson I learned so many years ago working on my Eagle Scout service project. A clear, concise goal is easier to explain and share with outsiders, but it’s also essential for project participants, to keep everyone focused on the same goal and headed the same direction. No one can lead a team, whether on a short project or on a larger team, without clear, shared goals and deadlines. A project without a clear, shared goal is doomed to failure because no one will be working together on the same shared goal, except by accident.
Success should never be an accident. It should always be a plan.

This post originally appeared on my LinkedIn profile.

I work in IT because I didn’t want to do sales.

The only problem is, everything is sales.
Even though my degree is in Marketing and my very early career included a commission sales job that was so profitable for me I was able to write a check for my first used car, I prefer to work with technology. In college, I actually took classes in sales and salesmanship. My father, who was an inveterate salesman by both nature and trade, always used to tell me that everyone sells and everything is sales. I decided to follow a different career path, though, when I saw what a good salesperson had to do on a daily basis. I’m pretty self-directed, but even the best salesperson deals with more rejection in a day than I probably handle in more than a month. But, that doesn’t mean that I haven’t, ultimately, embraced the reality that everything is sales and I’m selling, one way or another, every day of my life. The thing is, so is everyone reading this, whether they realize it or not.
Don’t believe me? I’ll prove it.
Any time in the past month, have you had to convince anyone that your plan for whatever you’re working on at the office is better than someone else’s? Maybe you’ve tried to convince someone that your restaurant choice is better than theirs? Those are both selling. The thing that people who haven’t done it don’t understand about sales is that you don’t sell products. You sell the idea that your product is the right product for the customer. Or, in my line of work, I sell the whatever idea I have about how things should work in an IT Department, or how IT can solve a business problem and how I’m the right person to implement that idea. Am I successful every time? Of course not, but I am selling every time I step up to pitch a project or procedure to my direct supervisor, my peers or other stakeholders in my company. And, the better I am at selling my ideas, the more work I get to do and the more interesting that work is to me. After all, given the choice, I’d much rather work on things that I think matter, are important or that teach me something new. Before I can do that, though, I have to sell my manager on the idea.
The other thing to keep in mind about selling, though, is that high-pressure sales doesn’t really work. There are still dedicated salespeople who will try those techniques, but that time, thankfully, has passed. All my training and experience has taught me that the single best way to sell, whether insurance or technology or patio furniture, is to sell the customer, or manager, on how I can solve their problem, whatever that may be. That, of course, means I have to talk to the person I’m selling to and find out what their needs are so I can show them how whatever I have will help. And, on the rare occasion that I don’t have something to sell them to fix their problem, I have to be smart and honest enough to acknowledge that and move on, or point them toward someone who can solve their problem, if I can.
Selling is one of the most challenging activities in my work day. In retrospect, even though I work in IT Infrastructure, I’m glad I have the experience and training of a salesperson. It turns out that my Dad was right after all; everything is sales!

This post originally appeared on my LinkedIn profile.

Sometimes, the raw numbers don’t really tell us how expensive something is.

One of the regular struggles we have in IT is that we are an expense. The bottom line is that, for most businesses, we don’t generate revenue and are strictly a cost center. And, unfortunately, in my experience, because we’re a cost center, spending on technology is resented almost as much as paying the electric bill or paying taxes; a necessary evil. What gets lost, I think, is the value provided by technology. To start with, much like electricity, business generally doesn’t work at all without IT. Technology runs the point-of-sale systems and the Accounting systems that even make it possible to collect and track money. Without it, business would simply halt. But, beyond that, the cost of the actual technology often overshadows the value provided.
Not too long ago, I had this same argument with a fellow IT professional who was mired in the numbers. To their credit, they were examining a potential equipment purchase from a strictly financial point of view. Since the Accounting Department or CFO are often the final decision-makers on technology purchases, seeing this process through their eyes can be beneficial. The problem is that the full potential value of upgraded equipment can easily be forgotten in the drive to spend the absolute least dollar amount possible. Don’t get me wrong! Technology costs absolutely have to be kept under control or IT people will focus only on getting the newest toys to play without considering the cost to the organization. But, the actual spending has to be appropriately balanced with the value provided by the purchase. As technology professionals, it’s part of our job to present not only the minimum and best options available, but what advantages there may be to making a particular purchase. Sometimes, the value of upgraded technology goes well beyond the dollar value.
Take, for instance, the opportunity to upgrade from a standard two server, one storage area network system, that was new technology fifteen years ago, to a hyperconverged system that spreads computing and storage capacity across four servers or hosts. It’s absolutely valid to look at the raw cost of the two solutions. And, you will absolutely see that buying two classic servers is less expensive than buying four modern hyperconverged nodes. But, if you stop there, you don’t see the added value of less downtime due to a hardware outage that can be avoided by upgrading to a newer, redundant technology. Or, the increased speed and efficiency gained by upgrading to a modern system purpose-built to run in a cutting-edge datacenter. Maybe there will be more opportunity to add capacity to the new system as the company grows. Or maybe there are business continuity advantages to a hyperconverged system beyond additional, redundant hardware. Though, to be honest, I think that’s reason enough!
Regardless, my point is that as technology professionals, we need to clearly communicate all the risks and benefits, expenses and added values, of our purchases. As subject matter experts, it’s in everyone’s best interests for us to educate decision-makers beyond the dollars-and-cents bottom line, to give them a true understanding of the value to be gained beyond the simple expense of a purchase.

This post originally appeared on my LinkedIn profile.

It never stops being important.

I think of myself as lucky in many ways. I trained in sales, but fell into IT work early in my career and found that I was good at it. I also was lucky enough to win a free training course and series of tests that got me my first big IT certification. But, I think the luckiest thing that happened to me in my early career is getting trained in customer service by Hyatt Hotels, known the world over for their excellence in service and training.
Of course, I’d worked retail jobs before working for Hyatt so I had at least some idea what it was like to work directly with the public, but Hyatt’s training really drilled us to be always thinking about the customer. I was taught to be thinking about the guest, or customer, as soon as I was visible in public areas, which in the hospitality industry is called “front of the house”. The last part of my uniform I put on was my smile, because, regardless of how I felt, I was there to do a job; make the customer feel welcome and important. But, there were the little things, too, like how we’re all part of a team serving the customer and if we saw trash in the guest areas, we should pick it up and not wait for cleaning crews to get to it. We were taught to work as a team, all the time, to make our customers feel as though we cared. And, the funny thing is, the simple act of pretending that we cared eventually meant we did.
As an IT professional, I am still in a customer service role. Even if I’m working with department heads or C-Suite executives, in the end, I’m still providing a service and need to pay attention to my customer, internal or external. But, don’t think that Accountants or Sales Managers or Truck Drivers or any other person delivering a good or service doesn’t have a customer and that those customers deserve good service! It’s something I think is forgotten or ignored. As an employee, I always have someone who is benefiting from my work; my internal customers, if you will. And, those people are entitled to me helping them to the best of my ability with as much friendliness and cheer as I can manage.
I know the idea is old-fashioned and falling out of vogue, but I still believe that good customer service, regardless of who my customer may be, is just the final layer of professionalism that can set us apart, as individuals and organizations.

This post originally appeared on my LinkedIn profile.

The metaphor of “internal customers” is unfortunately falling out of favor.

Lately, I’ve seen articles criticizing the idea of having internal customers. It’s a shame, really, because the people who are so willing to abandon that idea seem to be doing so because they don’t understand why it’s so powerful. The criticisms I’ve heard fall under two basic categories; accounting-focused people who don’t want to “charge” departments for internal services and people who seem to think the need for collaboration with other business units removes the need to provide customer service to end users. They’re both coming from some incorrect assumptions and, I’d argue, a misunderstanding of what services IT provides in an organization.
As technical people, in most organizations, we provide support functions. Any service-based group absolutely must pay attention to the service provided to those who use that service; their customers. People who incorrectly think that the old practice of charging the cost of internal IT services back to the departments who use them is a reason to abandon the entire idea of internal customers are losing sight of the goal behind the metaphor. The goal is not, as they seem to think, to make sure everyone pays equally to support the IT department. The goal is to remind technical personnel that the systems and networks we manage aren’t defined by the hardware and software, but rather the end-users who actually use the technology we provide as tools to do their jobs. When we forget that, we forget that our goal is to serve those end-users, not the systems. That sad, mistaken idea is clearly expressed in the old system admin joke, “My network would run perfectly if not for the users!” I cannot tell you how many times I’ve heard technical experts grumble about what a waste of time user requests are instead of seeing how it’s our only reason to exist. As a technical expert, my only reason to be employed is to solve other people’s problems, to provide service to my customers, the end users.
And, that leads directly to the second misunderstanding I see used as an objection to the end user as customer metaphor; technical experts cannot collaborate to provide solutions AND be mindful of customer service at the same time. We would do well to remember what the genius R. Buckminster Fuller said about solving problems, “When I am working on a problem, I never think about beauty but when I have finished, if the solution is not beautiful, I know it is wrong.” If I “solve” a technical problem for a user, but they wrestle with my solution so much that they never use it, then I haven’t actually solved their problem at all (ie. It’s not a “beautiful” solution to the problem.). A perfectly workable procedure that the user doesn’t understand or finds too difficult to use regularly is as good as useless and I’ve failed my customer. I can’t make my internal customers happy every single time, but I ought to be trying because the only reason I’m employed is to solve their problems well and in a timely fashion.
I could go on a great length about all the ways I’ve seen technical people abuse their internal customer, the end user. In the old days of “big iron” mainframes, it was unfortunately all too common. Today, we should know better and embrace our roles as service providers making business run more smoothly, efficiently and well. Let’s stop making customer service a joke and help our users be better.

This post originally appeared on my LinkedIn profile.

Are We Becoming Obsolete?

There’s lots of talk in the news of artificial intelligence replacing humans.

I don’t put much stock in it though, because, frankly, we are a ways off from that becoming a reasonable and less expensive alternative to most jobs humans do. Not all, to be sure, but, most. And, granted, automation has replaced a lot of jobs already, but artificial intelligence has to improve a LOT before robots can replace people in positions that require critical thinking skills, like, for instance, Network Administrators. On the other hand, most banks seem to have all but replaced tellers with ever more advanced ATMs. And, there’s been more talk about having kiosks for ordering fast food, too.
Okay, so maybe, as a tech who, according to the site Will Robots Take My Job?, has just a 3% chance of being replaced by robots and, in fact, has a projected growth of 8% in the next thirteen years, I’m a little smug.
Want to know how safe your job is? Hit that link and see. Probably, if you have the critical thinking skills to read my blog on the regular, you’re going to be safe. Or, you’re already unemployed. Either or.

Have a great weekend!

This post originally appeared on Use Your Words