The Unprecedented Importance of Revisiting IT Precedents

Every IT leader would agree that a few of the top goals of any IT department are to provide reliable, secure, and sufficient services to meet the needs of the company that they support. Most IT leaders would also agree that yesterday’s solution is for yesterday’s needs. If today’s needs are different, then yesterday’s solutions are likely insufficient. This is clear to most people. The blind spot for some leaders is recognizing that solutions continuously evolve even if your needs remain static. Today’s unchanged solution to your unchanged needs might seem sufficient, but it might be hurting your company if it goes unchecked.

Whether you have worked with the company for 2 years or 20 years, it is important to revisit the precedents for solutions that have been set by you or others on a periodic basis. Each year, I add to my IT action plan to review at least one past large-scale solution with the same basic goals to achieve: better service, and better value.

Two years ago, I chose to revisit the company’s telecommunications infrastructure. As anticipated, I had the goals of providing better service and better value to the company and our customers. In pursuit of these goals, I met with our sales and support teams and asked about any pain points that they had and what an ideal solution would look like for them. I met with our finance team and compiled a complete TCO report for our existing telecommunications infrastructure. To provide better value, it was imperative to know the big picture of our total costs. Any new solution would need to provide compelling enough value and service for it to make sense. After a few months of research, and many SC led demo’s we found our solution. We tossed our very large footprint legacy on-premises PBX (including the PRI, and ACD, AES, SIP, etc.) in favor of software phones and a standards-based SIP solution with a managed cloud PBX. It has been two years since that project was completed and the our sales and support teams still tell me how happy they are with the new phone system. Not only did this project save the company $30K per year, but the sales team is enjoying mobility options that had never existed before. Our sales team can work from home and even take calls to their office line from the road.

The best part of the whole project was when I saw the smiles on our sales team’s faces a few weeks after the project was completed. The company’s needs had not changed since the last solution was implemented. But by contrasting the viable incumbent solution against leading modern solutions, I was able to sponsor and implement the change that unlocked unforeseen productivity gains and simultaneously improved the company’s bottom-line.

Why the public cloud is the fast food of the IT industry.

The challenge for any IT manager is how to meet business requirements with technology.  More often than not, those requirements dictate rapid deployment.  The cloud excels at this, since the infrastructure is already available and waiting to be used.  Rapid deployment, just as fast-food, does not guarantee quality, however.  In fact, the performance and reliability of public cloud services is currently variable and largely unpredictable.  Despite the high availability of fast food restaurants, people do not eat it for breakfast lunch and dinner.  They know that the quality of the food is sub-par, and it is intuitive to recognize that its usefulness runs out if speed and short-term cost are not the two foremost drivers.  The same holds true with the public cloud services.  They excel at speed-to-deploy and cost-of-entry for a solution.   And – just as with fast food, public cloud services are almost irresistibly appealing on the surface.  But after considering quality and long-term costs, it is clear that the best solutions remain in private clouds.

Cloudsourcing – What is this “IT revolution” all about?

First there were servers.  Each server had a single purpose.  In some cases, 90% of the time, they ran idle — a big waste of resources (processor, disk, memory, etc.)

Then there were server farms, which were groups of servers distributing loads for single applications.   Distributing loads to multiple servers allowed for higher loads to be serviced, which allowed for tremendous scalability.

Then there was SAN storage, the aggregation of disks to provide performance, redundancy, and large storage volumes.  A company could invest in a single large-capacity, highly-available, high-performance storage device that multiple servers could connect to and leverage.   No more wasted disk space.

Then there was virtualization, the concept of running more than one server on the same piece of hardware.   No more wasted memory.  No more wasted processors.  No more wasted disk space.  But the management of isolated virtual servers became difficult.

Then there was infrastructure management.  The idea that we could manage all of our servers from a single interface.  No more wasted time connecting to each server to centrally manage them.   But there were still inefficiencies when managing the applications and configuration of the virtual servers.

