SMB IT Journal

Corporate interviewers often forget that interviews are a two way street: yes the company is interviewing the hopeful job candidate but that candidate is interviewing the company as well.  Unless you are a wildly well known and highly desired company at which to work (e.g. Apple, Microsoft or Google) then you have probably little more than the interview process in which to demonstrate what kind of company you are to a potential candidate and even then many candidates will take the media’s opinions of working at those companies with a proverbial grain of salt.

No matter how fashionable or well respected the firm, most likely a job candidate will get one chance to peer into the inner workings of your company.  They will not judge you based on your cafeteria food nor on how friendly the staff is nor the lengthy, and probably completely inaccurate, job description – all of that is a form of marketing – a good candidate knows that and is exposed to it all of the time.  No, they will judge you based on your processes and the only process that you can’t gloss over, hide or fake is the interviewing process.

A company’s ability to interview effectively is the best cradle to grave process example that a candidate will see – very likely it will be the only one.  And since this is a process that affects all others, in that every person at the company was selected using it, it is also the best way to indicate to the candidate what the overall company is likely to be like and how it functions.  A good hiring process reflects a healthy company using good processes and possessing good staff, a bad hiring processes reflects a company with generally poor procedures and staff consisting mostly of those unable to find work someplace more attractive.

The hiring process is so often either complete afterthought or, at best, based completely around weeding out bad candidates that there is little thought put into convincing good candidates to accept a position at the firm.  The better the candidate the more likely that that candidate is already working and getting offers from more than one company.  The interview process must often convince a candidate that the unknown of your company is better than their existing, known position and that it is better than the unknowns of potentially many other firms.  Overcoming the “devil you know” issue can be very difficult, especially if that candidate already has a great job.  Ask yourself, “If I had their job, why would I leave it to come work for me?”

Vetting a potential candidate is not something that interviewers and the hiring process creators are likely to forget or overlook, but focusing so heavily on ruling out bad candidates will often also tell good candidates that this isn’t a place where they are interested in working.  Good candidates don’t want to work in a place lacking bad people, they want to work in a place full of good people.  The two are not the same thing.

Having a good, efficient and goal-oriented interviewing process can be difficult, especially if your firm is large and follows traditional interviewing practices in a codified manner.  There is no simple equation to running a great interview process, what every company’s technical needs and cultural needs are will dictate how best to approach enticing the best fitting candidates.  There are simple rules, though, that must be followed.

Every potential candidate that you will ever interview is full of horror stories from their own job hunts over the course of their careers.  Some are nearly universal, such as stories about how the human resources department sabotaged an otherwise perfect fit position, while others are unique and surprising.  Anyone that you will be interviewing will be thinking about their own past experiences as well as stories that they have heard from others and will be thinking about these things as they go through your company’s process.  Most process issues can be resolved, or at least mitigated, simply by taking the time to empathize with the candidates and see the process from their perspective.

Running a good interview process can start with the simplest of things like making sure that the team preparing to interview a candidate are on time, prepared for the interview, the appropriate people for that interview, aware of what they are interviewing for, etc.  Too often candidates go to an interview just to find that they are being interviewed by random people in the office who just happened to be available.  Those interviewers have not seen the resume ahead of time nor are aware of the qualifications that they are seeking.  You would not be impressed if the candidate being interviewed was late and unprepared, why are we then surprised if they are equally unimpressed when we are unprepared.  We can hardly fault a candidate for not taking the interview seriously if we are not taking it seriously, but this is exactly how the average interview goes – the candidate is far more prepared than the interviewing team.

Human resources presents one of the most well understood failures in the interviewing process.  HR is seldom prepared to speak to a potential candidate in any meaningful way in the information technology arena.  Rarely, if ever, is HR in a position to judge a candidate’s skillset, skill level, ability to mesh with a team or appropriate compensation.  HR could be involved for verifying resume data or supplying benefits details, of course, but only after a candidate is otherwise selected.  Every IT professional can spot a job description that HR has touched and great candidates turn down your firm at this stage, long before they ever show up in any statistic.  You are losing potential employees, the best potential employees, before you ever find out that they were giving you a moment of their time.  You may also accidentally turn away candidates who would happily have accepted a position with your firm but were misled into believing that they were not qualified for a position due to nothing more than an incorrect, often impossible, job description.

It is important, too, to have a generally well laid out and efficient process to move from one interviewing stage to another and to do so, from end to end, in a relatively short period of time.  I myself have had poorly planned interviewing processes that stretched for longer than six months.  In these cases the people involved will often change positions, or even companies, during the process and the same stages might get repeated over and over with the interviewing company not remembering the candidate or what had been said and determined in earlier interviews.  If an interviewing process spans more than about a week the process is too long and the stages are too disconnected.  Decisions should also come in a timely manner, not weeks after an interview has taken place.

