People Tech

End users are not helpless babies

IT departments, particularly infrastructure teams, are often thought of as being anti-user. We get the reputation of being grumpy cave trolls, unsympathetic to the wants and needs of those all those dumb, unreasonable end users. It’s all tech for the sake of tech.

Sometimes that characterization is earned and fair, sometimes not. Either way, it’s a problem of attitude and perception.

At the other end of the spectrum are people who consider themselves defenders of end users, protectors against undue change and hardship. It’s not very often that it’s classified as such, but this attitude can be just as toxic and damaging as any overtly anti-user sentiment.

End users don’t need you

If you think end users need you, either as the provider of some critical service or as someone who will protect them from change, you sir/madam, are arrogant at best, if not also an idiot.

Unless the core of the business is technology, most businesses would figure out how to keep functioning if everyone in their IT department got hit by a bus. It might be painful and frustrating, but they’d make it through. Believe it or not, there were businesses before there was IT.

If you believe your end users need you to protect them from the IT trolls who’ve been looking down their noses at them, consider this: there is no surer sign of disrespect for a person than to assume that they need your protection.

At best, end users enjoy the benefits and efficiency of the services we provide them. Our job is to help and lead innovation where we can, not to lord-over or to be a conservitor.

Get out of their way

When it comes to creating road blocks for users, the usual problems are those that can be fixed by discussion –  having an un-realistic security policy is a good example.

Making a cultural shift from traditional IT to things like XaaS and BYOD is a little harder. Becoming comfortable with user-led IT and innovation is something that many IT people can’t achieve.

“Why would you want to use Dropbox when we’ve built this super awesome Windows file share for you?”

One of the hardest problems to fix, though, is a hardline conservatism against change that evidences itself by people saying things like:

“We can’t do that, our users will never figure it out.”

When that attitude pervades throughout an IT organization or business, it prevents users from getting access to new tools that might help them do their job and puts the business at a competitive disadvantage.

Yes, change control is needed and yes, we should not change things for the sake of changing them. But to not embrace change and enable end users to use new and different tools will leave everyone coughing in the dust.

Your users will figure it out, because they are intelligent adults. Have some respect for them and trust them. If you’ve provided them with good tools (which are inherently coherent and usable), they’ll get there.

Exposing end users to change isn’t an unsympathetic act (at least it doesn’t have to be). Speaking for myself, when I give a user something new it’s out of an intense sense of empathy – I know they don’t need me to help them, but I also know they don’t need me to stand in their way.

I’m also thinking about a longer game, one where not everyone works for the same company their entire life. I’ve seen family members and friends who were inhibited by their employer’s IT end up having a lot of trouble either finding a new job or coping with a more modern IT ecosystem at a new company.

As much as dismissing user complaints offhand isn’t helpful, sheltering users from change is not helping them either. If we really care about the people we’ve been tasked to help, the right solution is somewhere in the middle – throttled change supported by good testing, training, and in many cases, just trusting that users will figure it out.

Image Credit: Harald Groven

People Tech

How to sell IT to a cranky millennial

I am regularly accused of not liking salespeople, sometimes by the salesperson I’m currently meeting with. I don’t think this is true, but I can understand why one might think it.

If I smell blood in the water – an obvious lie, hyperbole, arrogance, insincerity – I go for the jugular. An example must be made, a lesson taught. I don’t mean to be this way, it’s just something in the way I’m wired – a neurological pre-disposition to not suffering fools.

To be clear, my hostility is not directed at the person, but the role they are playing, in many cases, the role they have been taught to play.

Truth is, I’m fine with salespeople. At several points in my career, I’ve been one. I have stared into the abyss of constant rejection. I’ve felt the pressure and inadequacy. Sales can be miserable and, at times, soul crushing.

What I actually dislike is the Game of Sales, the wagon wheel ruts that so many salespeople fall into and never steer away from – the pitching, the talking in circles, the “I read it in a Zig Ziglar book” tactics, and oh-my-God, the presentations.

I reject the notion that this is the way it has to be, that this is just “how it is” and everyone needs to get on board, power through, and get comfortable with never saying what they mean in a sales meeting.

It can be different. It can be so much better and it all starts with one thing.

