What does it mean when the key technology expert suddenly finds another job? Once or twice a year, for the last twenty years I get a call like this.
“James, our top IT guy just put in his two weeks notice. I’m not sure we can function without him. What should we do? Could you come over and help!”
What I’ve found is that there are three reasons key technical people leave:
- About 20% of the time – The person is bored, went interviewing and got a much better offer.
- About 40% of the time – The person realizes they are in over their heads in that the technology requirements have passed their understanding and experience. Unfortunately, the person is not able to express this to management (or management just won’t listen). So they abruptly leave.
- Again about 40% of the time – The person was too ignorant to realize they were in over their heads. Later the IT Technician sees a major technical emergency in the company’s future. Something so bad, usually business impacting, that will get them fired. Instead of telling someone, they find another role at another company. It may be 1 week to 6 months later before everything begins falling apart at the original company.
In every case, the person leaving walks out the door with undocumented company information they picked up on the job. The information could be anything from server settings to true intellectual property. This undocumented information is what I mean by “Tribal Knowledge.” When tribal knowledge walks out the door, a piece of the company walks out as well. Lost tribal knowledge is a business risk that will impact the business value of the organization. Risk mitigation means finding a way to capture tribal knowledge before it walks out the door.
In another article The Secret of 80/20 in IT Due Diligence, we talk about the idea that 20% of causes result in 80% of problems. In the case of technology, dependence on IT tribal knowledge is one of the 20% causes that negatively and directly affects employee productivity. Employee productivity ultimately has an effect on potential earnings. Especially when a key technical employee leaves.
Here’s a common Mid-Market business example
This could be almost any IT department in the US. In this made-up example, before a recent spurt of growth, there had been one IT technician supporting 10 business servers and 50 users. Recent growth had increased the user base from 50 to 250. This increase in user base required the company to increase the number of servers by 15 to 25 servers. The original technician, Andre, was made the technical lead for two newly hired and very experienced technicians, Juan and Samantha.
Tuesday morning, a user reported a problem to Samantha as she was walking onto her morning shift. Samantha went to one of the old servers and fixed the problem. At the same time, another user reported a different problem to Andre as he came into work. While fixing the second problem, noticed a change on the same server. After fixing the second problem, reset the change that Samantha had just made back to the original setting. In the process breaking the fix Samantha had just made. Juan, coming off shift, is approached by the same user who approached Samantha. The user mentions the problem to Juan as well. Explaining that the problem was still not fixed. Before he left, Juan made the same setting change that Samantha had made just 20 minutes earlier.
While this example is made up, the example is based on a common problem in IT support teams. In the course of 30 minutes, the same setting was adjusted 3 times without the knowledge of the other two technicians. This is something that would never happen with one technician in charge. Now multiply this by 20, 30 or even 100 settings changes in a single day. The problem can quickly escalate and become impossible for technicians to troubleshoot. In this case, Andre had always tracked all the setting changes in his head. Now with two other technicians, no system was in place to handle this problem. Andre was just trying to do his job. Unfortunately, it can get worse. It’s not unusual to see technicians to hoard what they’ve learned while fixing problems. Never sharing knowledge with other technicians. Many technicians see this as a source of “job security.”
Fortunately, Samantha and Juan had come from larger networks. When they realized what was happening they suggested a Change Control Log. They explained to Andre that all setting changes made by a technician are recorded in the log. Then the change policy is to review the log before making any systems changes. Unfortunately, Andre was unconvinced by this idea saying, “… but we’ve always done it this way!” Insisting that Juan and Samantha check with him before making any settings changes. This just made Andre’s job more difficult as he became the bottleneck for all troubleshooting. Andre’s hours suddenly climbed. He found himself working weekends and never taking vacations. Being the tribal knowledge holder he became more critical as an employee. After a couple years of this Andre began to burn out. Andre was approach and offered a job by a competitor. When leaving took all his change control tribal knowledge with him.
Let’s look at the problem as a business investor. In our example, we had a user whose system stopped working twice in 30 minutes during the confusion between Samantha, Andre, and Juan. Multiply this by 250 users during that 30 minutes. This could quickly have become a business impacting problem. Statistically,
- $40,000 is the hourly loss in worker productivity when technology is down company wide
- Managers spend 10% of their week (200 FTE hours/year/manager) putting out IT fires
- Companies with a week of downtime have a 90% chance of bankruptcy within 12 months
- Companies whose technology is 98% Available/year have 7 days of downtime/year
- Most mid-market on-premise networks have only a 95% availability rating.
What this tells us is that a key indicator of worker productivity is technology Availability. Any mid-market company with a technical availability of 98% is losing 7.31 days of potential employee productivity/year. Those lost hours represent a statistical potential loss of $2.4 million dollars/year in employee productivity. Simply by increasing availability from 98% to 99% availability, lost potential employee productivity is reduced to a loss of half or $1.2 million/year. A simple Change Control Log can mean the difference between a loss of 2.4 and 1.4 million in lost potential worker productivity. If only 50% of the potential was recaptured, that would mean a 1.8 million dollar increase in the company earning with no additional cost. With an EBITDA multiplier of 3, that is a 3.6 million increase in business value. Created simply by capturing a small percentage of tribal knowledge in a simple Change Control Log and changing the troubleshooting process to include a review of that log before making a system change.
We see this as an opportunity for the investor buying a successful business. It’s reasonable to make a simple request to review the Change Control Log during the due diligence phase. If there is a change control log (and other types IT department information) of some kind, it speaks to risk mitigation practices in the organization. We can expect that the company is designed to scale and grow. On the other hand, without these type of tracking the investor knows ways to quickly and significantly improve risk mitigation, employee productivity and ultimately business value.
Most technology companies don’t think this way. Which just means that as an investor, you need an IT Due Diligence firm that does. If you are an Investment Banker, check out our M&A IT Due Diligence Firm evaluation form. See if you are getting what you need during the IT Due Diligence phase of the business sale.