The interview process should be designed around the desired candidate traits.  If you want to hire someone to just hit the ground running and have no long term viability, focus purely on tech skills.  If you want someone to be a part of the team, focus on personality and just make sure that they can learn the tech skills in an amount of time that is appropriate for your needs.  If a position is important enough to hire someone to fill, it is important enough to interview well to get the right person.  Hiring a new staff member is a very big deal, nothing defines your company more than the people that it hires.  Nothing should be taken more seriously than the processes used to acquire the best staff.

Communications between interviewers and stages is important.  An interviewee will not be impressed if asked the same question multiple time, especially not if asked by the same person.  This is far more common than interviewers may realize.

Put yourself into the shoes of your candidates.  Think about how they will see your company when they interview with you.  Will they see an organization that treats them with respect and professionalism?  Will they see you as prepared and highly skilled?  Will they see processes that encourage the kind of people that they want to work with to join your firm?  Or will they see that your company thinks that hiring good people is not a priority?  Will they find that their future coworkers aren’t the cream of the crop and that they aren’t being hired to compliment good people but to provide skills that you have failed, thus far, to cultivate?  Will they see processes designed to weed out bad people but that fail to attract good ones?

Interviewing processes do not need to be exceptionally formal or rigid.  Alternative approaches can work wonders and can tell a candidate much about your company.  But make sure that any process that you implement reflects positively on your firm and is not turning away the candidates that you might wish to hire.

No matter how much you imagine that candidates should be beating down your doors to come work for you – those candidates don’t know that.  Until you convince them otherwise, you are just another unlikely job prospect to them in an endless sea of job listings – unlikely that they will get an offer and unlikely that they will accept one if received.  Job seekers are inundated with job listings and head hunters daily.  Most companies that a candidate will decide to interview with will turn out to not even really be hiring but are just “fishing” – looking to see what the candidates and going compensation rates are like in the current market.   A candidate is not going to get excited until they feel that you are a serious firm and that the job sounds exciting.

Interviewers generally approach candidates with the impression that the candidate is begging for the position and that they are charged with turning away all but the best option.  But there is a very good chance that the person that you are interviewing was cajoled or begged (or even bribed) to sit across that table from you by a headhunter, consulting or staffing firm.  Often they’ve been lead there under false pretenses, such as being told that compensation is as much as double what is actually your realistic cap or that they will be in a far more senior position than you are interviewing for.  In that person’s eyes it is you the interviewer, not they the interviewee, who is in the begging position.

If a candidate is brought in by a staffing firm then chances are that that candidate has been presented with a very different view of the situation than you expect.  Likely they have been told great and unrealistic things about the position and they see that staffing firm as the direct and official representative of your firm – which if you have hired them, they are.  So you are effectively reaching out to candidates, pre-selecting them and asking them to come interview with you.  To the candidate, they are doing you the favor, not the other way around.  If they show up and you are not ecstatic that they took the time out of their schedules to meet with you they are going to be less than impressed.  They assume that you have sifted through large numbers of candidates and selected them for a reason.

Using a staffing firm is never advised, in my opinion.  They do not represent the interests of you as the hiring company nor of the candidates.  They, at best, are a point of miscommunications and increased cost.  At worst they play both parties against each other for their own gain.  Like an HR department, they have very little to add to a selection process but have the capacity to wreak nearly unlimited damage.  The best companies, no matter what size they are, take the time to make their hiring process a purely internal one.  No matter what type of business you are in, the ability to attract, acquire and retain the best staff is the best competitive advantage possible.  If your hiring process isn’t taken seriously there is no way that you can compete  cost effectively.  Your only option is to raise salaries to a point that enough candidates concerned about money over job quality are willing to come work for you.  This can work but is very expensive, and not completely effective, compared to having great hiring practices.

The bottom line is that your hiring practices dictate what you are and will become as a company.   If you don’t acquire and develop good staff you won’t have them to drive efficiency and innovation.  Take your hiring process very seriously and consider how your company presents itself to a candidate.  Remember, weeding out bad people is easy.  Attracting good ones is hard.

My sister in law once asked me why they have so many computer problems and we do not.  My wife and I are both technology consultants and our home network probably seems incredibly stable to the casual observer.  This question, in one form or another, comes up pretty often.  I thought about it at length and feel that there are really a number of common factors that are pretty common to find differing between how the average IT professional sets up their home computers (as opposed to their work computer) and how the average user does.  Not every IT pro does these things and not ever non-IT person does not, but these are pretty common differentiators that all factor in to stability of the home computing environment.