Ask questions, and listen

I’ve lost count of the number of salespeople who’ve told me “Our customers love us because we listen to them.” and then proceeded into a lengthy soliloquy about how awesome their company is.

They talk about partnerships and our future together, coming off like the psycho person who talks about marriage and kids on a first date.

If we’re meeting in person, they probably brought a PowerPoint deck with lots of slides showing awards and Gartner Magic Quadrant placement and some insufferably cliche mission statement.

Guess what? This might hurt a little, but your prospects don’t care who you are. If they agree to anything as the result of your pitching, most of the time it’s just to get you out of their office.

As for partnerships? If you’ve pitched a partnership at our first meeting, I don’t want it. I don’t even want to be your customer. Partnerships are forged and justified by time, information, and action. We have none of those things together. What you’re really asking for is un-earned, blind trust so you can sell me the moon with no questions asked. Sorry, but no.

Try this instead: Ask questions.

  • “What do you need?”
  • “What’s causing you guys the most heartburn right now?”
  • “Tell me about your business.”
  • “What’s the next six months look like? Where do you want to go with this stuff?”

And just keep asking questions. Hone in on the problems your product or service can help solve. Gather information so that the next time we meet, you actually have something worth presenting: how you can help, which is 1000x more important to a prospect than anything else you’ve told them.

Maybe the answers to your questions reveal that you can’t help. That’s a real thing, accept it. What you’re selling doesn’t work for everyone.

Instead of wasting time chasing the prospect with follow-up calls and e-mails, and driving them to never wanting anything from you even if you could help, how about you shake hands and move along to someone else you might actually be able to help?

This works. It absolutely works. I’ve sold way more by asking questions than I have by pitching and I’m a lot more receptive to salespeople when they approach me the same way.

One of the earliest big sales I closed still sticks with me, not because of the dollar amount, but because of what the customer told me and my business partner after we closed.

“Out of all the companies who came in here today, you’re the only ones that asked me what I needed.”

Image Credit: Elias Levy


All your data is garbage

Storage is cheap, especially in the cloud where you can pay pennies per geo-redundant gigabyte. For someone who once paid $200+ to replace their 400 megabyte drive with a 1000 megabyte drive, that’s almost unbelievable.

No more expensive tape libraries. No more hiring couriers to ship data to an offsite vault. No more budget-busting SANs. No more uninstalling 1001 Amazing Fonts to free up space for Warcraft: Orcs vs. Humans.

Cheap led to less worry and it changed the way businesses approached data. Keep it all. Keep it forever. We might need it later.

Oh, what a terrible idea.

Building a liability factory

“We’re keeping everything to protect ourselves.” is a flawed approach to data retention. Even if your business is 100% ethical, the idea that “We’ve got nothing to hide and all this data will only help.” is misguided and naive.

  1. No one has complete control of their narrative. Sliced one way (your way), all that data may prove you’re in the right. But the other side’s lawyer(s) is incentivized to bring their own narrative and context to the data. It’s often better to have the legal minimum data rather than a rich data set that someone can twist, re-shuffle, and turn against you.
  2. If you have it, you’ve got to provide it. This isn’t an issue because you’ve got something to hide, but it does become costly and unwieldily. Storage is cheap, but managing it is not. Every retention and recovery process you put in place takes time and adds a burden on IT staff. If you’re trying to keep IT cheap, having 10 FTEs just to process data requests from Legal is not a good place to start.
  3. If you have it, you’ve got to protect it. Consumer facing businesses are terrible with this one. It might be really awesome to know the hair color of all your customers, but every bit of data you collect related to your customers, employees, and business partners needs to be stored as securely as possible at significant cost and risk. Less data, less risk.

Caveat: I’m no lawyer, but I used to watch a lot of Law & Order and know several words in Latin. Habeas Corpus Callosum.

99% of your data is completely worthless

Unless you measure your corporate data in petabytes and employ your own data scientists, Big Data isn’t a thing for your business.

On the other hand, Business Intelligence might be, and a lot of businesses get great insight from analyzing their data and building dashboards. But the successful ones all have one thing in common – they know what questions they want to ask before they start collecting data.