Then there was devops, the concept of having software scripts manage the configuration and deployment processes for virtual or physical servers.

…  With all of these inefficiencies addressed, you would think that there is no more room for improvement.  But we do have a “gotta-have-it-now” society, and in this age of fast-food and mass produced goods, we had to see this coming.  The “Cloud”.   The “cloud” is the fast-food of servers.  It is the idea that someone else can leverage all of the aforementioned concepts to build and manage an infrastructure much larger than yours, and cheaper and faster (per unit) than you can.  It is the idea that economies of scale drive costs so low for the cloud provider that those savings translate into big savings for the companies or people that leverage them.  We all use “the cloud” in some way.   Microsoft has OneDrive/SkyDrive, Google has Google Drive, and then there’s Dropbox.   All of these services represent “the cloud” for individual people.  But there are clouds for companies, too, like Amazon’s AWS, Google’s Cloud Platform, Microsoft’s Azure, etc.

So how do we know that the cloud is good for a company?   Well, it’s really difficult to tell.  For one, the traditional model for companies was one where they owned their infrastructure.  All expenses were considered capital expenses – that is, there were not recurring expenses for their infrastructure equipment (except perhaps for software components).   But when it comes to cloud infrastructure, the business model is, of course, the one that profits the cloud owner the most — the holy grail of business models — the recurring revenue stream known in IT speak as Infrastructure As A Service.   Cloud businesses are booming right now!  The big question is – is the “cloud” as good for the customer as it is for the provider?

In my experience, owning hardware has distinct advantages.  The most recognizable difference is that a company can purchase infrastructure while sales are up – and they can coast along continuing to leverage their infrastructure equity when sales dip down.   In my experience, once hardware is paid for, the recurring cost to run and maintain it is much less than the cost of any cloud solutions.  After all, the cloud providers need to pay for their infrastructure, too.  They pass that cost on to you after padding it with their soon-to-be profits, so your recurring costs with them will potentially always be higher than yours will be if you own your infrastructure.  If you were to transform your initial investment into an operational expense and distribute it out over the lifespan of the equipment (let’s say, 5 years), then add in the cost of ownership of that equipment, then the numbers become close enough that I am comfortable enough to declare that at least the first year of ownership will be a wash.  In other words, if you intend to own hardware for a year or less, then the cloud is really where you should be.   The longer that you intend to continue to extract use out of your hardware, though, the more appealing it is to own your own rather than use the cloud.

To put this into perspective…  it is common for townships to employ a mechanic to maintain their vehicles.   If townships were to, instead, lease all of their vehicles, the mechanic would not be necessary and costs could initially be reduced.  But, over time, the value that the mechanic introduces would more than pay for his salary.   Company’s have mechanics, too, except that they are called systems administrators.  They keep systems running and squeeze every last drop of efficiency out of a piece of hardware.   If you are a company without “mechanics”, the cloud is for you.   But if you do have systems administrators within your employ, then yet another consideration needs to take place.  What is the reason for leveraging the cloud?   If your answer is, “Because it’s the latest trend.”, then you need to take a step back and reconsider taking another sip of the kool-aid that you have been drinking.   If your answer is, “We have been growing rapidly and our infrastructure cannot keep up.”, then perhaps the cloud is the right spot for you.  If your answer is, “Our business is seasonal and sometimes we have a lot of wasted infrastructure that is online, but unused.”, then perhaps the cloud is for you.

There are other cases, and the math certainly needs to be done.   Economies of scale make this topic interesting because it is certainly plausible that one day cloud services will be cheaper than owning your own infrastructure.   There will always be the differences in CapEx vs OpEx, and that requires an assessment of your sales patterns before taking any plunge into the cloud.   One thing is certain, though.  The cloud is not for everyone.  Assess your business needs, assess the competence of your IT group, assess your revenue streams, and then make a careful and calculated decision.   But whatever you do, don’t do it just to do it.   Because chances are that the results will not meet your business needs.

 

 

 

What constitutes a great leader?

