I didn’t realize I had a problem on my hands until the wife of my absentee sales person called to ask one morning if we had seen her husband. There had been red flags leading up to this day that I had foolishly chosen to ignore. This sales agent hadn’t been able to close sales for months and I continued to give him additional chances to prove himself. Then one day, he closed six sales within a time span of four hours—a remarkable feat. I couldn’t believe this amazing turn of events. I thought the guy had finally figured it out! But the day after the products were shipped out the door, my wunderkid didn’t show up for work. I discovered the “sales” that he posted were fictitious and over $15,000 worth of merchandise was already being shipped across the country to non-paying customers.
This was just one of several experiences with employees that didn’t work out—sometimes referred to as rogue employees. This blog post recaps a few incidents with wayward employees and what we did about it.
The Rogue Programmer
Within six months of starting our first software company, I hired a programmer that I thought was first-rate. I gave him generous benefits and supported him in every reasonable way. He eventually wanted to move across the country and work from home and I supported this as well. This was well before working remotely had become common-place. There were no safeguards in place to be sure work was being done and yet I was prepared to (naively) trust this programmer unconditionally. He did not upload his code to the software repository as he had claimed to be doing, nor did he submit progress reports. Requests that he be more forthcoming and open about his work product resulted in him clamming up. Two months later, I made the trip across country to see if anything he told me was real. The surprise visit did not go over well and he refused to hand over anything, including the code he claimed to be working on. Our professional relationship ended on the spot, an outcome I should have anticipated. Clearly, when no safeguards or performance measures are in place, productivity is sure to go flat.
Not Rogue, but Without Experience
I hired another programmer early in my software career entirely on a gut feeling that he was a solid choice. He was a PhD student in computer science from a top-notch university, but I soon discovered that he lacked key practical experience. Luckily, I caught his limitations early on, but I haven’t always been so lucky. Other programmers I’ve had, stayed with me long enough to cause some serious damage in the form of introduced bugs and code that was so confusing we had to unscramble it for weeks.
The (Costly) Naïveté of a Start-Up
Start-ups that are desperate to save money are vulnerable to the hidden costs of cutting corners. Young businesses don’t have all the checks and balances, the benchmarks and performance measures in place because these companies are just trying to catch a break. Get employees on board, we tell ourselves, and you will work out the kinks as you go along. We are idealistic enough to believe that a minor adjustment here or there in written policy or a frank meeting with an employee will be enough to sort it all out. The fact is that we have all had to deal with employees that for one reason or another were not a good fit and the resulting costs to the company can be substantial. In some extreme cases, the employee’s behavior turns vindictive as he or she purposefully withholds information or tries to sabotage workflows (fortunately this is an exception and not the norm).
A System of Checks and Balances
Eventually, in the case of sales, we came up with a system based on the historical performance data of our top performers. By comparing a new salesperson’s weekly performance record to the sales data of our veteran staff at a comparable time in their career, we can track their progress. Are the new guys achieving the pre-defined benchmarks? Is the new sales person progressing as would be expected of a solid performer? An early disconnect when comparing records would suggest the new hire is not on track to success. With respect to programmers, we have adopted the use of a practical programming test that determines if a candidate can actually code or whether his qualifications just look good on paper. And, our daily stand-up meetings mean that an engineer or programmer cannot “go dark” for very long. I don’t have much time for guesswork or gut feelings anymore; raw analytics tell me more.
The value of a manager who reports directly to you is irreplaceable. Fact is that whether we are dealing with engineering, programming, marketing, sales, or human relations, I need a direct report that checks work day to day. I need someone who has a detailed grasp of how each employee is faring in their department, and this person needs to transparently share his or her assessment with me. These are the checks and balances I have implemented that protect us from making costly mistakes, or at the very least, from hiring rogue employees.