The answers to those questions may lead to new questions that require more data to be collected and retained, but it’s better to start with the goal of “Here’s what we need to know.” instead of “Gee, I wonder what all this data could tell us.” The first is a path to making practical decisions, the other leads to pretty, but useless charts.

The pitfall, even with BI, is making the assumption that you are gaining predictive power. Gaining insight into What Has Happened doesn’t necessarily unlock the ability to accurately predict What Will Happen (although it is generally helpful). It all depends on the data model, and good models are ridiculously hard to create and maintain.

There are instances where massive data sets make prediction even more difficult, especially when you don’t have the right people in place who understand statistical baselining and the effects of specificity.  A smaller, intelligently analyzed data set may be far more useful to you.

Ask “Why?” and push back

Just because you can do something, doesn’t mean you should and there are only a few good reasons for businesses to retain data. Three, in particular, serve as a good sniff test.

  1. Regulation & Compliance – There is a specific legal requirement to store a specific data set for a specific amount of time.
  2. Real Need – The business literally needs the data to function – think payroll and financials.
  3. Quantitative Value – You already have a set of questions you want to ask your data.

Requests for data retention that don’t pass the sniff test tend to lead down non-sensical rabbit holes. Unless your business is, literally, data – you should be keeping as little data as possible.

Cheap as storage might be, between liability, opportunity cost, and management cost, all the data you’re storing could wind up being very expensive for your business.

Image Credit: United Nations


Saying goodbye to my CISSP

Part of growing up is figuring out that your time and attention are 1.) your most valuable resources, and 2.) finite. To paraphrase Gollum, they are your “preciouses”.

So it helps to be thoughtful and deliberate about how you spend them. You need to figure out where to focus to get the most from your investment.

As an IT person, some of that investment tends to be in studying and professional certifications. We have to make choices about what we’re going to pursue (what’s most interesting and what will help in the future), and what we’re going to leave behind (what’s uninteresting and least helpful).

The yearly renewal for my CISSP is due in a few days. I’m going to let it lapse.

Checking all the boxes

I got my (Certified Informations Systems Security Professional) CISSP cert while working for a firm that does IT audit – it was important to them to have a CISSP on their staff. I had done quite a bit of security work as part of my IT jobs, so I bought the study guide, registered for the test, and drove to a hotel in Dallas to sit for it.

I was the only IT person in the room. Everyone else was an auditor. They glared at me when I finished first and walked out of the room- they had been at the hotel for two weeks for a CISSP bootcamp. I had shown up the night before and flipped through the study guide. It was the difference between an IT person approaching security and a security auditor approaching IT.

My pass note came in the mail. I had checked the CISSP box. Over the next few months I took part in some audits and checked a lot more boxes.

And I quickly became convinced that IT audit is where dreams, happiness, and prarie dogs go to die. Be kind to your auditors, you may be the only thing keeping them from throwing themselves in front of a train.

From pride to apologies

Of my certs, the CISSP is the one that gets the most comments. At first it was exciting – it was the first management level cert I acquired and it felt nice to have  recruiters calling.

But over the years I’ve found myself becoming defensive.

“Oh, you have your CISSP?!”

*Look around* “Yes, but I promise I’m really down to earth and practical.”

My defensiveness was a response to the culture I was getting exposed to – security group meetups, forums, fights with auditors. In the past couple of years I found myself really not enjoying IT security.

The thing is, I love IT security. There are interesting problems to solve and an element of Sherlock Holmes-style mystery that’s a lot of fun.

But the curriculum and culture of CISSP (and much of IT security) isn’t really geared toward problem solving – it’s geared towards writing policy to deflect liability, even though many technically focused jobs ask for it.

As I went to events and gobbled up continuing education, I became less certain about who would be able to get the most value from the cert.

An Information Security Officer? It probably is a foundational cert if you want to blab about vague, misguided attempts at corporate risk mitigation. I guess that works. I bet the CISO in charge when Target got hacked had his CISSP.

It’s not really a good cert for auditors either, as it just gives them confidence to ask the wrong questions. It’s definitely the wrong cert for someone technical – I don’t think its creators would argue too strongly with that.

