In the world of IT management styles seem to be more and more confusing.  As a Consultant, I’ve worked with teams from all over the world.  The hours were long, sometimes sleepless, but very very satisfying.  Then things began to change.  As networks became more complex, more and more experts were added to the teams, some who came from other countries and other cultures within the US.  This worked well also.  In enjoy the diversity of different types of people working on teams.  I thought it was about the project and i enjoy completing projects.  Then one day I found myself on a team where I was the minority in a very different culture.  I’d worked on internationals teams before, but this was different.  95% of the team including two managers above me were from different cultures, different continents and I was suddenly not having fun.  I wondered… was it my age?  Was it the cultural and language differences?  What I began to realize was that it wasn’t any of those things. What I began to realize it was the difference in leadership management styles.

In high school I learned a lot about management theory.  So it wasn’t a surprise to see the subject when later in college I was working on my MBA.  One of the principles in management has to do with the managers assumptions about their workforce.  Back in the 60′s started being taught as theory X vs theory Y.

Theory X – Up and into the 50’s managers were taught that employees were lazy and did not want to work.  That all workers would do everything they could do to get out of working.  Part of the managers job was to build a management system that held employees accountable for working every minute of every hour.  Then to get as many hours out of an employee at the lowest cost.

I think if we look back at some of the turn of the century work places; Coal mines, foundries and other manufacturing businesses the working conditions were deplorable.  It was no wonder that after a 6 day work week with 12 hour shifts, an employee might be wanting to get off work and see his family.  When working conditions got better something amazing changed.  Employees began enjoying their work.  It wasn’t until the 1960’s that management theory included a new theory called Theory Y.

Theory Y – Assumes that all workers see their work as a fulfilling part of their life.  The goal is to do as good a job as possible.  Employees are not lazy and can be trusted.  Managers then must assume that the worker is there for a reason much bigger than just money.  To enable this type of worker the manager should add more and more flexibility and authority as the employee requests it.

It took over 80 years for the business management culture of the 1800’s to catch up in the 1960’s.  The result?  A workforce managed by Theory Y managers is a much more productive workforce.  More production ultimately means more profits for the same cost to the employer.  Theory Y is now embraced by the management culture in the United States.  This is great.

What if  the managers on your team were trained in Theory X and not Y? Life can be miserable for the employee who is used to theory Y managers.  Work is especially shaming for the employee.  The most productive employees will go find a job someplace else.

Personally, I think this is the biggest weakness when it comes to outsourcing teams from other countries.  Put a theory X manager in charge of a Theory Y workforce and suddenly there is confusion.  With that confusion, is a workforce that is much less productive.

I am sure that over time, managers from other cultures will learn to manage this new way.  It didn’t happen overnight in the United States… and it probably won’t happen overnight for the managers with a strong theory X culture.  In the meantime though, the employees, the company and even the managers lose.  As an business consultant, I interview the managers while the managers are interviewing me for every project.  I discuss Management styles to discover who I might be working for.  After working with managers who are theory X trained or even untrained and promoted from a technology team I’ve decided that I won’t work for managers who aren’t versed in Theory Y.  I’ve been much happier ever since.

One of my Seattle IT consulting clients had a problem.  After onboarding a new client, suddenly!… They were in the midst of an IT failure cascade.  It started with all the workstations that were old and past their normal life span.  Then servers would begin to fail.  Eventually even routers and other systems would begin failing.  No client likes to pay for brand new equipment.  So of course, insisted that the reason for the failure was my client’s fault.  So my client was replacing hardware at the end of life.  This of course led to a discussion of customer onboarding.

As technology experts we just think of onboarding as a technical process.  We are migrating data, software, settings, network objects and hardware from one environment to another.  We often want to do this quickly and with as minimal downtime as possible for the users and customers of our clients.  Most technicians are juggling a lot so expecting them to also juggle the business side is a little unrealistic.

So as technicians we create an onboarding path for our new clients.  Now here’s the rule I use for onboarding.  If my client is an Seattle IT Support company, I make the onboarding process very long.  If I’m my client is a customer, I may be tempted to encourage a very quick onboarding process.  The quicker the onboarding process, the more liability is placed on the shoulders of the IT Support Company.  So my goal with my Seattle IT Services and IT Support clients is to slow down the process.