A leader is a driver, meaning that leaders must be good decision makers and must be capable of choosing a destination.   When judged in hindsight, the destination must be meaningful and productive.  Just like a driver of a car, a great driver will act upon the passenger-spoken words, “We need to take the next exit.”  A bad driver will disregard all advice.   As drivers, we may know where we want to go, but it is our passengers who have the best view of the road.  It is our passengers who are in the best position to navigate.  Good drivers take us to our destination.  Great drivers rely on great navigators to help them get us to our destination in the best possible way.

Heeding the advice of “passengers” is vitally important to the effectiveness of a great leader.

Let’s consider the fail-forward (trust) and fail-stop (mistrust) approach to governance.  The term “fail” refers to the failure of a tactical decision/action to comply with a strategic goal.  The term “forward” means that the short-term tactical action may proceed if it means that it will “keep the lights on”.   The term “stop” means that in the interest of meeting a strategic goal, a tactical action is forbidden and the company suffers consequences as a result of inaction, “lights out”.  Fail-forward requires trust because the time and effort taken to assess an urgent tactical action may jeopardize the effectiveness of that action and may therefore jeopardize the health of the company.   Fittingly, fail-stop reflects mistrust because the reflexive blocking of a tactical action for the sake of improved alignment with a strategic goal does not take into account upward feedback and therefore cannot allow for the trust of tactical decision makers.

A great leader fails-forward, meaning that there is a healthy bi-directional trust relationship both up and down the hierarchical chain of responsibility.   A great leader empowers tactical decision makers with the ability to navigate.  A great leader recognizes that the acceptance and accommodation of non-ideal elements is often crucial to accelerating the journey to our destination (success) – in the same way that a driver might take a detour to avoid a road closure rather than waiting for the road to re-open in the vain of not diverting from his/her predetermined ideal route.

We are all leaders, navigators, and followers at different times.  When leading, if our decisions are unchanged when compared with and without our navigators, then perhaps it is time to rethink whether or not we are great leaders, good leaders, or shamefully bad leaders.

 

 

Abstract Technology Concepts – Devops

When we think about technology, we often think of it as abstract concepts.   For example, we think of a “telephone”, not a network of transducers wired through hubs and switches that create temporary channels that bridge calls together.  It is natural for us to add layers of abstraction that help us to understand the purpose or use of something.   In programming languages, we saw the rise of object oriented programming – the ability to define an object and then manipulate its attributes.   The Windows operating system is a layer of abstraction that you interact with.   These days, you can accomplish, with scripts (PowerShell), most of what you can do with a mouse.   That brings me to the latest layer of abstraction – devops.   It’s a concept that says that developers and operations join forces and share methodologies for the betterment of the company that they represent.   For example:  With a traditional sysadmin mindset, a systems administrator might click a button every day to accomplish a task.   But a developer would write a program that automates pressing that button to gain efficiency.   So devops is really about applying development concepts to systems administration.  Aside from potential gains in efficiency, there are also gains in consistency, since the code will not forget to press the button – and it will press the button each day exactly the same way as the day before.   Consistent input means more consistent output.   So the task can be considered more reliable.

Sounds great, right?    Why didn’t we do this 10 years ago?

Well, the truth is that in the Windows world, the GUI is king.  But in the Linux world, the command-line is king.   Automation in Linux is much easier to accomplish.  Linux systems administrators have been practicing the concept of devops for quite some time now – it just never had a name.  Microsoft has just in the past several years released tools, such as PowerShell, that allow Windows Systems Administrators to practice devops.    I consider the devops mindset a tool because it is a concept that has a specific function.   The function of devops is to automate, automate, automate.  Like any other tool, there are problems that it is the solution for, and problems where it just does not fit.

So where does devops not fit?   Ok, so devops is all about automation, right?   So naturally, anything that we do not want to automate is something that probably is not something that the devops paradigm is a fit for.   Here are a few examples of things that should not be automated:

  • User account information entry – someone needs to type this information at some point.  From there forward, we can automate though.
  •  Buidout of the automation scripts – this a tedious manual process that can possibly be partly automated, but not fully automated.
  • Image building – I am talking about base images.  It is not that this cannot be automated.  It is that in most cases, building a single image manually is more efficient than building a set of scripts to build it.