1. We Don’t Log In as the Administrator.  This is probably the single biggest difference between normal users and IT professionals at home.  Running as the administrator for every day computing just isn’t wise – any malicious or misbehaving application will be able to be malicious with your user privileges, which as the administrator are unlimited.  I have been working in IT for over twenty years and would never use the administrator account for anything but system maintenance tasks.  It just isn’t safe.  The entire purpose of having these different types of accounts is for your protection.
2. Keep the System Patched. A patched computer is, more or less, a safe computer.  Those patches that come out from Microsoft, Apple and your application vendors are there for a reason – because a problem has been found and they want to get it fixed before something bad happens to you and it is their fault.  Once a patch is released, you need to get it installed right away because the security hole that it patches is now public knowledge and you are particularly vulnerable in the time right after the patch is released.  Nearly anytime that I log onto someone else’s computer the first thing that I notice is that there are a large number of security patches waiting to be installed.  Never let this happen – patch immediately.
3. Use AntiVirus and Software Firewall.  Running a good antivirus (there are plenty of free ones for home users) is quite important as is having a firewall on your computer.  AntiVirus helps your computer protect itself against known attacks and will look for dangerous files on your computer that may have been downloaded, found on removable media, on a website, etc.  In theory, if you are not the administrator and are well patched viruses will be able to do only limited damage, but any damage you can prevent is a good thing.   A software firewall on your computer is an added layer of protection as well – for home users it is pretty minor but it is free and you should never turn down valid protection.
4. Use a Real Firewall.  A software firewall on your computer is not enough, you should always have a real, hardware firewall as well.  This does not have to be an expensive device and you will often need one for other purposes anyway – such as sharing your Internet connection with multiple users – just make sure that you have one installed.  This is far more important than having a software firewall but neither is an excuse for not having the other.  You need both.
5. Never Use the Pre-Installed Operating System.  This is one of those “tricks” that IT pros learn after working on many, many machines.  Computers come with a pre-installed copy of the operating system on them.  This pre-installed copy normally is loaded with horrible software that you would never, ever want to have installed on your computer and is often just trials of software that you will have to buy to use.  You don’t want this.  Instead, take the operating system installation media that came with your computer (you didn’t buy a computer without it, did you?) and install a fresh copy of your operating system without any of that additional stuff before you do anything with that computer.  This is important for two reasons: first that you eliminate all of that useless advertising that might even go so far as to break your computer and second it gives you a basic install that you can repeat later, which is important.
6. Reinstall the Operating System Periodically.  Over time, on Windows especially, you will notice a deterioration of your computer over time.  Except in the cases of hardware failure, this is caused by a sprawl of data, settings, registry changes, etc. on your hard drive.  There are techniques for fixing this but none are perfect.  From time to time, often once every one to two years, it is very advantageous to blow everything away and install the operating system fresh (as in the tip above) and start over with a “new” computer.  As long as the hardware has not begun to fail your computer will now behave exactly as it did the day that you got it.  (Do not forget to patch it immediately.)  This also gives you the very important chance to reinstall only those applications that you actually need and use and leave unused ones behind (along with any malware that has found its way onto your system.)
7. Have a Spare Computer.  It is a rare IT professional who relies on a single desktop or laptop for everything that they do.  There is too much riding on the ability to be online, all the time to only have one computer.  The slightest hiccup and you are unable to do anything – including unable to look up what you need to know to fix your computer!  Having a spare computer means that you have another computer to use while you are busy reinstalling the operating system on your main computer, for example.  It also gives you a secondary location from which you can verify that all of your critical data is still available while working on your main machine which is some serious peace of mind.
8. Take Good Backups.  Nothing is more important to IT professionals than backups.  Backups are what keep us in business.  Most likely these days you will find IT pros not only have an external hard drive (or better, an actual storage server) in their homes on which they keep complete copies of everything that matter to them but also that they have online backups going to a cloud storage provider so that should their home be lost (flood, fire, tornado) that they would still have their precious files.  Losing your photographs, home movies, financial records, etc. can be quite tragic – take steps to protect these.  If you do it right, you should never fear your computer dying beyond the slight annoyance that it takes to install your operating system again.
9. Don’t Install Just Anything.  What you install and run on your computer matters.  IT professionals are generally pretty wary of what they install and normally only install known applications from trusted vendors – not any random piece of software that is found on the Internet.  It is important to know what you are installing and why you want it.  The average computer user, IT pros included, actually need very few different applications on their computers.  The fewer you install the fewer you need to maintain and the less chance that you will have one that damages your system or slows it down.  Often when helping non-IT professionals with their computers I find that the computers are full of applications that no one has ever heard of and the person whose system has them installed has never really used or may not even know what they are!  This is how the bulk of malware gets installed.
10. Download Drivers, Don’t Use Vendor CDs.  IT Pros know that drivers are critical to system stability and that the latest are available from vendor websites.  Any CD with a driver for a new piece of hardware that you just bought is pretty much guaranteed to be out of date and, more often than not, the vendor will use the opportunity of you putting their CD into your drive to install extra software that you don’t want onto your computer.  Avoid this completely; use the vendor website to get the latest drivers immediately and don’t use the media that comes with your hardware.
11. Buy Commercial, Not Consumer, Equipment.  I’ve written whole articles on this in the past – this is one of those industry insider tricks.  In business, we look for computers to be stable and reliable, not flashy and “cool”.  Nothing is cooler than a computer that works reliably.  Big computer vendors make one line for consumers to be sold at your local store and another line for discerning companies who do their homework.  Skip the in-store buying.  Go directly to the big vendors (don’t even think about buying something made by the guy down the street) and stick exclusively to their commercial or business lines.  These lines are built for buyers in the know who need their computers to be cost effective over their lifetimes, not to be cheap up front.
12. Have a regular maintenance routine.  There are simple tasks that need to be done all the time such as defragging your drives, cleaning up unneeded files and blowing the dust out of your machine.  IT pros regularly maintain their computers to maintain system health.  Computers are not just “set and forget” devices.  They are just too complex for that.  That being said, though, most tasks can be automated.
13. Run wires.  Wireless networking is simple, clean and easy.  It is also slow and difficult to troubleshoot.  When possible, consider running cabling in your home so that your computers, at least the desktops, game consoles and other stationary devices, can get the speed and stability advantages of cabling.  The more devices on your cabled network also means the fewer devices that will be competing for wireless resources.
14. Use a UPS.  A UPS, or uninterruptable power supply, is a crucial component in protecting your computer equipment.  It protects computers from disruptions and surges in the power grid.  Computers are very sensitive to power problems and an inexpensive UPS can go a long way to keeping your computer healthy for a long time.  More importantly, it protects against data loss.

