Category Archives: Career

Career, Education, IT Hiring, IT Management

IT’s Most Needed Skills

3 Comments

IT does not exist in a bubble.  IT is a business enabler, a way of taking an existing business and making it more efficient, cost effective, nimble and capable.  Except for home hobbyist, and even there this isn’t quite true – IT is subject to the business that it supports.  It has a goal, an objective and a budget.  The business provides for context in which IT exists.

I speak with a wide array of IT professionals every day.  I work with both the enterprise and small business markets and I work with a review board overseeing IT and software development programs at a university.  On that board we were asked, “What is the single, most critical skill lacking in college graduates seeking jobs in IT today?”

The answer to that question was overwhelmingly “the ability to write and communicate effectively.”  No, it was not a technology skill.  It was not even a skill taught by the computer or technology department.  What we needed was for the English department to push these students harder and for the university to require more and harder English classes for non-majors and to demand that those skills be applied to classes taken in all disciplines and not relegate those skills purely for use in English-focused classes.

The ability to communicate effectively is critical in any profession but IT especially is a field where we need to be able to communicate large amounts of data, both technical and esoteric, rapidly, accurately and with extreme precision.  Most fields don’t penalize you to the same degree as IT for not knowing the correct use of white space or capitalization, spelling or context.  IT demands a level of attention to detail rare even in professional fields.

As a prime example I have seen the misuse of “Xen server” to mean “XenServer” no less than twenty times in an attempt to get technical assistance – which inevitably lead to useless advice since these are the proper names of two different products with unique configurations, vendors and troubleshooting procedures.  How many lost hours of productivity for each of those companies have happened just because someone cannot properly identify or communicate the software product with which they are seeking assistance?  Worse set, I’ve see this same product referred to as ZenServer or ZEN server – both of which are the correct names for other software products.  Yes, four different products that are all homonyms that require proper spelling, spacing and capitalization to reliably differentiate one from another.  The worse scenario is when someone writes “Xenserver” or “Xen Server”, neither being the exact name of any product, where the ambiguity means that there are at least two products equally far from matching what is given.  The person speaking often feels that the needs for precision is “annoying” but fails to understand why the advice that they receive doesn’t seem to apply to their situation.

I’ve seen confusion come from many written inaccuracies – mistaking versions of Windows or confusing “VMWare Server” for “VMWare ESXi” because someone refers to both or either simply as the name of the vendor and not of the product forgetting that that one vendor makes at least five or more different virtualization products.   These are basic written language skills necessary to successful work in IT.  Not only does lacking this skill create technical challenges in communicating to peers but it also implies an inability to document or search for information reliably – some of the most common and critical IT skills.  This, of course, also means that an IT professional in this position may be responsible for purchasing the wrong product from the wrong vendor simply because they did not take the time to be accurate in repeating product or vendor names or may cause system damage by following inappropriate advice or documentation.

Good communications skills go far beyond technical documentation and peer interactions – being able to communicate to the business or other support groups within the organization, to vendors or to customers is extremely important as well.  IT, more than nearly any other field, acquires, processes and disseminates information.  If an IT professional is unable to do so accurately their value diminishes rapidly.

The IT professional seeking to advance their career beyond pure technical pursuits needs the ability to interact with other departments most notably operations and business management in most cases.  These are areas within most companies where written word, as well as presentation, is highly valued and the IT team member able to present recommendations to management will have better visibility within the organization.  Technology departments need people with these skills in order to successfully present their needs to the business.  Without this skill within the ranks, IT departments often fail to push critical projects, secure funding or obtain necessary visibility to work effectively within the organization.

The second big skill needed in IT departments today is an understanding of business – both business in general and the business referring to the specific business of their own organization.  As I said at the beginning of this article, IT is a business enabler.  If IT professionals do not understand how IT relates to their business they will be poorly positioned to valuate IT needs and make recommendations in the context of the business.  Everything that IT does it does for the business, not for technology and not for its own purposes.

