When it comes to working in IT, 00000001 is the loneliest number

Standard

I’ve been lucky enough to work in many different aspects of IT – from building gray box pcs and repairing printers to strategic, global decision-making.  As a reseller, from supporting 3-person Architecture firms to companies as large as Boeing and Isuzu.  There’s many, many factors that can make someone’s IT professional life difficult – but the number one challenge in our field is being the Lone IT Guy.

If your firm is in the 40 to 150 staff size range, there’s a good chance that you’re the only IT guy there.  Your firm may outsource to fill in gaps or do special projects, but at the end of the day, it’s just you.  One person acting as the focus for all the needs and demands from each employee – one person shouldering the responsibility for keeping the place up and running.

I know the perception is that we’re not the most socially adept guys to begin with – but anyone who has worked in IT knows that it is an incredibly collaborative environment.  There’s a concept in programming called Rubber Ducking – the simple ability to bounce ideas off of someone else, or to explain a concept to someone externally in order to better grasp it yourself.  That need for validation, for reassurance that someone else feels like you’re not going to blow the entire place up when you install Service Pack 8 is a huge step in creating a sense of confidence in your work.

There’s also the fact that IT – as a discipline – makes it *impossible* to become an expert in everything.  You’re great at Windows Server, Exchange, AD, Cisco VPN, TCP/IP?  Great.   How’s your skill level with linux, apache, mysql, php? Sharepoint? OCS with PKI?  And those are some of the most widely used technologies in our business – never mind the more obscure ones.  Every IT person brings something a little different to the table, something they’ve experienced in the past that helps them in the present.  How many times have you had a situation where the manual – or common wisdom – says to do it one way, but if you don’t also do step X, the whole thing falls apart?  When you’re on your own, there’s no immediate secondary source of knowledge to pull from.

The last issue is political.  When you’re on the carpet in front of Leadership for whatever reason – to request a day for maintenance – to pitch a new tech you think will help the firm – or god forbid, to buy something not in the budget – it’s just you.  You’re the sole champion for your request.  No one at your side to validate your pitch.  It can be tough to build a sense of confidence in those situations.

So… whaddya do?  In a nutshell, your options are limited.  But you can work to maximize the ones you do have.

First:  you’re an expert in Networks, right?  Network.  Although you’re an army of one, there’s thousands, if not millions, of virtual helpers out there.  Get *good* at Google searching.  Understand Boolean logic, eliminating common words, and the concept of near-ness.  Get an Experts Exchange account.  Join forums like (plug) http://www.aecit.com.  Do you have friends in IT?  Use ’em.  Are their local IT roundtable groups, either generic or specific to your industry/field?  Go to one of the meetings.  IT guys *love* to bounce ideas and experiences off each other.  And to brag about their newest gizmos. 🙂  Bottom line – force yourself to engage other professionals beyond just reading forum posts.

Second: that part about you being the only guy in the company that understands IT?  It is a double-edged sword.  Leadership has to trust your analysis and recommendations.  They may not agree with the outcome or may not authorize spending, but no one at the firm, besides you, is qualified to make technical decisions about your IT environment.  You need to leverage that.  I would *never* condone lying or using tech-speak to BS Leadership into seeing things your way – but if you have a valid argument, you need to present it in the best light possible, with all the gravitas you can muster that is associated with your role.  It is a tricky line – saying that the “Flux capacitor will unleash a cloud-based virus storm” if we don’t buy a new 11 x 17 laserjet – it might get you the printer, but undermine your long-term need to establish trust.

You probably have more pull than you think.  They have to trust you more than you have to trust them.  If you’ve done a good job there, you have a history of performance you can draw from.  And no one likes the idea of going out and finding a new IT guy when they like the one they’ve got.  This is very hard – but you need to work to make Leadership see you more as a peer when it comes to area-of-responsibility decision-making, and not the guy who hands out mice and keyboards.  Explain it like this – although the mundane stuff is part of your job – it is a small part – and primarily, your focus is making sure the company, as a whole, is able to execute without issue day after day.  That’s a strategic view, not a technical one.

