Change is always interesting. With the way technology is changing so quickly, I have begun to feel a little dinosaur-ish. Meaning that I get stuck in the old way of doing things and the idea of changing is becoming more and more daunting. I have been a Seattle IT Consultant for the last 20+ years. I’ve worked with the Apple IIe and other early computer systems. I started my career, switching from being a landscaper, in the DOS 3.0 days. So I guess it’s understandable that re-inventing myself seems more difficult today than it did 5 or 10 years ago. Yet I look around at our industry and I see that other IT experts have an even more difficult time changing.
So where are we at today in computers? I am doing a presentation in Seattle on CRM where talk about one of the dilemmas of technology. That’s where we embrace a new technology, but we try to do what we’ve always done. In my presentation I quote Ford, who is supposed to have said,
“If I listened to my customers, they simply want a faster horse.”
Yet we see how the automobile changed everything. In the early days of the car, manufactures tried to make the automobile look just like a horse carriage. Today’s automobile has four wheels and seats for people to sit in, but that’s where the similarity ends. Cars today would be unrecognizable to the early drivers. More importantly even in the 1950’s the last holdouts were still people grudgingly accepting the combustion engine. When I started 20 years ago we were trying to convince business owners to accept computers because typists didn’t have to start over when they made a mistake. Early business owners would accept a “Faster Typewriter” before they would accept the idea of a computer. Sounds like a similar dilemma for Ford, his customers wanted a faster horse. In the 90’s business owners wanted a faster typewriter. This is the dilemma of new technology, as it changes we thought what we really wanted was a faster horse.
You’d think as technology experts always promoting change, we’d get this? Yet when I look around, I see technology people who are having just as much problem changing. They are happy with where they are at and what they already know. I’ve seen it every time the technology changes. Each IT department wants to think about more servers, switches, routers and computers and think about them in the same way. There used to always be a division between the data guys and the voice guys (Now with voice over IP and Unified communications that division of labor is changing). As things changed we see managed services models replacing break/fix services (it’s cool technology, but it puts the break/fix troubleshooters out of business). I can list technology after technology that is more efficient and being replaced in the same way. So it’s surprising when I hear IT Support vendors who aren’t embracing the cloud. They seem to want bigger, faster and easier to manage servers and more of them. At the same time, they ignore the reality the reality that technology is changing.
So where are we at? At the beginning of the path? The end of the path or maybe in the middle? I personally feel we are just reaching the point Henry Ford reached when he setup his factory with the assembly line. Right now we are used to hand crafted technology where business technology is built from the ground up. Yet when Ford re-perfected the automobile manufacturing hand crafted automobile became an oddity almost overnight. Businesses that ignored the trend went out of business.
As technology experts we can’t get lazy or be afraid of change. The modern data assembly lines like the cloud, can only be ignored until your company or client is out of business. Then where will you be? If you aren’t migrating your systems into the cloud, you may just be you holding your employers or your clients back. The cloud may only be a marketing term, but it is the next step. If we try to convince our employers what they really need is a “Faster Horse” aren’t we just condemning our clients to the world of the dinosaurs?]]>
As a Seattle IT Consulting company I get lots of help from the most unexpected sources. This morning I got an email telling me about this great CRM add-on. My friend knew that I was giving a talk on CRM on January 10th here in Seattle. So shared with me something that he thought would help me out. I always appreciate this type of help. Who can keep up with all the new technologies going on. As I explained to him, I try to be vendor and technology agnostic in my approach. So I am always open to interesting options. I function at a very strategic level. Long before we know the technology that is required, I am working with a management team to identify the business problem that is going to be solved and the solution.
The reason I try to stay agnostic is that every business situation is different.
Car Dealer A has a different set of priorities from Car Dealer B… they might use the same technology platform or a different platform it depends on their requirements.
Now take a Trucking Company C that delivers shipping containers around the Puget Sound area here in Washington state. They may also be using the same technology platform as Car Company A, but it may look to the user as a completely different system.
The technician sees what is behind the Curtain (referring to the Wizard of Oz) and the technology platform may appear to be the same for each of these companies. Each company of course has servers, software, switches, routers and more. From the technicians context, the choice is mostly about the hardware and software platform. The technical perspective is that the car dealers and the shipping company have the same needs for information.
From the business perspective though, the technician doesn’t have a complete picture. Each company needs that information presented in different ways. Information requirements are dependent on the industry, the size of the company and more. Now add a small manufacturer that does closet customization or a small software development company focused on Mobile VPN or a craft beer brewer (my favorite type of client) or a coffee manufacturer/distributer. Each has different industry issues, managerial prejudices, size issues, long term goals and so on. While the platform might be the same from company to company, they each have a small portion of difference, that I call the custom bits. These custom bits make the business completely unique.
Most business owners don’t understand these custom bits and often leave these choices to the technician. This causes problems because the technicians context is so different. In order to understand them a business must first understand its own business requirements. I find that most business owners stop caring, they just want to move forward and don’t care about the details. My role is a problem management role and is to push back and encourage them to start thinking strategically about their technology… I usually start with what I call my –ability analysis… I have them rate an order for these abilities for their technology
It starts with these five. I have them number each one in priority from one to five. As we do this, the technology choices become more and more obvious. If for example Scalability (my personal favorite) were top priority we would analyze the proposed tool from the context of scalability as the top priority. If usability (most managers preference to maintain productivity of their workforce) we analyze the software from this first priority of usability. Then we go to the second, the third and so on.
By the time we get to the bottom of the list we may have added more abilities… but the answer becomes quickly obvious what the right choice is. So this add-on might be perfect for one business, but not another.
I love it when people I trust do free technology reviews of new software as my friend did for me. I never have enough time for this type of review. So it’s appreciated when someone will do the work for me. These types of people are becoming my informal IT Support team. I find that anyone willing to dedicate some free time to me, that actually is what I need, seems to get referrals and work from me. I’m beginning to suspect that I have a much bigger team backing you up than meets the eye. It gives me pause, because I think that this is the weakness I keep running up against. As I finish this article I realize that my own issues focus around sharing this leadership vision of what I need with lots of people. Then letting them help me build my business with their help. So here’s my question for my readers…
How do I build these types of IT Consulting teams that support me in a way that supports both of us, while at the same time not getting lost in the management of those teams?]]>
In working with clients between about $800,000 / year and 5 Million dollars per year, companies need to make a change. I started out as more of a Seattle IT Cowboy than a Seattle IT Consultant. I thought IT was about fixing broken computers. As time went by though, eventually the companies grew and there was too much work for a simple cowboy. It became necessary to become a team player. What does an IT team look like? To understand this I wanted to start with the IT Support tactical roles and how they should interact. I like to use the term “healthy conflict.” In this article I wanted to talk about the operational roles and conflict between Incident and Problem management.
The IT tactical roles support the IT strategic roles leveraging the “Healthy Conflict” strategy we’ve described.
Incident – Failures on the network starts with the incident management role. Incident management first makes a determination if this is a known or unknown error. The majority of errors are known errors and are handled without a great deal of problem by the incident management team.
Problem – Problem management focuses on unknown errors. These types of errors require a much more in-depth understanding of the problem. Sometimes requiring log file information that occurred during the error. Sometimes even a re-creation of the error in a test environment of equivalent systems.
The most common “healthy conflict” in IT is between the Incident team and the problem management teams.
The 1st priority of the Incident team is to get the system up and running as quickly as possible. This way less productivity is lost. While the incident is being solved; a user, set of users or even an entire company is down. While the system is down, the company is losing the productivity of the employee and the business systems. The risk though is that by not understanding the problem the same problem may (and probably will) re-occur again and again until the root cause is understood.
For the problem manager, the priority is different. Instead of bringing up the system quickly; the problem management team’s 1st priority is root cause analysis. An incident manager can reboot the server and if the server functions the way it’s expected, the incident manager’s job is done and the ticket is marked resolved. The server may fail again in an hour, a week or next year. The incident manager doesn’t care, once the ticket is resolved the Incident manager moves on to the next problem. The problem manager’s job is to look at the “resolved” ticket and determine why the incident happened. If the problem has a known cause, the ticket is then marked closed. If the ticket is determined to have an unknown cause, the ticket goes into the problem manager’s cue for root cause analysis.
The root-cause analysis process is a long forensic journey looking for hidden clues. The root cause could be a failing piece of hardware, mistakes in the software program, a misconfigured setting or even a mistake in the business process. The analysis review may search through log files, software code, interviews with the incident manager and even with the non-technical employees who discovered the problem.
What I’ve found working the last 21 years as a consultant, is that this healthy conflict is essential for a well-run IT department. When these teams are separate people with opposing objectives, more quality work gets done. Where without this conflict, more problems arise as one or the other team players begin to dominate the leadership of the organization.]]>
Most IT experts are thinking tactically. Our job as is to think about how to do things. How am I going to keep systems up and running? How am I going to fix something that failed? How am I going to do what I’m doing more efficiently? We look to the leaders in the organization for why? When I started, I only wanted to know what it was that you wanted me to do. I never asked why? When I became a Seattle IT Consulting expert I found that asking the question “Why”, was a much more important question. I’ve found that IT professionals with the most experience answer every question with the comment, “It Depends.” What they are really saying is why.
Asking “Why?” is the first step in building business value.
If we want to increase the value of a business, it’s first important to understand in what ways the IT department or an IT Services vendor can improve the value of the business. There are at least 5 ways to value a business. To complicate this more each industry has a different valuation metrics. For example a Dry cleaning company could be valued by 70% of annual sales plus the value of its inventory. For a law firm the value would be between 40 and 100% of annual revenues. The book value of a business is Tangible assets minus Liabilities.
No matter how a business is valued, the ability to create cash flow is essential. Cash flow is a basic equation of income minus expenses. With cash flow, assets can be increased, liabilities can be reduced. A movement in either of these directions increases the value of the business. Technologies strength in increasing business value is to reduce the cost of doing business. Technology has always reduced the cost of doing business. Horse drawn wagons carried more freight than a man could carry. Horse drawn wagons were the technology that reduced the cost to deliver goods from one location to another. Train, trucks, automobiles and even airplanes reduce the cost even further. As an example: A freight company depending on human baggage carriers will never compete in today’s market.
This is the value technology brings to business. Early adoption into technology gives competitors an edge. Now business can save time, costs and even improve the quality of their products or services competitors can’t achieve. Cash flow and profit is determined by income. Income levels are determined by the expense required to create that income. Utilizing technology to reduce expenses, income is automatically increased. As income is increased, the value of the business is increased.
Cloud technologies becomes a latest method of reducing expenses for small and medium size businesses. This is done in multiple ways including: Reducing Capital expenses, increase workplace productivity by decreasing IT downtime and negating the effects of depreciation of long term technology assets including servers and supporting technologies. Simply by moving into the cloud, IT downtime can be improved from an industry average of 90-95% to less than 1% downtime. Increasing workplace productivity alone by 5% can easily equate to an increase in business value of 30%]]>
I work as a Seattle IT Consultant, sometimes as a part time CIO or technology architect for my clients. One of my potential clients was struggling with the concept of strategic business strategy and asked,
“Give me examples of ‘business technology strategy. Define this for me. Tell me exactly what it is you put together for clients.”
It’s a very good question, hard to explain, but at an important question. Most people are either tactical thinkers or strategic thinkers, with the majority thinking tactically. So the simplest way to start is to compare IT with Accounting. I’ve used this Accounting Analogy before, but bear with me…, There are four main accounting roles that correspond to four main IT Roles:
• CFO CIO
• CPA, Controller System Administrator, System Architect
• Book Keeper Technicians
CFO’s & CIO’s think strategically
CPA’s & System Administrators, manage the day to day business accounting systems
The Controller and System Architects design and verify that the day to day system processes meet accounting or IT standards
Book keepers / Technicians track the day to day record keeping under the direction of the CPA.
The accounting system is designed so there is a natural confrontation between the CPA and the Controller. In the same way the System Admin and the Controller conflict in healthy IT Departments. We also see this between ITIL roles for Incident and Problem Management.
The C-level executive in both departments will go to members of each role for specific advice, but would recognize the context of that advice and the training and understanding of the giver. He/she would also understand that they are strategic roles who are focused on the day to day activities. They are not thinking about the long term strategy of the organization, nor are do each of these roles have a big picture of the entire organization.
The problem I find though is that in SMB organizations and this model is not defined at all. Someone who is a technician is expected to play every role, Including the roles that should be confronting one another like system administrator and architect. When I see network failures, I’ve noticed that these roles are not well defined. The system administrator is also playing the system architect role. In accounting this is a big red flag when the CPA and the Controller are the same person. Similarly In IT departments red flags should also go off for the CIO and the CEO of the organization.
What is happening with most IT vendors and in most IT departments is that a technician (an equivalent role to a book keeper) is doing the system administration, designing the network and doing the 5 year planning for the organization. In other words the technician and even a good system administrator are not qualified to function in a 5 year planning role. Nor is there a role that is in conflict with the system administrator making sure the system administrator is following best practices. Finally most of these vendors are assuming that a network is a network, so as long as they build it and control it, the business should be fine.
Systems have technical failures, but fix for future problems isn’t a technical solution. Rather the solutions should be to fix the business organization in the IT group.]]>
I spoke with another client. He was a small client who was considering going back to night school to study technology. He described how difficult life is being held hostage by his IT consulting company. I’m hearing this more and more often as I talk about cloud network architecture. Our clients are feeling like hostages to their technology and to their IT consultants. I think the modern network architect needs to understand how to build systems that enable not trap the business owner.
Imagine a client that is so frustrated with the situation that he gives up talking to his IT support company and goes back to get a school to free himself. I’ve begun asking questions of business owners, “Do you feel like a hostage to your IT department or IT contractors.”
The facial emotions quickly go blank. Almost as if they are thinking, “… But you are the enemy… can I trust you with the truth?”
I explain why I’m asking the question. After hearing that many business owners feel the same way a sense of relief seems to overtake the owner.
Then they admit that yes they do and then I get an earful about the problem
Having worked with IT experts for many years I know that most IT Experts are doing the best they can for their clients. The problem isn’t that they aren’t trying to do a good job. I think the problem is ignorance about the needs of the customer. I think there is also ignorance about some of the basic roles within technology. Most IT Support experts focus on Incident support and little focus on Problem management or root cause analysis. So it’s no wonder that problem keep re-occurring over and over again. This is probably also why most on-premise networks are managed without a Service Level Agreement (SLA) for availability. A professionally run IT Consulting Company understands the conflict cause by the technical power of the technologist and the effect they have on the bottom line.
I think this is one of the biggest advantages of the cloud. The cloud will move on-premise networks out of the office building and into a professionally run network operating center (NOC). The NOC will have incident and every other IT Operations role. Once in the “Cloud” the owner will get the same type of reporting and feedback that he/she gets from the other departments. The political power that the technician has over the business and the business owner will be lost. With cloud architecture the modern network architect will be releasing the business owner from being a hostage to IT.]]>
I saw it ten years ago, I see it today. A network is built. The business systems are built on the network. As the business grows, the technology remains the same. As the business grows further, the technical systems begin choking the productivity of the organization. The next step in the cycle is that the business stops growing because the network capacity has stopped growing. What I’ve found is that the IT expert before me was doing the best he/she could. The problem was that their experience was with smaller businesses and smaller business systems. Once the business outgrew the knowledge of the IT staff, the productivity stopped growing as well. I call this limitation in technical knowledge the IT departments technical glass ceiling. The modern network architect must keep raising his/her own technical glass ceiling.
If you think about it… well it makes sense. A kid out of high school can connect a few computers together. The concept is not that big of a jump. Many teenage boys spend their weekends connecting up their computers in order to play computer games together. While the principles the same, does it lend itself well to a business that that has grown from 10 to 100 employees. Now the knowledge level of the high school kid has been exceeded. Not that the kid realizes it yet. Nor does the owner realize it yet. When it becomes obvious is when the network goes down for days or weeks rather than hours.
When that network goes down a new technician comes along. Yet the cycle repeats itself. Now the technician grows the technology until his/her technical glass ceiling is reached. The technician doesn’t want to give up the contract and keeps trying “work-a-rounds” to keep the business running. Until one day… the network fails again. Now an IT Consulting Company takes over. This IT Services Company has an even higher technical ceiling.
I’ve found it’s not uncommon for this cycle to happen over and over again.
The problem is further complicated as technology changes so quickly. Experts at NT 4.0 had to re-invent themselves to work with Windows 2000. Then again become experts in Windows 2003 technologies and finally 2008 technologies. In the meantime new technologies like email servers, database servers, web servers, security and many other issues on the network distract the technician from relearning their basic technologies. What worked in NT 4.0 doesn’t work in Windows 2000. Windows 2003 is a new design problem from Windows 2000 and Windows 2008. Many technicians are flying by the seat of their pants. Nobody knows it all. Yet technicians are being asked to do more and more and more. It’s no wonder we reach our technical glass ceilings more and more quickly.
What do you do to compensate for the drastically quick changes in technology? Some ideas I’ve tried,
I’ve been in the industry and re-inventing myself for almost 20 years. What are you doing to re-invent yourself for the new technology changes to come? Two technologies that I am seeing will change the face of technology more than we’ve seen since the DOS 3.0 days are cloud network architecture and unified communications. What are you doing to keep yourself ahead of the curve?]]>