Within the IT ranks it is easy to become excited about new products and approaches – we love these things and likely this was a factor in our wanting to work in IT.  But finding the latest software release to be exciting or the latest, fastest hardware  to be “neat” are not sentiments that will cut muster with a business professional who needs to understand the ramifications of a technology investment.  IT professionals wishing to move beyond being purely technology implementers into being technology recommendors and advisers need to be able to speak fluently to business people in their own language and to frame IT decisions within the context of the business and its needs.

Career, Education

Standard Areas of Discipline Within IT

2 Comments

 

Information Technology and Business Infrastructure are an enormous field filled with numerous and extremely varied career opportunities not just in the industries in which work is done, but also in the type of work that is done. Only rarely are any two IT jobs truly alike. The variety is incredible. However, certain standard career foci do exist and should be understood and known to everyone in the field as they provide important terminology for mutual understanding.

It is very important to note that, like in any field, it is most common that a single person will do more than one role throughout their careers and even at the same time. Just as someone may be half time burger cook and half time cashier, someone may have their time split between different IT roles. But we need to know what those roles are and what they mean to be able to convey value, experience and expectation to others.

These are what we refer to as “IT Specializations” and are areas of specific focus and opportunity for deep skill within IT. These often do not just represent job roles within IT, but in large businesses generally are representative of entire departments of career peers who work together. None of these areas of focus is more or less senior to any other, these are different areas, not levels. There is no natural or organic progression from one IT discipline area to another, however all IT experience is valuable and it would be expected that experience in one discipline would prepare someone to more quickly learn and adapt to another area.

The terms “Administration” and “Engineering” are often applied today, these, again, are not levels, nor are they discipline areas. These refer to a role being focused on operations (the running of production systems) or on designing systems for deployment. These two share discipline areas. So, for example, the Systems discipline would have need for both administration and engineering workloads within it.

Systems. Shortened from “operating systems.” Systems roles are focused on the operating systems, normally of servers (but not necessarily in all cases.) This is the most broadly needed specialized IT role. Within systems, specializations tend to be such as Windows, RHEL, Suse, Ubuntu, AIX, HP-UX, Solaris, FreeBSD, Mac OSX and so forth. High level specializations such as UNIX are common with a single person or department servicing any system that falls under that umbrella, or larger organizations might split AIX, Solaris, RHEL and FreeBSD into four discrete teams to allow for a tight focus on skills, tools and knowledge. Systems specialists provide the application platform on which computer programs (which would also include databases) will run. Desktop support is generally seen as being a sub-discipline of systems, and one that often intersects pragmatically with end user and helpdesk roles.

Platforms. Also known as virtualization or cloud teams (depending on exact role), the platform discipline focues on the abstraction and management (hypervisor) layer that sits, or can sit, between physical hardware and the operating system(s). This team tends to focus on capacity planning, resource management and reliability. Foci within platform specialization would commonly include VMware ESXi, vCloud, Xen, XenServer, KVM, OpenStack, CloudStack, Eucalyptus, Hyper-V and so forth. With the advent of massively hosted platforms, there has also arisen a need for foci on specific hosted implementations of platforms such as Amazon AWS, Microsoft Azure, Rackspace, Softlayer and so on.

Storage. Storage of data is so critical to IT that it has filtered out as its own, highly focused discipline. Storage specialist generally focus on SAN, NAS and object store systems. Focus areas might include block storage in general, or might drill down to specific product or product lines, such as EMC VMAX or HPE 3PAR. With recent growth in scale out storage technologies, the storage arena is growing both in total size as well as in depth of skill expectation.

Databases. Similar to storage, databases provide critical “backing” of information to be consumed by other departments. While conceptually databases and storage overlap, in practicality the two are separated dramatically in how they are treated. We think of storage as “dumb”, “unstructured” or “bulk” storage and database as “smart”, “focused” or “highly structured” storage. At their fundamental level, the two are actually quite hard to distinguish. In practice, they are extremely different. Database specialists work specifically on database services, but rarely create databases and certainly do not code database connected applications. Like their systems counterparts, database specialists (often called DBAs) manage the database platform for other teams to consume. Database foci could be high level such as relational databases or non-relational (NoSQL) databases. Or, more commonly, a DBA would focus on one or more very specific database applications such as Informix, MS SQL Server, DBase, Firebird, PostgreSQL, MariaDB, MySQL, MongoDB, Redis, CouchDB, and many more.