I know for sure that, right now, it’s the wrong cert for me. It may have helped me get a job or two, but I have to put my time and attention elsewhere to focus on more interesting and valuable things. I’ll still bake security into everything I do, I’ll just do it without the extra letters at the end of my name.

Image Credit: Ken Caruso


VMWorld 2015: Sessions, Swag, and a Broken Promise

When Satya Nadella took charge of Microsoft and said they were going “cloud first” I had a hard time believing him – given the previous CEO’s tendency for hyperbole and marketing double-speak. But they proved me wrong. Their continuous delivery of new features and services in Azure and Office365 over the last year has been impressive. It’s changed the way many IT departments approach service delivery.

At last year’s VMWorld, VMWare made the same promises. “We’re making the shift. We’re going cloud first with all of our products.”

A year later, I’m at VMWorld again and am unsure if they didn’t know what they were committing to or just changed their minds.

Tied to the point release

I love a lot of what VMWare is doing right now, especially in the end-user compute space. They’ve enabled some really interesting opportunities with all the integration work that’s been done from NSX in the datacenter down to the device with Airwatch and Horizon – things that are going to make security and device management a lot easier.

They’ve been a good partner to work with and they have a clear, unique vision of where they want to go with EUC and hybrid cloud, which is exciting.

But for a company that committed to “cloud first”, they sure talk a lot about “the next release”.

“You can already do this in the on-prem product. It’ll be coming to the hosted service later this year.”

“We’re planning at least three releases for our hybrid cloud next year.”

“All the features you’re asking for will be available in the next release.”

That’s not cloud first. That’s not continuous delivery or devops (ideas that VMWare has been speaking to heavily). It’s waterfall development with a focus on boxed product. It’s shoehorning on-premise into the cloud.

It’s a strategy that isn’t going to work if VMWare really wants to appeal to anyone outside of their most traditional enterprise customers. It’s certainly not going to get them out of playing catch-up to Microsoft and AWS.

Culture clash

There seem to be lots of people at VMWare who see the problem, but they are butting up against the internal politics and culture of “Don’t make our legacy customers uncomfortable or my division may lose sales and I won’t get my boat.”

The same battle is happening at all of the vendors making the shift to cloud. Bring up Meraki to someone in Cisco route/switch internal sales and watch their face melt. Everywhere you look you’ll see the old guard fighting a losing battle for relevance.

Maybe it takes a dictatorial leader to resolve that. “Shut up. This is what we’re doing. Get on board or get out.” I’m not sure I’d want to work for that person though.

I do know that shifting from point releases to continuous delivery takes a massive shift in mindset across the entire business that isn’t easy, but it’s not unprecedented. Microsoft and IBM are doing it and they’ve got much bigger ships to steer.

They’re leading with cloud and carving out boxed products for the customers that lag behind – prioritizing the future over the past. I’m not sure there is a “right” way to pull this stuff off, but what they’re doing sure looks “right”.

Promising progressive customers “cloud first” and then not executing is certainly the wrong approach. Unless your goal is to alienate them and get them looking for solutions elsewhere.

Image Credit: VMWare PR

People Tech

Accelerating Change: Adapt or be eaten

I was fascinated with animals when I was a kid. Whenever there was an animal documentary on PBS, I was glued to it.

My favorites were the predator and prey hunts – big savannah cats sneaking up on gazelles, chameleons popping out of camouflage to grab insects with their tongues – that sort of thing.

Mimicking the animals, my friends and I would play hide and seek in the woods – hunting each other with pellet guns (I’m really not sure how none of us ended up blind.).

Between reading, watching those shows, and getting pelted with lead, one thing stuck with me:

When you get comfortable and stop paying attention to what’s going on around you, you get eaten.

Or at least hit in the back of the head with a pellet.

Unable to adapt

Humans are terrible at anticipating change. It’s hard for us to get out of our day-to-day and our local scene. We’re busy, we’re distracted, we’re worried about surviving office warfare for the next 8 hours.

But we live in an age of rapidly-accelerating, Kurzweilian change. To keep one’s head down and assume everything is going to be a.) OK and b.) the same, is a form of intellectual and career suicide.

You know those people. You see them in the hall at work. You pass them on the highway.

They say things like “We’ll never do that…” and “It’ll be at least ten years until…” and “I’ll worry about that later.”