The basic tip here is – treat your home like a business, not like a toy.  The average home user doesn’t take their computer seriously at all and never gives it a second thought until something goes horribly wrong – and then it is likely too late.  Your computer is one of your most expensive and most important possessions, treat it more like a car and less like a toaster.

As IT managers we face the need to deal with two very different types of technical professionals.  These two types of professionals are separated, not by their personality types or working styles, but by the very nature of their job roles.  Understanding the unique needs of these two job types is critical in effectively managing technical workers, but few IT departments truly take the time to understand and appreciate the nuances inherent to these two different job roles.

The first type, and by the far the best understood, I will call the “engineer.”  This engineering role encompasses a massive array of job functions ranging from software developers and designers, architects, system engineers, network engineers or anyone whose primary function is to creatively design or implement new systems of any sort.  The term engineer is a loose one but is relatively meaningful.

The second type of technology worker role can be generically referred to as the “support” role.  Support professions might include helpdesk, systems administration, desktop support, network monitoring, command center, etc.  What separates support professionals from engineering professionals is that they are not tasked with creative processes involving new designs or implementations but instead work with existing systems ensuring that they run properly and get fixed quickly when something is wrong.

It goes without saying that no one real-world human is likely to ever be completely in only one category or the other, but almost all job functional in IT focus very heavily upon one or the other.  It is pretty safe to assume that almost any role will be exceptionally weighted to one role or the other.  It is very rare for a single position to be split evenly between these roles.

Where this identification of roles comes into play is in knowing how to measure and manage technical staff.  Measuring and managing engineers, from a very high level, is quite well understood.  The concept of productivity is very simple and meaningful for engineering roles.   The goal of managing an engineering person or team is to allow and encourage that role to output as much creative design or implementation as possible.  The concept of quality exists as well, of course, but we still can think generally about engineering roles in relatively concrete terms such as number of functions written, number of deployment packages produced, size of network designed, etc.  Metrics are a fuzzy thing, but we at least have a good idea of what efficiency means to an engineer even if we cannot necessarily measure it accurately.

Support roles do not have this same concept.  Sure you could use an artificial metric such as “tickets closed” to measure productivity in a support role, but that would be very misleading.  One ticket could be trivial and the next a large research challenge.  In many cases there may be no tickets available for a long time and then many arrive at once that cannot be serviced simultaneously.  Productivity is likely to be sporadic and non-sustainable and, ultimately, not at all meaningful to measure.