Devops is a great way to look at things, and it’s about time that the Linux mentality has spread to Windows.   But as you might already understand by now, the effort required to automate is considerable.  Devops is an abstract concept, just like the telephone is.  Underneath the devops concept are additional processes and procedures that, without devops, would not be required.  If you think of devops as a layer of abstraction, then you will quickly recognize that just like virtualization, or object oriented programming, there is a penalty when applying it.   In most cases, the productivity/reliability gains of applying devops concepts far outweigh the penalty of implementing it, though.

Conclusion

Devops is best applied when the amount of manual work to be done is significantly greater than the amount of work required to automated it.

When considering whether or not to apply devops practices to an IT function, consider if the functional requirements vary too much to be automated, or if the function is used too infrequently to warrant the additional overhead required by the application of devops practices (automation).   Remember the goals.  Improve efficiency, improve consistency, improve reliability.  Prioritize those goals, and then determine if the act of implementing devops is expected to hinder any of them.   If the answer is no, devops does not hinder any of these goals, then go ahead and apply it.   But if devops challenges your most important – top priority – goals, then perhaps reconsider its application.

 

Subject Line Messages Lead to Ineffective Communication

One of my pet peeves in the professional world is when people send emails with the body empty and the entire message in the subject line. In my experience, I have isolated a few different characteristics of many (not all) people who exhibit this behavior.

  • Technologically Antiquated
  • Arogant
  • Narcissistic

Undoubtedly, there are more than just these three characteristics, but these capture my experiences.  A very well-intentioned, educated, good mannered person might have a very good reason for sending such a succinct notice. These three categories simply represent the majority of people who I have encountered over the years who exhibit this behavior. Not everyone. But most.

If we have the luxury of time and the subject matter is not of urgent nature – that is when I cringe upon reading one of these specially crafted messages. The truth is that the all star over-achieving employees do always take the time to share enough words to properly convey their thoughts and use technology as it was intended to be used. A subject is a subject of a body, not the body itself.

But why does something so simple bother me enough to write about it?   Well, when I am busy and I receive a hastily written message that is neither urgent nor meaningful, it sends an unwritten message to me.   The message is that the writer believed so much that his/her time was so much more important than mine that he/she expects me to waste my time while attempting to decipher their incomplete and poorly written thoughts.  Now, nobody really thinks that way, so I would expect no malintent.  But the absence of respectful, thoughtful, and succinct writing is nearly as bad as malintent.  It leads to ineffective communication, which then creates inefficiencies that cost additional time and therefore money.   It is always better to take the extra few seconds to type the few additional words than to leave the person on the other end scratching their head, wasting time.

Passive-Aggressive Personality Disorder

So, I just made that up.  But I truly believe that this is becoming an epidemic due in no small part to the heads-down “connected” culture that we are all a part of today.   There is no substitute for a face-to-face conversation, where there are real consequences for bad behavior, innuendos, or blatant and excessive criticism.  In the digital world, though, those rules do not apply.  Emails are ripe with innuendos, and unlike face-to-face conversations, people do not typically wait to calm down before hastily typing a digital message that embodies their real and present, but short-lived, emotional state.

Sending emails or other digital communications is only half of the problem, though.  The other half of the problem is quickly and accurately detecting the emotional state of the person who sent. The ability to assess this is critically important so that you can properly disarm them and have a meaningful and constructive conversation.

Even through digital communications, there are always hints of the composer’s state of mind.  If you are angry, you might choose the more negative of two synonyms.  Your precise choice of words draws a subtle picture in the reader’s mind.  And this is where the passive-aggressive behavior comes into play.   Whether we intend to or not, our choice of words tells just as much a story as the literal meaning behind them.  The subtle nature of that information, makes it a passive, yet aggressive, form of communication.  In summary, treat digital communications the same way you would face-to-face communications.   Pause if you are upset.   And when you do write something, choose your words carefully so as to not fall into the trap of becoming passive-aggressive.  Be direct, and be professional and/or considerate.