When it comes to technology they make the mistake of thinking that the next five years will resemble the last five. They look at continuous delivery, or BYO, or containerization and think “That’s fancy, but I’ll never have to deal with it.”

It is one thing to disagree about the nature of a change – this is healthy and necessary, but another to claim that something will not change.

Keep moving

We’re living through a major technological transition driven by pervasive compute and connectivity. It’s a big enough step that not everyone is going to make it – especially those who can’t or choose not to re-tool. Many people are going to find themselves pushed into lesser-paying roles or different careers.

It’s heartbreaking talking to those folks, trying to convince them that what’s headed their way is real – that the future is coming and it will be radically different than the present, even though we might all be wrong about the details.

“If you would move literally two steps to the right I think you’ll be OK.”

“Nope, ain’t gonna do it. You’re wrong, dummy. YOU’LL NEVER TAKE ME TO THE CLOUD!”

But I’m going to keep trying because the world is in constant flux and the future is coming. In fact (in the words of William Gibson), it’s already here, it’s just not evenly distributed.

Image Credit: Shutter Fotos


SCCM for device management is a dead end

I have always done my best to avoid Microsoft System Center, especially Config Manager. I don’t hate the product (It’s fine, whatever.), but I loath the culture and business decisions that SCCM enables and in many ways represents – turn every knob, customize every widget, control ALL the things.

SCCM is the embodiment of big, ponderous IT driven by big, nonsensical bureaucracy. It’s not the tool’s fault, it’s just how everyone ended up using it.

“We built a task sequence to swap out all the standard Windows icons with ones the CEO likes better. Your CD drive icon is now a portrait of Grover Cleveland.”

“The auditors said we need to index all the .ini files on everyone’s laptop. Then they asked what an .ini was.”

“Oracle wants us to show them a software report so they can charge us more.”

SCCM made it easy for IT departments to do stupid, expensive things and create unsustainable processes. I have rarely come across a business, that after spending thousands (if not millions) of dollars implementing and customizing, didn’t view SCCM as a grotesque monster – especially when they were trying to find people to maintain it.

Goodbye, Mr. Dinosaur

The unwieldy IT that SCCM supported is dying. Businesses are shifting to lean, cloud-based IT with less customization and little, if any, on-site server infrastructure.

SCCM doesn’t fit that model. Cloud-based MDM does and Microsoft seems to realize this despite their messaging on the topic being confused and noncommittal.

“More SCCM features are coming to Intune.”

“More Intune features are coming to SCCM.”

“SCCM isn’t part of System Center 2016.”


Rebooting device management

Starting with Windows 8, Microsoft began baking in a new management API that could be controlled independently of domain-based solutions like SCCM. Windows 10 includes enhancements to the API and adds a Linux-like package manager for software installs as well as runtime provisioning, removing the need for traditional imaging.

These are technologies for an MDM like Airwatch or Intune to plug into. It’s BYO and cloud-tech. Tech that lets businesses move fast and light. WMI and the standard SCCM tech is still there, but only as a bridging solution.

Given Microsoft’s focus on the cloud and enablement of technologies like Azure Active Directory (and being able to cloud-domain-join Windows 10 computers), I doubt they’ll continue investing in SCCM in its current form. If SCCM is your core skill set, I’d say you have 2-3 years of runway ahead of you.

My current money is on this scenario:

SCCM gets split and “goes away”. The device-focused tech gets rolled into the Intune platform and everything else gets shoved into the cloud-based Operations Management Suite, which is more server focused.

No more SCCM distribution points, no more impossible-to-find specialists, no more turning every dial. Oh, happy day.

Alternatively, SCCM winds up sitting in some weird middle ground where no one understands what it does or if they need it or not and Microsoft’s device management portfolio becomes an even more confusing mess than it currently is. This will incite an IT admin mob that chases SCCM through the village before cornering it and killing it with torches and pitchforks.

That, or the first thing. I’m fine with either.

Image Credit: Andee Duncan


When cloud isn’t cloud

“Your service is entirely cloud-based, right?”

“Yep. Absolutely.”

“So there’s no on-premise hardware? Nothing we have to build, deploy, or manage?”