Engineering positions earn their keep by producing output effectively over a rather long period of time often even spanning into months and years for large projects.  The goal, therefore, with engineering positions is to provide an environment that encourages sustainable productivity.  It is well know that engineers will often gain productivity by working shortened or alternative hours, taking regular vacations, etc.  Not only does this often increase productivity but often greatly increases the quality of the output as well.

Support positions earn their bread and butter by “being there” when needed.  If a support person is attempting to work at maximum efficiency there is a natural implication that there is a continuous backlog of support issues awaiting the support team’s attention and that there are many people requiring support who have to wait for it in order to form a queue.  By having a queue always in place this also means that support personnel are continuously taking work off the stack instead of resolving live items – either ignoring high priority items or being regularly interrupted – causing continuous context switching which significantly reduces the ability to efficiently handle the queue – whose entire purpose for existing was to create the appearance of artificial productivity in the first place.

Support roles are “event driven.”  I like this terminology because I think it most accurately describes the mode in which nearly all support professionals work.  Whether an event is generated by a phone call, an instant message, an email or a ticket it is an “event” that kicks off the transition of the support person from idle to action or, in some cases, from a low priority item to a high priority item.  One way or another, an event represents a “context switch” for the support professional.  Without an event there is nothing for a support professional to do.  Even if the “event” is represented by a ticket queue or an email backlog it is still a form of event.

Having a truly efficient support desk requires careful management of the event process.  Having a never ending queue of support issues is exhausting for the support professionals and it also means that no amount of staff is ever in an “idle” state awaiting high priority items.  Because of this, high priority items are either not addressed as quickly as they should be or else in-process items are neglected.

Understanding the event driven nature of support staff is critical to understanding how to approach the management of these teams.  There are no simple answers, and metrics of support staff are often even more meaningless than those of engineering staff – so use with extreme caution, but by empathizing with the support role we can begin to see where our role as a support manager plays into the bigger picture of supporting and promoting the support team members.

The most important concept, from my experiences, is providing a good flow of the interrupts going to the support team.  Often support teams are handling a number of different avenues for support, such as email and telephone.  Restricting and funnels events to appropriate channels is critical.

The problem with telephones is that they are aggressive and demand an immediate context switch whether the recipient is idle or if they are currently supporting the most critical production outage in corporate history.  The person calling is guessing that their immediate need outweighs the current needs of whomever the support person is currently supporting.  Telephones cause this problem everywhere that they are used.

Think about the last time that you were at a pizza parlor placing your order at the counter.  You waited in line patiently as each person was served.  You did the right thing.  You arrive at the front of the queue.  You begin to place your order when, the phone rings.  The person taking your order puts you on “hold” even though you are standing right there, picks up the phone, takes the order, hangs up and returns to you.  What this says is that the person calling, being the “squeaky wheel”, is more important to the restaurant than are the people actually in the restaurant.  This same effect happens on many support desks – in process work is interrupted by calls going to a group line or directly to the support person.  This is, at best, inefficient and at worst may disrupt critical support processes for highly critical issues.

So when thinking about how to manage IT professionals, think about the purpose of their role.  The goal of an engineer is productivity.  The goal of a support professional is availability.

A question that comes up on a pretty regular basis is whether or not servers should be routinely rebooted, such as once per week, or if they should be allowed to run for as long as possible to achieve maximum “uptime.”  To me the answer is simple – with rare exception, regular reboots are the most appropriate choice for servers.

As with any rule, there are cases when it does not apply.  For example, some businesses running critical systems have no allotment for downtime and must be available 24/7.  Obviously systems like this cannot simply be rebooted in a routine way.  However, if a system is so critical that it can never go down then this situation should trigger a red flag that this system is a point of failure and perhaps consideration for how to handle downtime, whether planned or unplanned, should be initiated.

Another exception is some AIX systems need significant uptime, greater than a few weeks, to obtain maximum efficiency as the system is self tuning and needs time to obtain usage information and to adjust itself accordingly.  This tends to be limited to large, seldom-changing database servers and similar use scenarios that are less common than other platforms.

In IT we often worship the concept of “uptime” – how long a system can run without needing to restart.  But “uptime” is not a concept that brings value to the business and IT needs to keep the business’ needs in mind at all times rather than focusing on artificial metrics.  The business is not concerned with how long a server has managed to stay online without rebooting – they only care that the server is available and ready when needed for business processing.  These are very different concepts.

For most any normal business server, there is a window when the server needs to be available for business purposes and a window when it is not needed.  These windows may be daily, weekly or monthly but it is a rare server that is actually in use around the clock without exception.