Working alone in IT is not for everyone.  For personalities that love it – more power to you.  For those that find themselves liking IT, but hating the loneliness that can come from being the sole IT guy – consider joining a larger firm with a bigger IT staff.  You may not have the autonomy you had before – but you will have someone besides yourself to complain about it to.

Saying No in IT – When, Where and Why

Standard

I need to preface this by saying there’s two completely different dynamics that exist in the world of IT – inhouse (corporate) staff and VARs (value-added resellers).   Those differences manifest in many different ways, but none more distinct than the relationship with upper management.

As an outside party, you engage with IT senior leadership – but almost never with the actual company leadership. Your stakeholders are a fairly small group.  More importantly, they work with you on almost a peer level – since you’re usually not there to just do grunt work but to perform a function they are unable or unwilling to do themselves.  When the CEO passes you in the hallway, he means little more to you than any other user.

As a corporate IT staffer, though, that all changes.  In theory, every person higher up the food chain than you becomes a potential boss, or at least, someone who has the potential to make your life difficult.  C-level executives, VPs, etc, all take on an importance simply because of their rank.  In poorly led IT organizations, this can even impact your reporting structure or create a sense that others *outside* of IT management have firing or demotion capabilities.

As a reseller, saying No almost never happens.  There are few things in life that can’t be solved by the golden triangle – people, money and time.  However, these are the occasions when it should happen:

1) Unrealistic scopes of work.  Be it the goals, timeline, etc – never commit to doing something you don’t feel can be accomplished given the constraints.  You may have the attitude that things can change along the way, or halfway in the customer would be committed, but this is (in my opinion) unethical.  It is a far, far better thing to tell the client the negatives up front rather than halfway done.  For both parties.

2) Lack of technical expertise.  There’s as many technical solutions as there are grains of sand on the beach, and it is flatly impossible for a VAR to be versed in all of them.  The problem is that there is a natural propensity for clients to want to view you as a single-source for all solutions.  When you’re doing an Exchange install, and they say, “hey, can you do a Sharepoint deployment for me” – it’s a natural question.  And the dollar amounts make it very tempting.  But to take on that engagement – to say “yes, we can do that” – without having any exposure or experience in the product isn’t right.  And when the project goes sideways, your reputation takes the biggest hit.  The *only* time it is acceptable to engage like that is when you’re very up front about your experience with the client – and in these cases, coming down off your full rate would be appropriate.

3) Legal violations.  This is a tricky area.  We all know firms that bend the rules with software licensing.  The very best licensed firms I’ve seen still only fall in the 90% range (of percentage of legal software in use).  Where exactly you draw the line will differ based on your comfort level with the customer.  I personally refuse to procure, deploy or manage grossly under-licensed product.    It is one thing to put Adobe Acrobat on three computers – it is quite another to cheat the adlm system or to deploy torrented copies of Revit.

In all my years, on both sides of the fence, I’ve never seen a VAR fired for saying no to a request.  I have seen them fired for attempting to execute when they *should* have said no.

For internal staff, the waters get very murky, very quickly.  Much of your ability to say no will depend both on your position and the culture of your firm.  When I worked at a larger (8000 user) company, there really wasn’t the concept of “no”.  Orders came down the line (I reported to the Director of IT, under the CEO), and we followed them.  Orders we sent down were followed, or people got fired.  It was that simple.   You could raise concerns – voice your opinion – but there was no saying no.

Architecture firms – for better or for worse – don’t operate like that.  For whatever reason – from small firms to huge ones – the concept of a mandate, or top-down directed management is unheard of.  This of course creates significant issues for IT – but it does give you more flexibility when you do find situations – like these – that require a no:

1) Extreme risk or danger to data/systems.  These situations are rare, but at the bottom levels of the IT need pyramid – Antivirus, Backups, User Permissions – you as an IT professional need to feel a sense of responsibility that the safety levels are adequate.  If you are told by your boss “we don’t need A/V software”, or “lets not back up those project files” – you need to put up a fight.  There is nothing wrong with telling the CIO that the level of risk incurred by that decision is such that you feel the CEO should be informed of it.  If the CEO signs off – your fight is over, but you’ve fulfilled your responsibility by making the very highest levels aware of the risk.

2) Personal reasons.  In workplace environments, it would be rare that you don’t make the occasional enemy, or at the least, have users that you don’t care for.  In one situation, I had a C-Level executive that went out of his way to hurt the IT group, including lying on occasion.  However – when his IT requests came in – we handled them exactly like we would any other external request.  You cannot allow personal feelings or a user’s bad behavior to impact your service levels to the firm as a whole.

3) Abuse of your staff.  This can take many forms – from users cursing at your staff, to superiors using intimidation to get what they want, to requests to overwork them.  Your job – if you’re a manager – is to stop the crap from floating past you, and to stop the crap from raining down on your team.  It may not be easy having a discussion with a VP that their behavior is unacceptable – but you have to have it.  At the end of the day, you – and your group’s reputation – rely on your team members.  Nothing will kill morale quicker than the feeling that there’s no one above them looking out for their interests.

I’ll conclude by saying that in reality, saying No is extremely uncommon.  There are so many other ways to get the message across without saying the n-word.  I used to believe that not saying no – saying nothing to a request, or black-holing it – was worse than just saying no outright.  People will tell you they want a direct answer.  I don’t think I believe that anymore.  But I could be wrong.

And when you do say no, understand that it is the way you say it that will be absorbed more than the no itself.  Sympathize, empathize, seek alternatives together, offer a different solution, anything to defray the “no” word.  Your work – and your effectiveness – will benefit.

Clouds Ad Nauseum

Standard

There are days when I feel like if I hear the words “in the cloud” one more time, my head is going to explode.  From the Windows 7 lady using “the Cloud” to fix her photographs to “BIM IN THE CLOUD”, we’re completely over-saturated with Cloud-talk.  What makes it worse is that there seems to be a decent percentage of IT professionals who don’t fully understand what “the Cloud” is.  This post is an attempt to clear that up.

First:  “The Cloud” is a very generic term (like “Broadband”) that can describe many different technologies.  At its lowest common denominator, however, something in the Cloud means it is hosted elsewhere.  That’s it.  If it is not in your building, it is in the Cloud.  It is any resource that is hosted elsewhere, be it files, email, remote desktop, whatever.  That is the very straightforward and generic term.  Cloud computing grew from the concept of SaaS (Software as a Service) and extended it to include all and any types of resources.

So under the basic definition, hosted email is “in the Cloud”.  Users who access a Citrix server to run Revit are doing it “in the cloud”.  These resources can be hosted by third parties, or you can self-host at a colocation facility, and call it the Cloud, just to make it sound sexy.  You may as well, since Marketing folks slap the label on anything they can find.

Since the cloud definition is basically a resource being presented to you, the neat technology *can* come into play behind that presentation.  There’s a couple of key technologies that are intertwined with many cloud offerings.

The first is many-to-one resource presentation.  This can be either processor-based or storage-based.  Lets say you want a virtual server in the cloud.  The provider has the capability to utilize distributed computing to chain together many thousands of high-end servers, and then portion off the segment that you need or are paying for.  Again, it is about presentation.  While there may be 500 servers in the farm, all linked together, you’re only seeing a virtual one.  The same with storage.  A cloud provider with several thousand terabytes can slice and dice it however their customers need.