I don’t know how many conversations I’ve had like this with OEMs and VARs selling cloud products that are only “cloud” in the loosest sense.  When they say “cloud” what they really mean is “hosted” or, in select instances – “hybrid”, either of which are OK, if that’s what you want.

Past the normal software connectors and API integrations you might expect in a cloud product, they have requirements for servers, internal network changes, and myriad other infrastructure items and config changes.

“You need to deploy this SSL certificate to every device.”

“You need to stand up 10 servers attached to your SAN.”

“You need to add these 35 records to your internal DNS.”

“Everyone needs to run IE 8 with Flash version 7 and JRE 2.”

“It only works on Windows… and Blackberry.”

Nope. Not gonna do it. You can take your product and go die in a fire.

Hybrid-cloud – I can get behind. There are some technologies and use-cases that require an on-premise component for at least a portion of their functionality. The client side of things, though, is where most integrators, OEMs, and VARs seem to fall off the rails entirely.

A big part of cloud is providing access to any device, anywhere – without reliance on a very narrow infrastructure config. If your product only works with one browser, requires five plugins, and four internal DNS records – it’s not cloud, but it is terrible. Before you say your service is a cloud service, be sure you know what that means.

Caveat emptor

If you’re on the buying side, it’s important to dive in to product functionality as much as you can before buying, especially if you’re trying to move away from on-prem and toward cloud and/or BYOD.

You need to go past asking “Does your product do X?” and ask “How does your product do X and what does it require to do that?” so you can gain the full picture of what you’re in for.

I’m not cynical enough to think that everyone selling a non-cloud “Cloud” product is trying to pull one over on their customers. In most cases, I think they’re just playing catch-up.

It’s surprising how common it is to find companies selling non-cloud “cloud” products and also doing something silly like selling white-box PCs. They seem to misunderstand scale, commodity, and technology agnosticism across a broad spectrum.

As much as you want to pat their salespeople on the head and say “Awww…who’s a big boy? You’re a big boy!”, it’s better to walk the other way.


Don’t ruin your vendors, dummy.

You did it. You rejected the status quo and took a chance with a startup instead of the established safe bet. Now you’re working with that new company to gear their product toward what your company needs.

Be very careful what you ask for.

Growing up

Companies, like people, are always challenged by who they want to be when they grow up. You can see this in startups as well as established companies like Microsoft and Cisco. You can watch those same companies flop around like dying fish when they’re struggling to define that vision. (Look at Microsoft over the past decade.)

Even single product companies have a lot of trouble defining themselves.

“Do we push for feature parity with our competition?”

“Do we throw a wide net or focus on a niche? Which niche?”

“Do we focus on growth and expansion or stabilize and boost margins?”

So on and so on.

Your responsibility

When you’re working with a vendor that’s trying to find itself, it’s important to keep these things in mind, especially when you start sending them your wish-list items. There are a few reasons this is worthwhile.

  1. You picked them for a reason. You made your pick because you liked that the new solution was simpler, smarter, faster, cheaper, etc. There was something you liked about them that you didn’t like about the safe bet. When you provide a laundry list of requested features and make comments like “Well, the other guys have that functionality.”, you risk turning that special startup into the monster you were running from.
  2. Your processes suck. Everyone has crappy processes, some more than others. When you start making hyper-specific requests based on an existing process, be cautious. You may be propping up your vendor to enable you to keep doing something stupid. Before you ask for something in this vein, really consider what you’re trying to accomplish.
  3. Constraints can be valuable. See above. Having a well defined box to work within drives creativity and innovation. Pushing your vendor to create an infinite sandbox will bog you down in ambiguity and choice paralysis. (*cough* SAP *cough*). Don’t believe me? Turn to your significant other and ask them “We can go anywhere in town for dinner. Where do you want to go?”
  4. You want your vendor to stay in business. When their product becomes bloated with features and they lose direction on what they want it to be, their marketing will become muddled and they’ll have a hard time making sales. Your random requests may be killing your darling.
  5. You’re scattering their resources. Three years from now when you’re asking your self “Their support really sucks now. I wonder what happened?”, the answer might be “you”. Every one of your implemented requests has to be built, integrated, documented, and supported.