Applications. Applications are the final product that consumes all other platform components from physical systems, platforms, systems, storage, databases and more. Applications are the ultimate component of the computational stack and can take a massive variety of forms. Application specialists would never use that term but would be referred to as a specialist on a specific application or set of applications. Some application families, such as CRM and ERP, as so large that an entire career might be spent learning and supporting a single one (such as an SAP ERP system.) While in many other cases one might manage and oversee hundreds of small applications over a career span. Common application areas include CRM, ERP, email, web portals, billing systems, inventory tracking, time tracking, productivity and so much more. Applications could include just about anything and while some are high provide, such as an Exchange email system; others might be very trivial such as a small desktop utility for calculating mortgage rates quickly.

Networking. Networks tie computers together and require much design and management on their own making them often the second largest discipline within IT. Network specialists work on buses, hubs, switches, routers, gateways, firewalls, unified thread management devices, VPNs, network proxies, load balancers and other aspects of allowing computers to speak to each other. Networking specialists typically focus on a vendor, such as Cisco or Juniper, rather than product types such as switches or routers. Networking is, with systems, the best well known or most commonly mentioned, role in IT even if the two are often confused. This role also supports the SAN (the actual network itself) for storage teams.

Security. Not truly an IT discipline itself, but rather an aspect that applies to every other role, IT Security specialists tend to either specialize by other discipline (network security, application security) or act as a cross discipline role with a focus on the security aspects as they cross those domains. Security specialists and teams might focus on proactive security, security testing and even social engineering.

Call Center, NOC or Helpdesk. The front line role for monitoring systems across other domains, taking incoming calls and emails and assisting in triage and sometimes direct support for an organization which may or may not include end users. This role varies heavily depending on who the direct “customer” of the service is, if tasks are interrupt (monitoring) based or if they are queue (ticket) based. Often the focus of this role is high level triage but can cross dramatically into end user support. This discipline is often seen as a “helper” group to other teams.

End User Support. Whether working sitting beside an end user in person (aka “deskside support) or remotely (aka helpdesk), end user support roles work directly with individual end users to resolve individual issues, communicate with other support teams, train and educate, and so forth. This is the only IT role that would commonly have any interaction with non-IT teams (unless reporting “up” in the organization to management.)

Hardware Technical Support. This role has no well known name and is often known only by the fact that it works with hardware. This role or family of roles includes the physical support and management of desktop or laptop devices, the support and management of physical servers, storage systems, or networking devices or the physical management of a datacenter or similar. This is the portion of IT that rubs shoulders with the “bench” field (considered to be outside of IT) and consists of much grey area overlapping with it. Hardware Support will often plug in and organize cables and generally works supporting other teams, predominately platforms or systems. Separating IT Hardware Support from Bench work is often nothing more than an “operational mindset” and most roles could potentially go in either direction. Placing desktops on desks is often seen as falling to bench, whereas racking, stacking and monitoring server hardware is generally seen as IT Hardware.

 

It is often practical to define what IT is not, rather than what it is. Many things are often assumed to be IT roles, but are not, and are so commonly connected with the field that it is worth expressly pointing out that they are not IT roles, but rather something else.

Project Management. PM is its own discipline that is far more a part of management than any other field and has no direct ties to IT whatsoever. IT often utilizes PM roles and PMs often oversee IT projects and IT companies or departments generally have PMs tasked to them; but the PM career itself is quite separate from IT. The same as any management role.

No Cabling. IT is most certainly not an electrician’s trade and the running off, termination of and certification of building cables is not even remotely within the scope of IT. Most IT departments will plug in computers to their network ports; but this no more makes IT the electrical maintenance department than plugging in a lamp at home makes you the electrician. The physical cabling plant of a company remains part of the electrical and maintenance roles clearly outside of IT.

No Programming. There is no programming role within IT. Software Engineering is a closely associated industry, but is not itself part of IT proper. The head of IT is seen as the CIO, the head of SE is see as the CTO. CIO is about business infrastructure – the “plumbing” of the organization. The CTO is about the engineering and creation of new tooling – often which would then be used by the IT organization. The expectation is that IT would request tools from SE. That is not to say that IT roles never write code, they often do, but coding is not the product of IT, it’s a tool in the toolset. An SE’s job is to deliver code as the end product.