The IT Services Company should have a big advantage when it comes to keeping down costs for IT Support.  After all they have better architects designing the systems, better vision about the future of technology, system administrators with more experience and stronger technicians than their clients could afford.  Put that together with a solid NOC and we should be seeing a bullet proof operation for the IT Services Company. The risk for the IT Services Company is bringing unknown systems into their environment.  Each change means the possibility for failure.  This is why an onboarding process for customers is so important to the IT Support and Seattle Cloud Architecture company.  The contract will read something like,

We support systems within our base configuration.  All systems outside this base configuration will not be supported by the SLA.  As the client systems fail or are replaced, we will maintain all systems installed by us at the best possible SLA possible for the customer.  All system repairs for non-compliant configurations will be priced at a discounted fix rate price.

So instead of a weekend onboard, we contract the onboarding for 6, 12 or even 18 months out.  During that time the onboarding teams job is to bring all systems into compliance with the SLA requirements for the new company. When expressed this way, it makes the migration to the cloud seem fair.  Nobody expects the cloud company to support all the systems, as if they were already SLA compliant, before the systems are ready.  The IT support company is no protected from past mistakes and can focus resources on slowly building out the network.  Onboarding actually becomes a benefit for that the sales department can use to sell the onboarding process.

Most IT support companies have problems in the first 6 months of the migration onto our site.  This is often because they are inheriting the problems from your last IT Support vendor. 

So instead what we do is onboard you over a 6 months.  During that time will fix or replace all the problems we find that migrated from your old system.  Once the onboarding process is complete and we certify your systems as compliant with our SLA, any failures will be fully covered.

So a well designed onboarding plan sets the new customer with the right future expectations.

What is business value?  As a Seattle IT Consultant, this is a question I try to answer for my clients.  This is more than just building more servers and loading more software.  A business is valued by its business processes.  The better defined the business processes; the more value there is in the company.  Smaller companies tend to have less well defined processes.  As the company grows those processes need to be better and better defined.

So what is a business process?  A business process is a component that supports a business system.  There are multiple business systems in any business.  Business systems include:

• Management
• Accounting
• Legal
• Marketing
• Sales
• >Production/Services
• Human Resources
• Account Management

Every business system is support by multiple business processes. All business processes are supported by some level of information technology. Of course this means that when the technology that supports the process fails, the business process also fails. Additionally, when the technology that supports each business process within a business system is not integrated, waste occurs. The waste is usually in lost worker productivity. To improve business value there are three strategies.

Stabilize Information technology – Reducing downtime, means increasing worker productivity.  When systems are down, modern information workers must wait for the systems to come back online.  Payment is still required for these workers.  So by improving workplace productivity from an average 10% downtime to 1% downtime automatically increases income and ultimately business value.

Automate the Sales process – By automating the marketing and sales of the business income and business value increase.  Integrating sales technologies the company reduces the cost of finding and customer conversation.  This improves the business value of the organization.

Automating business processes – Every Business system requires multiple business processes.  For example: Accounting processes include Payroll, Accounts Receivable and Accounts Receivable.  By utilizing fewer technology platforms to support all business process we reduce the costs.  By reducing cost, we increase income and the ability of the management team to create business value.

Each year technology is changing. Break/fix technology services were replaced by managed services technologies.  Now we see cloud services technologies replacing break/fix and even managed services strategies. Tomorrow we’ll see Unified Communications (UC) technologies. We’ve already seen cases were small business has save 80% on operational expenses and 100% on capital expenses.

As a Seattle IT Consultant I am called by new business startups, small businesses and businesses that have just seemed to stop growing.  Each business owner asking,

“I innovate! Why can’t I grow?”

If you’ve ever met someone who is a pure innovator, you might have noticed something about them.  I find that they have lots of ideas.  It’s the execution of those ideas that becomes the big problem.  What do I mean?  Imagine trying to build a building.  There is a very specific order to building a building.

For example: You would never wait to build the foundation until after the walls and roof was built.  Yet this is exactly what a pure innovator might do. It’s the classic example of the cart before the horse.

The innovator thinks that the cart before the horse is, “Just crazy enough that it might work!”  So building the roof before the foundation seems like a great idea too.