You may be thinking “Well, isn’t it the vendor’s job to define their product?” Yep, it is. But if you want them to be around and be the awesome partner you hired them to be, you need to help. Very few companies have leadership who can maintain the laser-like focus they’re going to need to successfully mature, especially when every customer is asking them for the world. (There are very few 37Signals.)

This doesn’t mean you shouldn’t ask for improvements or features, it just means you need to be thoughtful about what you ask for. Each feature request has consequences that (you, and) your vendor might not be considering in their eagerness to please you.

Think of all the stupid things you were willing to do when you were young and really wanted people to like you. The startup you picked is just like your younger self. Help them to not be stupid.

Image Credit: James Provost


Infrastructure People – Learn to code or GTFO

Although it’s not always apparent to those I’m mentoring (Asking me for answers should not be your first step.), I like teaching. I like helping people work through problems and figure out how different components fit together holistically.

Lately, there’s been a particular point I’ve been trying to hammer home in almost every conversation I have – with junior sysadmins, college kids entering the field, and anyone else who will listen.

Regardless of your infrastructure specialty – networking, servers, storage, whatever – you need to learn to code.

Or you need to consider another line of work.

Batch script wizard

Part of gaining expertise is learning the scope of what you don’t know. I remember feeling like a fancy wizard when I started my career in tech – that I knew sooooo much. I could build computers from junk parts and troubleshoot through any problem set in front of me.

Then I met systems and network admins who knew how to script. They could craft batch and bash magic to effect change across the network. The scale of the world they worked within was so much larger than mine.

Suddenly, I felt like a caveman (Not even a smart caveman. More like Flurp, the slow, butterfly-chasing caveman.), clumsily bashing rocks against every problem.

Even simple batch scripts to map printers and install software were game-changing. All of those manual configurations I had been so proud of started to feel silly. I still feel a little of that when I browse through projects on GitHub.

Knowledge of scripting rapidly became a dividing line between tech jobs that paid minimum wage and those with upward potential. Batch (more Powershell now) and bash (more Ruby/Python now) became the foundation to launch a career from.

Code literacy

There are cases where a simple Python script can obviate hundreds of hours of work. Hiring managers know this and this skill set is now expected rather than being a “nice-to-have”.

“Take this server. Now make 1,000 friends for it.”

New expectations are forming around the interaction between infrastructure & applications and general automation. Within a few years there will be very little room in the industry for infrastructure-focused people who are not, at the very least, code literate.

This doesn’t mean you need to be able to build a consumer-ready application from scratch (although that helps), but it does require an intermediate-to-advanced understanding of scripting languages and/or a basic understanding of compiled languages depending on your company’s dev stack.

DevOps is here

What use is a sys admin who just points at the apps team and says “your code sucks” without even being able to read the code? Or a sys admin who is charged with designing infrastructure for an app he or she has no understanding of?

That’s why DevOps (the merging of infrastructure operations and development) has become such a big deal. Companies need their sys admins and programmers to be able to work together and at least have an idea of what the other person is talking about.

“Line 38 appears to reference an individual database server we took offline last week instead of the load balanced DNS name and knowing that this loop is working through this array, I probably gave the app servers too little memory.”

And in situations where an app is being scaled horizontally, the infrastructure has to be there to meet it – automatically. Clicking buttons in the Windows Server GUI is probably not going to get you there. Knowing how to script against the server command line or the platform services an app is running on will carry you a long way.

Additionally, why would a company hire 10 network admins to maintain equipment configurations when they could hire 2 who knew how to script against an equipment API? Be in the second group. Automate your configs and show your value.

It’s up to you

If you have no plans to build your skills past manual configuration, you are destined to work in small, boring environments if you’ll be able to find a job at all.

If someone can hack together a few lines of code to replace you, that’s your fault, not the merciless-robot-who-is-taking-your-job’s fault.

If you think “I can’t code. My brain isn’t built that way.” Spend 30 minutes working through exercises on CodeAcademy or any of the countless other coding tutorials online and you will find out that you are wrong.

This isn’t the requirement for five years from now. DevOps is here today. If you want to stay in the infra niche and be happy and successful, it’s time to fire up your text editor and learn a programming language.

Image Credit: Michael Himbeault