No DevOps. DevOps is not a role. DevOps is a modern terminology for a specific style of working in other roles. One can be a DevOps System Admin or a DevOps Network Admin or a DevOps DBA, for example, but you can’t be just “DevOps” as it does not mean anything on its own. DevOps is a way of working, not a specific task. So we do not see DevOps on the list, even though DevOps is an important concept in IT in general.

Career, Education

Legitimate University Programs Are Not Certification Training

2 Comments

The university educational process is one that is meant to broaden the mind, increase exposure to different areas, teach students to think outside of the box, encourage exploration, develop soft skills, and to make students better prepared to tackle more learning such as moving on to trade skills needed for specific fields.  The university program, however, is not meant to provide trade skills themselves (the skills used in specific trades), that is the role of a trade school.   Students leaving universities with degrees are intended to not be employable due to specific skill sets learned at college, but to be well prepared to learn on the job or move on to additional education for a specific job.

In the last two decades, led primarily by for profit schools looking to make money quickly without regards to the integrity of the university system, there has been a movement, especially in the United States, for trade schools to get accredited (an extremely low bar requirement that has no useful standing outside of legal qualifications for educational minimums and should never be see as a mark of quality) and sell trade degrees as if they were traditional university degrees.  This has been especially prevalent in IT fields where certifications are broadly known and desired, acquiring properly skilled educational staff is expensive and essentially impossible to do at the scale necessary to run a full program, degree areas are easily misunderstood by those entering their college years and where the personality traits most common to people going into the field sadly makes those people easy prey for collegiate marketing drives.  The promise of easy classes, double dipping (getting the certs you need anyway then getting a bonus degree for the effort) and the suggestion that by having a degree and certs all at once will open doors and magically provide career options that pay loads of money triggers an emotional response that makes potential students less able to make rational financial and education decisions, additionally.  It’s a predatory market, not an altruistic one.

Certificates play a fundamentally different role than a university education does.  Unlike universities, certification is about testing very specific skills, often isolated by product or vendor, things that should never appear in any university program.  Certification may be broad (and closer to collegiate work) in certs like the CompTIA Network+ which tests a broad range of basic networking knowledge and nothing specific to a vendor or product, but is still overly specific to a single networking technology or group of technologies to be truly appropriate for a university, but is, at the very least, leaning in that direction.  But more common certifications such as Microsoft MCSE, Cisco’s CCNA, CompTIA’s Linux+ or A+ are all overly product and vendor specific, far too “which button do I press” and far too little “what does the underlying concepts mean” for collegiate work.

Certifications are trade related and a great addition to university studies.  University work should prepare the student for broad thinking, critical thinking, problem solving and core skills like language, maths and learning.  Then applying that core knowledge to certifications should make achieving certifications easier and meaningful.  University should show a background in soft skills and broadness, while certifications should show trade skills and specific task capabilities.

Warning signs that a university is behaving improperly would include, in regards to this area of concern, overly specific programs that sound as if they are aimed at technologies like a degree in “Cisco Networking” or “Microsoft Systems”, if certifications are achieved during the university experience (double dipping – giving out a degree simply for having gotten certs) or if the program leans towards an indication of preparing someone “for the job” or expected to “get the student a great job upon completion” or is expected to “increase salary”.  These are not goals of proper university programs.

Critically evaluating any educational program is very important as educational investments are some of the largest that we make in our lives, both monetarily and in terms of our time commitments.  Ensuring that the programs are legitimate, valuable, meet both our own goals and proper goals, will be seen as appropriate by those that will see them in the future (such as hiring managers) are very important.  There are many aspects over which we must evaluate the university experience, this is only one but it is one that is a newer problem, suddenly very prevalent and one that specifically targets IT and technical hopefuls so requires extra diligence in our industry.

 

Business of IT, Career

No One Ever Got Fired For Buying…

Leave a comment