I often hear people state that because they run operating system X rather than Y that they no longer need to reboot, but this is simply not true.  There are two main reasons to reboot on a regular basis: to verify the ability of the server to reboot successfully and to apply patches that cannot be applied without rebooting.

Applying patches is why most businesses reboot.  Almost all operating systems receive regular updates that require rebooting in order to take effect.  As most patches are released for security and stability purposes, especially those requiring a reboot, the importance of applying them is rather high.  Making a server unnecessarily vulnerable just to maintain uptime is not wise.

Testing a server’s capacity to reboot successfully is what is often overlooked.  Most servers have changes applied to them on a regular basis.  Changes might be patches, new applications, configuration changes, updates or similar.  Any change introduces risk.  Just because a server is healthy immediately after a change is applied does not mean that the server nor the applications running on it will start as expected on reboot.

If the server is never rebooted then we never know if it can reboot successfully.  Over time the number of changes having been applied since the last reboot will increase.  This is very dangerous.  What we fear is a large number of changes having been made, possibly many of them undocumented, and a reboot then failing.  At that point identifying what change is causing the system to fail could be an insurmountable process.  No single change to roll back, no known path to recoverability.  This is when panic sets in.  Of course, a box that is never rebooted intentionally is more likely to reboot unintentionally – meaning the chance of a failed reboot is both more likely to occur and more likely to occur while in active use.

While regular reboots are not intended to reduce the frequency of failed reboots, in fact they actually increase the occurrence of failures, the purpose is to make those failures easily manageable from a “known change” standpoint and, more importantly, to control when those reboots occur to ensure that they happen at a time when the server is designated as being available for maintenance and is designed to be stressed so that problems are found at a time when they can be mitigated without business impact.

I have heard many a system administrator state that they avoid weekend reboots because they do not want to be stuck working on Sundays due to servers failing to come back up after rebooting.  I have been paged many a Sunday morning from a failed reboot myself, but every time I receive that call I feel a sense of relief.  I know that we just caught an issue at a time when the business is not impacted financially.  Had that server not been restarted during off hours, it might have not been discovered to be “unbootable” until it had failed during active business hours and caused a loss of revenue.

Thanks to regular weekend reboots, we can catch pending disasters safely and, thanks to knowing that we only have one week’s worth of changes to investigate, we are routinely able to fix the problems with generally little effort and great confidence that we understand what changes had been made prior to the failure.

Regular reboots are about protecting the business from outages and downtime that can be mitigated through very simple and reliable processes.

It is an old story in SMB IT, IT managers who get their start young, stay with a single company, work their way through the ranks and become venerable IT managers who have never worked outside of their current environment.  Just like the “good old days” when people stuck with a single company for their entire careers, this too sounds like a wonderful thing.  But IT has long rewarded “job hoppers”, those technically minded folk who move from shop to shop every few years.  The lack of direct upward mobility within single shops has encouraged this process – incremental promotions could only be found between companies, seldom within a single one.

Some people support and some people dispute the idea that there is value, or significant value, to be had by changing companies.  The idea is that by moving between environments you will glean techniques, procedures, processes and general experience that you will then bring with you to your next position – that you are a cumulative product of all of your past environments.  This concept, I believe, has some merit, moreso in technology than in other fields.

In technology fields, I believe that the value of moving between jobs, after a reasonable amount of time, is generally of much better value than is staying put.  The reason for this is relatively simple: Most small businesses lack an ecosystem of support and training for IT professionals. It is well known that IT professionals, working in small shops, lack the interaction with peers and vendors generally accepted as necessary for healthy professional development and which is common in enterprise shops.

An IT professional, after spending many years in a small shop, effectively all alone, tends to feel isolated lacking the professional interaction that most specialists enjoy.  Most small professional or artisan shops have a number of specialists who work together, share research and experience, are encouraged to work with competitors or vendors, to attend trade events, training, etc.  Few fields share the odd dispersion of IT professionals with only one or two people working together at any given company with little to no interaction with the outside world or with peers at other companies.

This isolation can lead to “IT insanity” if left unchecked.  An IT professional, working in a vacuum with little to no technical or professional feedback, will lose the ability to assess themselves against other professionals.  As often the sole provider of technology guidance and policy for potentially years or even decades, a lone IT professional can easily “drift off course” and lose contact and course correction from the larger IT field with only light guidance offered through the filtered world of vendors attempting to sell expensive products and services.