The second is dynamic, or elastic, resource allocation.  Let’s take Netflix, which uses Amazon Cloud services.  At 8 pm on a weeknight, they have huge needs for their streaming users.  On Sunday at 1 am, not so much.  So they can either build out a data center of their own, which must be sized to handle that peak capacity – although it may only be 12 hours a week – or they can purchase that processing power from Amazon on an on-demand basis, and only pay for what they actually use.  Amazon has software that dynamically allocates additional resources based on usage.  Netflix wins, because they’re not making a huge capital investment – assuming that Amazon provides adequate performance and reliability.

The third feature of cloud services is *usually* reliability.  Again, if you’re using something that is dynamically allocated, it usually means that if a drive fails or if a server dumps another can be brought online almost instantaneously.  But that presumes distributed computing – a single file server, with one hard drive, can be connected to the Internet and Marketing will put an “In The Cloud” sticker on it.

So the next time someone hits you with an “in the cloud” pitch, ask some questions.  Are they using distributed computing?  How elastic are they in terms of scaling? What is the resiliency level in case the application fails?  Are they really just using “Cloud” as a synonym for “Hosted” or “Software as a Service”?

As Chuck D. said:  “Don’t Believe the Hype”.

Is the iPad a potential PC replacement for your executives?

Standard

I’ll not wait till the end of the article; in a word, no.

Apple talks a *lot* about the “Post-PC World” – and they make some great points.  We all have those users, mostly in Senior Leadership positions, that are extremely light users.  They read their emails, surf the web a bit, and once in a great while will open a DWG for review.  They complain about the weight of their laptop, complain that it isn’t as cool as a Mac, and so forth.

And yes, the iPad does all those things.  On the surface, it seems like there’s a potential there to junk the desktop/laptop and move them to only having an iPad.  But for now, for the following reasons, the iPad will remain an accessory and not a laptop replacement.

1) Poor email support.  This is really manifested in two ways; first, the touchpad, while great for typing, is nowhere near as effective as a real keyboard.  Can you buy a keyboard for the iPad? Sure, but they’re not going to take it with them while travelling.  But the second, more important reason boils down to Outlook being a really great email client.  Right now, today, it doesn’t have an equivalent on the iPad platform.  With email being such a critical need at the executive level, it means the iPad is great for casual/quick email use, but not for primary use.

2) Safari/Flash.  We all have our personal browser preferences – some of you, by necessity, may even mandate use of IE.  But when it comes to favorites, there’s really only three main flavors – Chrome, IE and FF.  The most esoteric of you may even listen to a little Opera.  But Safari seems to be no one’s favorite, despite the pre-installation advantage.

The other knock here is the lack of Flash/Silverlight support.  We can have a healthy debate about why they’re not supported, but a *ton* of websites, possibly including your own intranet – require Flash or Silverlight support for proper use.

3) Lack of applications.  Yes, the iPad App Store has 350,000 apps, but half of them are Angry Bird knock-offs.  Sooner or later, the exec will ask for Application X that only runs on the PC so that they can open up a file that was sent to them.  And you won’t be able to give it to them.  This is especially true in the Architecture world with so many resource-intensive applications that require PC horsepower.

4) Not Microsofty enough.  Like it or not, we’re in a Microsoft world.  Especially as most of us are in the SMB space, and Microsoft is a convenient choice.  Yes, the iPad can open most Microsoft documents, and if you buy software, edit them as well.  But Microsoft makes a lot of products, and while the majors may be supported, fringe products – like Project, or Office Communicator – are not.

5) Read vs. Edit.  The iPad is a great Reading and Presenting tool.  When you ask it to edit, it struggles.  Simple things like copy/paste can drive you crazy if your fingers don’t do precisely what the iPad wants them to do.  Could you imagine an Architect redlining with his finger – for a document sent to the client?  Mouse support is really critical when you need to edit, and the iPad doesn’t have it.

At the end of the day, it’s a great idea.  Give someone a $700 box that is 1.3 pounds and does 90% of what they need it to do.  Unfortunately, until that remaining 10% gets filled, it will always be an accessory, and not a replacement.