It was the 1980s when I first heard this phrase in IT and it was “no one ever got fired for buying IBM.”  The idea was that IBM was so well known, trusted and reliable that it was the safe choice as a vendor for a technology decision maker to select.  As long as you chose IBM, you were not going to get in trouble, no matter how costly or effective the resulting solution turned out to be.

The statement on its own feels like a simple one.  It makes for an excellent marketing message and IBM, understandably, loved it.  But it is what is implied by the message that causes so much concern.

First, we need to understand what the role of the IT decision maker in question is.  This might sound simple, but it is surprising how easily it can be overlooked.  Once we delve into the ramifications of the statement itself, it is far too easy to lose track of the real goals. In the role of a decision maker, the IT professional is tasked with selecting the best solution for their organization based on its ability to meet organizational goals (normally profits).  This means evaluating options, shielding non-technical management from sales people and marketing, understanding the marketplace, research and careful evaluation.  These things seem obvious, until we begin to put things into practice.

What we have to then analyze is not that “no one ever got fired for choosing product X”, but what the ramifications of such a statement actually are.

First, the statement implies an organization that is going to judge IT decision making not on its merits or applicability but on the brand name recognition of the product maker.  In order for a statement like this to have any truth behind it, it requires the entire organization to either lack the ability or desire to evaluate decisions but also an organizational desire to see large, expensive brand names (the statement is always made in conjunction with extremely high cost items compared to the alternatives) over other alternatives.  An organizational preference towards expensive, harder to justify spends is a dangerous one at best.  We assume that not only does buying the most expensive, most famous products will be judged well compared to less expensive or less well known ones, but that buying products is seen as beneficial to not buying products; even though often the best IT decisions are to not buy things when no need exists.  Prioritizing spending over savings for their own reasons without consideration for the business need is very bad, indeed.

Second, now that we realize the organizational reality that this implies, that the IT decision maker is willing to seize this opportunity to leverage corporate politics as a means of avoiding taking the time and effort to make a true assessment of needs for the business but rather skip this process, possibly completely, we have a strong question of ethics.  Essentially, whether out of fear of the organization not properly evaluating the results  or by blaming the decision maker for unforeseeable events after the fact or of looking to take advantage of the situation to be paid for a job that was not done, we have a significant problem either individually, organizationally, or both.

For any IT decision maker to use this mindset, one that there is safety in a given decision regardless of suitability, there has to be a fundamental distrust of the organization.  Whether this is true of the organization or not is not known, but that the IT decision maker believes it is required for such a thought to even exist.  In many organizations it is understandable that politics trump good decision making and it is far more important to make decisions for which you cannot be blamed rather than trying honestly to do a good job.  That is sad enough on its own, but so often it is simply an opportunity to skip the very job for which the IT decision maker is hired and paid and instead of doing a difficult job that requires deep business and technical knowledge, market research, cost analysis and more – simply allowing a vendor to sell whatever they want to the business.

At best, it would seem, we have an IT decision maker with little to no faith in the ethics or capabilities of those above them in the organization.  At worst we have someone actively attempting to take advantage of a business by being paid to be a key decision maker while, instead of doing the job for which they are hired or even doing nothing at all, actively putting their weight behind a vendor that was not properly evaluated based possibly solely on not needing to do any of the work themselves.

What should worry an organization is not that vendors that could often be considered “safe” get recommended or selected, but rather why they were selected.  Vendors that fall into this category often offer many great products and solutions or they would not earn this reputation in the first place.  But likewise, after gaining such a reputation those same vendors have a strong financial incentive to take advantage of this culture and charge more while delivering less as they are not being selected, in many cases, on their merits but instead on their name, reputation or marketing prowess.

How does an organization address this effect?  There are two ways.  One is to evaluate all decisions carefully in a post mortem structure to understand what good decisions look like and not limit post mortems to obviously failed projects.  The second is to look more critical, rather than less critically, at popular product and solution decisions as these are red flags that decision making may be being skipped or undertaken with less than the appropriate rigor.  Popular companies, assumed standard approaches, solutions found commonly in advertising or commonly recommended by sales people, resellers, and vendors should be looked at with a discerning eye, moreso than less common, more politically “risky” choices.