IT professionals suffering from “IT insanity” will often be found implementing bizarre, nonsensical policies that would never be tolerated in a shop with a strong peer-review mechanism, purchasing incredibly overpriced solutions for simple problems and working either completely with or completely without mainstream technologies – mostly dependent upon individual personality.  Partially this is caused by an increasing dependence on a singular, established skill set as the lack of environmental change encourages a process of continuing dependence on existing skills and procedures.

IT insanity will commonly arise in IT shops that have only a single IT professional or in shops where there is a strict hierarchy with no movement at the management ranks so that fresh ideas and experience from younger professionals do not feed up into the managers and instead established practices and “because I said so” policies are forced down the chain to the technologists actually implementing solutions.

This is not to say that all is lost.  There are steps that can be taken to avoid this scenario.  The first is to consider outsourcing IT – any shop so small as to face this dilemma should seriously consider if having full time, dedicated internal staff makes sense in their environment.  Looking for fresh blood is an option – getting IT professionals from other shops and even other industries can work wonders.  Some shops will even trade staff back and forth in extreme cases to keep from losing existing employees but seeking to “mix things up.”

Short of drastic measures such as changing employees entirely, non-IT organizations need to think seriously about the professional health of their staff and look to opportunities for peer interaction.  IT professionals need continuous professional interaction for many reasons and organizations need to actively support and promote this behavior.  Sending staff to training, seminars, peer groups, conventions, shows or even out as volunteers to non-profit and community activities where they can provide IT support in an alternative environment can do wonder for getting them out of the office and face to face with alternative viewpoints and get their hands on different technologies than they see in their day to day lives.

IT managers need opportunities to explore different solution sets and to learn what others are doing in order to best be able to offer objective, broad-based decision making value to their own organizations.

The IT world loves to swing back and forth between moving processing out to the user via fat clients and moving processing back to the server leaving users with thin clients.  The battle is a long running one that started with the first appearance of multiuser computer systems several decades ago and has continued to this day and will likely continue for a very long time to come.

When I began working in IT, thin clients were simple text terminals attached to a single, central server via serial connections.  Limited to very basic text input these served their purpose at the time to provide relatively low cost computing to a large number of users.  The system wasn’t pretty or glamorous, but it was quite functional.

These ancient terminals gave way to the personal computer and computing power shifted from the datacenter to the desktop allowing users to run powerful apps like Lotus 1-2-3 and WordPerfect.  Responsive graphical applications were a powerful draw for decentralized processing.  Users were enthralled with the new usability.  The text terminal went into very rapid decline.

Eventually centralized power was available in such quantities and at such a low price point that graphical applications could be run with almost as much responsiveness from the server while clients could be “thin” needing just a shim of an operating system – enough to provide remote access back to the server.  Thin computing became the darling of the industry again and the term itself arose and moving towards centralized processing again came into vogue.

Administrators love the central computing model because data and configuration remains in one place.  Backups and management are a breeze.  The idea, at least in theory, is that in doing so desktop support becomes a non-issue with all desktop clients being nothing more than commodity components that can be replaced anytime with completely interchangeable parts.  Since nothing is stored or configured on the desktop there is nothing to support there.

In the initial swings of the “thin computing pendulum” the market movement was dramatic.  When text terminal computing first became available this was practically the only model used in the real world.  The value was so dramatic that no one could really justify doing anything else.  When the PC was introduced the movement to the fat client was so ubiquitous that many younger IT professionals today have never actually seen text terminals in use even though the move to fat “PC” clients was not as all encompassing as the move to text terminals had been one pendulum swing previous.

The PC model was generally better for end users because it mimicked how they used computers at home – those that had computers at home.  It also gave them more options for customization and, for better or for worse, opportunity for them to begin installing software of their own rather than only that software preconfigured for them on the central server.

Over time there have been a lot of developments from both camps giving each more and more advantages of the other.  Central domain services such as Microsoft’s Active Directory have come along allowing central management to extend out to fat clients bringing control and management more in line with traditional thin computing models.  Likewise, companies like Citrix have worked very hard developing new technologies that allow thin clients to perform much more like robust fat clients making their use as seamless as possible for end users and even making offline use possible for laptop users.

Most shops today have adopted hybrid models.  Fat clients where they make sense and thin clients for certain categories of users and for remote workers and continuity of business scenarios.

Over the past decade we have seen a shift in the way that business applications are created and deployed.  Today almost all business applications are web-based and have no client platform dependency.  This affords IT departments of today with a potential new opportunity – to shift from a traditional thin client platform – that requires remote graphical access – to the browser as the new thin client platform.

The move to web apps has happened slowly and most businesses have a rather large legacy codebase on which they are quite dependent that cannot be easily transferred to the new web app architecture and some apps simply are not good candidates for this architecture.  But by and large the majority of new business applications are web based, written most often in Java or .NET, and these apps are prime candidates for a new thin computing model.