“Hey… everyone gets to work in the shade… am I right?” says the innovator.

So in the world of technology we have a standard order of operations.  Follow it in the wrong order and things don’t really well or expenses go up while everyone waits around.  In the business world there is also standard order of operations as well.  The problem I find with innovators is that they don’t follow them.  Nor do they expect others to follow them.  So when I walk into their networks they are having errors because they haven’t followed the proper order of operations.

For example:  As a business grows it follows a standard cycle of operations.  The first step is The Idea Stage.  The Idea stage is an exciting time for an innovator.  There is no reality to stop his dreaming.  The second step though is to Build the business systems.  This is where the innovator is often stopped in her tracks by reality.  The business systems as mention on this page are accounting, legal, marketing, sales, management, Human Resources and so on.  Before the business can duplicate itself, these systems must be in place first.  Without them, there really is no business to grow.  That is unless you are an innovator.

If you’ve ever met a builder personality, they love building these business systems.  The problem with an innovator is they get bored with the building part.  It becomes a tedious place for them.  So they try to make things interesting by adding another factory or something before all the business systems are in place.  The resulting problems become a nightmare for the technology group.

I wonder if I’m the only one that runs into these types of situations.  A business owner jumping into the next step before the last step was completed?  I suppose it keeps everyone on their toes, but I’ve had my fill of innovators lately

Ok so the first thing to understand about strategy is that strategy is not the same thing as tactics.  Technology is very tactical within the business organization.  Because this is not always understood by the management teams in the organization, often it’s often hard for technical people to understand that there is a difference.  The one thing technologists are very good at is execution.  Execution is all about tactics.  This change for the technical expert from tactical thinking to strategic thinking is often a paradigm shift.  In this article we want to discuss the modern network architect’s understanding between the differences of tactical and strategic thinking.

Imagine you are a lumberjack 100 years ago.  You carry a big double headed ax and you walk from tree to tree chopping down trees.  For you trees have been chopped down the same way since the first caveman created the first stone ax.  You know that the more hours cutting down trees the more money the company makes. 

The strategy for the company is to produce raw lumber for the various industries that turn raw wood into finished products.

The tactic is to chop down trees with an ax,

The managers of the company think about the end to end process of harvesting and transporting trees to the market place.  The lumberjack is focused on the most efficient way to use his/her ax to harvest trees. 

Then one day someone invented the chainsaw.  By utilizing the chain saw instead of an ax the lumberjack was able to chop down more trees.  Changing from Axes to Chain saws was a tactical change for the lumberjack and the organization.  Despite the effect on profitability of the company, the overall company strategy did not change at all.

Because management is primarily strategic, management didn’t really need to change much.  On the other hand the lumberjacks needed to go through a change in thinking about what they cut down trees.  Some lumberjacks might object to the tactical change.  After all… trees have been cut down the same way for 1000′s of years.  Why then is there a need to change tactics? 

Many industries run into problem when they begin thinking that their tactics are their strategy are the same.  A good example is newspapers.  We all think of the newspaper business and we think about huge printing presses that print information on paper.   We all know that the newspaper industry’s strategy is to sell this paper.  What makes the paper valuable is the information, but the strategy is to sell papers.

Thinking about this idea I can’t help wonder what the lumber jacks would say who didn’t want to switch to chainsaws?  Are trees better if they are chopped down with axes versus a chainsaw?  By the same token is the information in a newspaper any different when read on a piece of paper or on a computer screen?  The reality is that lumberjacks that refuse to chop down trees with chainsaws won’t be able to compete with competitors.  Nor will newspaper publishers be competitive if they insist on using the same tactic for distributing information.   In the case of newspapers the strategy has become synonymous with the tactic. 

When the organizations strategy becomes synonymous with the tactic the organization will fail when the tactic becomes obsolete. 

This is important to understand because technicians and system administrators are primarily tactical roles.  The system architect is the bridge between business strategy and technology tactics for the organization.  The architect must build tactical solutions that support but don’t replace the strategy and vision of the company.  This is not always easy.  Many managerial teams really don’t understand the role of IT in relationship to the business.  As a result many technical people in the organization also don’t understand their own relationship with the organization.  Management’s job is to give a vision and develop the strategy for the organization including the technology departments.