Crisis Management

Successfully navigating through an IT crisis requires both successful problem solving AND successful communication.

When it comes to a crisis, it is absolutely imperative to communicate effectively. People tend to fill in the details of what they do not know with their imaginations. Most often, those ad-lib details are inaccurate. Without good communication, you could experience the best, most ingenious solutions in the world, and you would not be the wiser. Seeing the ashes of a house that once stood might make you condemn a fire department. But knowing that the firemen saved everyone single living being in that house might allow you to focus on and appreciate the heroism, rather than to kindle any condemnation.  The facts do not change, but your perspective does.  Good communication yields more accurate perspectives and that is exactly what you want during a crisis.

Contributors of Change Within a Business

There are three types of contributors of change;  Instigators of Change, Implementers of Change, and Resistors of Change.   Each of these people are vital if any business is going to succeed.  Here’s why.

Instigators of Change are the people with uncontrollable passion.   They may often have ungrounded ideas, but their ideas might also be essential to the business’ success.  Many times, these are the people who are focused on the reward and oblivious of the risk.

Implementers of Change are the people with the technical skills needed to implement just about anything.   They often possess seemingly unbounded knowledge, and bring tremendously creative solutions to match equally difficult challenges.

Resistors of Change are the people who are usually the doubters.   They often fear change, and have a self-serving vested interest in averting it.  Many times, these are the people who are focused on the risk and unconvinced of the reward.

We need all three types of people to be successful.   The instigators are needed for their passion and for their ideas.   The implementers are needed for their innovative solutions.   The resistors are needed to keep the whole process grounded, to point out flaws, and to ensure that if the project does proceed, that every “i” is dotted and every “t” is crossed.   Each contributor is responsible for the success of the changes.

Just as the political system in the US has checks and balances, so do the contributors of change.  The implementers project a pragmatic perspective onto the instigator’s idealistic concepts.  The resistors harden the solution by weeding out potential failure points in the implementer’s solutions.   The instigators set the end-goal and many times, also the target deadline – ensuring an end in sight.  In the end, an innovative and successful change can take place.  Win-Win-Win.

Where does job stress come from, and what can we do about it?

Many of us have experienced stress at the job.   Perhaps we feel a muscle twitch, a migraine headache, or even our blood pressure might skyrocket.   Is there anything that we can do to be less stressed?   Let’s explore.

Empowerment is stress reducing.   Enabling others to make as many decisions as is prudent is one way of reducing their stress.  Having less on our plate reduces our stress.

The long way may take longer than taking shortcuts, but doing so will reduce stress later on.  When facing the choice, always try to avoid taking shortcuts.  Do things the right way the first time.

Be direct when communicating with others.  Avoiding confrontation is many times a precursor to passive aggressive behavior.  Whether you are the aggressor or the subject of the aggression, both parties will be subjected to stress.   It is always better for us to directly communicate with others, especially when our opinions differ.

Inform the uninformed.  Working for someone who shoots first and asks questions later can be very stressful.   Sometimes their decisions may be based on falsehoods rooted in ignorance.  Our job is not to be the victim.   Our job is to keep our bosses and peers informed.  Working for or with people who are informed will reduce conflict, which in turn will also reduce our stress.

Use your internal compass instead of an external one.  When we feel external pressure, we sometimes flip flop with our ideas.  We quickly, and many times incorrectly, doubt ourselves. We are often better experts in the subjects of our decisions than our critics are.   We need to believe in our decisions independently from criticism.   If we can be honest with ourselves and willing to swallow our pride if we make mistakes, then we can use our internal compass to tell us if we are headed in the right direction or not.  Having more confidence in our decisions will help us to be less defensive and that alone will help reduce stress.