If our custom business apps are available via the browser then our only commonly used apps that remain holding us back are the traditional productivity apps such as our office suites that are widely used by nearly all staff today (if they have a computer at all.)  Very few desktop apps are actually pervasive except for these.  Increasingly we are seeing browser-based alternatives to the traditional office suites.  Everyone is very aware of Google Apps as a pioneer in this area with Microsoft now offering online MS Office as well.  But the popular offerings making consumer news headlines require businesses to totally rethink long term strategies involving keeping critical business data within their walls and are not likely to be highly disruptive to the enterprise for quite some time.

What does pose a threat to the status quo is other alternative software products such as ThinkFree office which is installed within the organization and used and secured internally just like any other normal business application.  This category of “traditionally installed internal web applications” will allow enterprise IT departments to begin to reconsider their end users’ platforms without having to reevaluate their entire concept of IT in general.  The biggest barriers to this today are lingering business applications and power users using specific desktop apps that cannot be encapsulated within a browser.

One of the great advantages, however, of the browser as the new thin client is how simple it is to mix browser-based apps with traditional apps.  The move is transparent and most large businesses are moving in this direction today even if there is no overarching strategy to do so.  The market momentum to develop all new apps for the web is causing this to happen naturally.

Another key advantage of a completely “web based” architectural model is the great ease with which it can be exposed for users outside of the corporate network.  Instead of using cumbersome VPN clients and company laptops employees can find any web browser, sign in to the company network and have secure business applications delivered to any browser, anywhere.

Bringing this almost unnoticed shift into sharp relief today are a handful of, of all things, consumer devices such as: Apple’s iPhone and iPad and Google’s Android and ChromeOS platforms.  What all of these devices have in common is a focus upon being primarily thin web appliances – thin clients for consumers.  With the majority of consumer computing focused upon web connectivity the need for anything else from a platform is nearly non-existent in the consumer market.  This means that within a very short period of time users who once brought home PC experience to the office as their expectation of a computing environment will soon be beginning to bring web-based thin computing as their new expectation.

When this shift happens IT departments with need to rethink their internal application delivery strategy.  The change doesn’t have to be dramatic if current development trends are used commonly and legacy systems are routinely updated.  In fact, one of the great benefits of this new model is that traditional fat clients function very well as browser platforms and will do so for a very long time to come most likely.  Companies adopting this model will likely be able to slow desktop purchasing cycles and prepare for purchasing some form of traditional thin client with embedded browser or move to a business version of the new Nettop trend that we are beginning to see emerge in the consumer space.  Some businesses may even attempt the rather dangerous path of using consumer devices but the lack of management and security features will likely keep this from being popular in all but rare instances.

I believe, though, that this swing of the pendulum will not be as dramatic as the last one just as it was not as dramatic as the swing before that.  It will be an important trend but IT departments understand more and more that no new technological shift is a silver bullet and that with each new opportunity comes new challenges.  Most IT departments will need to implement some degree of browser-based thin computing over the next few years but most will retain a majority user base of fat clients.  Hybrid environments, like we’ve seen for many years with more traditional models, will continue as before with each technology being used in target areas where they make the most sense.

The one area where thin clients continue to be challenged the most is in mobile computing where disconnected users end up being digitally marooned away from their company networks unable to continue working until network connectivity is reestablished.  This is a significant issue for power users who must travel extensively and need to be able to continue working regardless of their current connectivity.  Today this is being solved in the traditional thin client arena thanks to companies like Citrix who continue to advance the state of the art in thin application delivery.

In the browser-based arena we have had to turn to technologies like Google Gears and Adobe AIR in the past to make this possible but these had poor market penetration.  Coming down the pike, however, is the new HTML 5 Offline API which is set to redefine how the web works for users who need to go “off the grid” from time to time.  With HTML 5 incorporating offline capabilities and a richer feature set into the specification for the web itself we expect to see broad and rapid adoption from all of the leading vendors – most likely even before the draft standard is finalized.  While still quite some ways away this new standard will certainly lay the groundwork for a significant shift towards the browser as a ubiquitous, standard and robust platform.

The future of thin computing looks to be incredibly promising both in the enterprise as well as, for the first time, in the consumer arena as well.  Adoption of thin computing models will be spurred on by the current movement towards Software as a Service models and SaaS adoption will continue to be encouraged by the widespread presence of thin computing devices.  In many ways browser-based thin computing represents the technology aspect that is now maturing in the SaaS arena where SaaS itself is maturing in social acceptance rather than technical feasibility.