The better the system architect understands the role of management and IT the less likely the organization will lose the strategic direction of the organization to the tactical requirements of the organization.

One of the more complex problems in network architecture design is redundancy.  Sometimes the principles of redundancy and disaster recovery become confused.  Perhaps because the more redundant the system the less likely the disaster recovery system seems to be needed.  There are a few systems that are so redundant that a disaster recovery system is not needed.   For small, medium, large and most enterprise networks there are very few environments where redundancy negates the need for disaster recovery.

So the first question, what is the difference between redundancy and disaster recovery?  The simplest way to understand the difference is by asking this question.  When does the system engage?  A system designed for after a failure is a disaster recovery system.  A system designed to prevent a failure is usually associated with redundant systems. 

For example:  Think about a server with two power supplies.  If one power supply fails does the server fail?  A second or redundant power supply is designed to keep the server running even if the first power supply should fail.  Two power supplies is an example of redundancy. 

Hard disk RAID arrays are examples of redundancy.  If one drive in the array fails, the system continues to run.  Often the disk can be replaced without shutting down the server.  Most of the components in a modern server are redundant.  In order for the server to completely fail every redundant hardware component must fail. 

So how is this different from a disaster recovery system?  A disaster recovery system kicks in after the system is down.  The classic example is a hard drive failure.  When a server fails, the number one worry by the management teams is the safety of the data.  In this situation the disaster recovery team restores the data from a backup.  A disaster recovery plan starts with the question what if we lose a file?  Then asks what do we do if we lose a drive or drive array?  Then what if the server fails?  Finally what if the site fails?  If there is no redundant system in place a disaster recovery plan is the last chance to recover from a data or system loss.

In a redundant system the architect asks the same questions.  If the server is lost, there must be another server that has the same information.  If an internet connection is lost another internet connection is available.  If a site is lost, there must be another site with the same information available to switch over to.  When considering the cost of the network design the rule is, “The more redundant the system, the more expensive the system.”   With unlimited funds every network would have unlimited redundancy, but in a world where funds and resources are limited most networks are a mixture of redundancy and disaster recovery. 

The architect meets with the business owner to decide the priorities associated with the system design.  Business critical production systems tend to be highly redundant.  This is because while a business critical system is down, the company is losing money.  Profitability and Organizational productivity are directly related.   Statistically when these types of systems are down it costs a small to medium size business $7,314.00, or more, each hour in productivity losses.  Successful large businesses see this rise to $50,000 / hour.  Some systems within a Fortune 500 company could easily cost $1,000,000 / minute in lost productivity.   Consider that for a successful small business a 12 hour loss can potentially cost the business $87,000 in lost productivity.   Redundancy is statistically 1/7^th the cost of repairing the system after a failure.

Yet non-critical systems failures can sometimes go un-noticed for weeks.  So the cost of making non-critical business systems redundant may not be worth the cost to the management teams.  Deciding which systems are business critical and which aren’t is a managerial decision.  The problem is that many often the management teams are left out of this decision process.   

When making availability decisions in my architecture here a question questions I ask myself:

“Does this decision affect the strategy or the tactics within the organization or the department?”

The logic tree behind this…

Premise:

• All strategic business decisions should be made by management.
• All technical decisions are tactical and should be made by the technician.

Conclusions:

Therefore: If a change made by a technical expert does not support the vision or goals of the company, a department or a team this is a strategically decision.   Therefore this change should be run by management before the change is made.

Therefore: If the change is made to reduce time or costs for the company, this is also a strategic decision.  Therefore this change should be run by management before the change is made.

Finally: If the change supports the present tactics of the organization, without affecting cost or time (positively or negatively) this is an appropriate decision for the technical team to make without running the problem by management. 

In this article I’ve discussed the difference between redundancy and disaster recovery.  Most network systems are a combination of these two types of systems.   As a system architect changes that affect the business vision, goals and strategy need to be run by management before they are implemented.  This is true not matter whether the change is made by a technician, system administrator or system architect.

I’m curious if others have seen the effect of confusing redundancy and disaster recovery?  I also wonder if others have seen negative affects when technicians made decisions that affected the strategy of the organization without realizing the cost of what they had done.