How not to run a business (Part 5) — Meeting Edition
In this edition of ‘How not to run a business’, the topic is meetings. Do they help or hurt your business? Let’s explore. I’ll start this one out with a ‘Do’.
Do set up meetings between sales staff and prospective clients
Sales meetings are entirely out of the scope of this article. Sales meetings are the only truly critical and needed business meetings. Sales meetings are also part of a salesperson’s job. So, for sales meetings, bring in anyone who is needed to ensure a deal is closed. If that means bringing in technical staff, then do it. If that means bringing in the CEO, do it. Of course, the personnel involvement level also depends on the size of the deal. If it’s a $10 a month deal, this is probably not worth involving everyone in the company. If it’s a $300,000 a year contract, then by all means create meetings with whomever it takes to close this deal. Sales meetings are the only type of meetings where some of these rules below do not apply. So, keep this in mind when reading through this article. The only other piece of advice I will add that’s outside of the scope of this article is, don’t oversell. That is, your sales team is there to help close deals you can actually support. Your sales team should never close a deal based on something that doesn’t presently exist as a product. Selling vapor products is a huge corporate no-no.
Don’t create a meeting based on personal opinion
Meetings are about communication transfer, not about personal opinions. Yes, we all have opinions, but business meetings are not the platform to express your opinion. You can do this in email or stopping by someone’s desk. Opinions impart no useful information about an objective. Getting the job done and whom handles specific pieces of that job, that’s a valid reason to gather a meeting. Discussing why you don’t like something about the business, that’s opinion and irrelevant to the job at hand. If you have an opinion that leads to a fundamental design change that works to solve a problem, then by all means create a meeting involving the design change, not involving your opinion.
Don’t expect productivity from employees while in meetings
Meetings quite simply halt employee productivity. When an employee is away from his/her desk in a conference room listening to someone discuss something irrelevant to their job at hand, then that is quite simply lost productivity. As a manager or business owner, you hire your employees to be at their desks doing the job you hired them to do. However, if they are continually being required to attend meetings, they cannot be at their desk doing that job you hired them to do. This means that for every minute of time the employee spends in the meeting, that’s minutes you paid for that employee to not do their job and not be productive. Meetings often solve nothing which leads to completely lost productivity.
Don’t expect your employees to make up for productivity lost while in meetings
If an employee spends half or more of their day attending meetings, don’t expect that employee to put in overtime or spend after hours time making up for lost productivity in those meetings. This is a completely unfair work life balance request. You have then asked them to sacrifice their personal time (either on or off the clock) to make up for that lost time spent in the meeting on the clock. This is not fair trade and is not be expected. If you expect this, you will eventually lose the talent it took you so long to actually find and hire.
Don’t call meetings with people who do not need to be there
Invite only the absolute minimum people you need to any meeting. Everyone else can learn from someone else. So, if a manager has 10 staff, only bring in 1 or 2 staff to attend a meeting and leave the rest at their desks working. Don’t invite all 10 of those staff simply because you want to have a staff meeting. You can rotate your staff through the staff meetings weekly so that each of them participate in a staff meeting at some point, but they don’t all need to be there every single time. Alternatively, sit with your staff at their desks one at a time and spend 5 minutes or so catching up on expected completion times for projects or other deadline work.
Don’t hold hour long meetings
Meetings should be as brief as possible. Fifteen (15) minutes is long enough time to impart most necessary information and simultaneously short enough to prevent the meeting from degrading into a pissing match between several people or other non-related discussions. At the same time, it prevents employees from being away from their desk and not being productive. Productivity is the key to your business success. The more productive your employees are, the more productive your business will be. Lack of productivity can be directly attributed to useless meetings among other time wasters.
Don’t hold (or allow your staff to hold) useless meetings
What exactly is a useless meeting?
- Meetings that rehash existing topics and add no new information.
- Meetings that are simply platforms for employees to express opinions.
- Meetings that discuss extremely distant possible future projects without knowing any exact information.
- Holding excessive numbers of meetings in a single day (leads to meeting overload).
- Meetings that are overly long and overly verbose.
- Meetings that degrade into unrelated topics.
- Meetings that end up with multiple groups dividing and talking at once.
Meetings need to be as long as is necessary to explain a given topic, short enough to limit productivity loss.
Don’t hold meetings every single day of the week
Employees want to work at their desk, not sit in conference rooms doing no work and listening to someone else chatter. You hired your employees to do a job, having too many meetings is wasteful and also means you’re paying these employees for sitting in meetings rather than doing the job you hired them to do.
Don’t allow staff to hold meetings that consume nearly every work hour
When a company gets to a certain size, usually above 100 employees, meetings start becoming excessive. People begin scheduling meetings to discuss any and everything. I’ve been personally pulled into meetings that have consumed every single hour of my work day including, no surprise, the lunch hour. Granted, free food was supplied, but that doesn’t make up for all the work that didn’t get done. This is meeting overload. At the end of the day, you walk away from work knowing you got nothing done and, at the same time, feel like the meetings accomplished nothing. So, it was a completely unproductive day. But, my employer paid me nonetheless. Then the employee comes to the realization that they have about 3 due tasks the day after that meeting stretch. Meetings should not pull in staff who have critical deadlines the next day.
Don’t hold meetings during lunch hour without supplying lunch
If you plan to hold a meeting that spans through the lunch hour, then supply lunches to your staff. Don’t expect them to take a late lunch or skip their lunch as they might be tied up getting other work done and have no time to take a lunch after that meeting. This is both unfair to the employee and can get your business into legal hot water if any employees file a grievance. If at all possible, let your employees leave for lunch and reconvene the meeting after lunch is over or, alternatively, expect to order lunches for meetings that span the lunch hour.
Don’t let your meetings run long
Meetings need to be a predetermined length. Many times, meetings can degrade into a pissing match between one or several people over a single thing. Nip that behavior out quick. Have these employees table the discussion for later or have them take the discussion out of the room. The rest of the attendees likely don’t need to hear or even want to hear those discussions. Additionally, if you are unable to impart all of the information you expected to and the meeting is at an end, schedule a followup meeting for later, but not the next day. Let the people digest what they’ve heard. By the time you reconvene, there may be new information that would have invalidated your extra information (or even the entire meeting). If you can cut your meeting short, then do so.
Don’t feel obligated to use all of the reserved meeting time
If you have reserved a one hour slot, but you are done with what you need to say in 10 minutes, leave the conference room. Do not continue to hold the meeting after 10 minutes simply because you have the meeting room reserved. Let your employees get back to their desks as fast as possible. You hired your staff to do a specific job, let them do it. Remember that keeping people in extended meetings takes employees away from their desks.
Don’t schedule excessively long meetings
Schedule only the maximum amount of time you need to impart the information required. Don’t write a novel sized agenda, set up a 4 hour meeting and expect many attendees. Business meetings need to remain short. The shorter the better. Fifteen minutes is the optimal time. Long enough to get done what you need, short enough to get people back to their desks to become productive.
Don’t expect great things out of meetings
Meetings are a mixed bag. Sometimes they work, sometimes times they fail. I’ve been to many meetings where nothing was accomplished. That is, we were no better off after attending the meeting than before we joined the meeting. If you suspect (or know) your meeting will not bear fruitful results, then bring in the minimum people. If you didn’t realize your meeting would be fruitless, then you will need to understand why the meeting failed before setting up another meeting of that same topic. Don’t continue to press a failed topic if it’s not going anywhere. Drop the topic and move on.
Don’t schedule a meeting between two people
Meetings are intended for 3 or more people unless it happens to be an interview. Two people conference room meetings are a waste. Send email, call them or stop by their desk to ask your questions. Don’t go through the motions of reserving a conference room for two people.
Don’t expect as much produced from a meeting as can be produced from someone at their desk
Employees know their jobs. They know what they are doing. Or, at least they should know what they are doing as that’s why you hired them. Meetings are generally designed to discuss unknowns (how do we do this, how can we fix that, what happened with this, where are we with regards to blah, etc). Some of these questions can be asked one-on-one to the individuals involved and do not necessarily need 20 people together to ask this single question and get this single answer. Taking a number of people away from their desks for extended periods means that the employees are getting further behind in their work for topics that could be better handled in other ways. So, those employees now have to make up that one or possibly several hours of dead time for work that they were unable to do while sitting in a conference room. So, pull in only the people who absolutely must be there. Don’t bring in people who have no participation in that discussion.
Don’t use a meeting as a public whipping post
Meetings are and should be about business topics. That is, topics that further the business along. Meetings are not intended to be used as subterfuge to get people in a room for group tongue lashings. If you need to chastise an individual or group for failing to perform, do this one-on-one with each individual. If you need to have a group fail discussion, then produce an improvement plan. That is, design a ‘Here’s how we can do better next time’ approach. Chastising people without a way to correct the issues is fruitless. This type of meeting only serves to demoralize the team without anything productive from the meeting. Again, if you need this type of meeting, then bring in something positive to the meeting by discussing how to correct the issue and with improvement points for each team member to work through. Putting together a fail meeting solely chastise employees can open your business to legal hostile workplace issues, so be careful with these types of meetings.
Do encourage other communication methods for meetings
With GoToMeeting, Skype, Hangouts, IM and SMS you can easily talk to people in many other ways than holding a physical gathering in a room. Find alternative methods to keep people at their desks. At the same time, they can attend and participate in the meeting when they are needed. Otherwise, they can be productive at their desks. Taking your staff away from their desks for conference room gatherings is the fastest way to lost productivity that you are actively paying your staff to produce. Keep the people at their desks rather than sitting in a conference rooms listening, but producing nothing.
← Part 4 | Chapter Index | Part 6 →
How not to run a business (Part 4) — Performance Evaluations
Do employee performance evaluations help or hurt your business? Are evaluations even necessary? The HR team may say, “Yes!”. But, that’s mostly because they have a vested interest in keeping their jobs. If evaluations are performed incorrectly (and the majority of the time they are), they can hurt your company and your relationship with your employees. Employee evaluations are also always negative experiences, so even this aspect can hurt your relationship with your employees. Let’s explore why?
Don’t let your Human Resources staff design the employee evaluations
If you absolutely must create and implement the tired ‘once-a-year’ evaluation system, then at least make sure you do it correctly. That is, assuming there is a ‘correct’ way to do this tired old thing. Employee evaluations should be designed by someone who is knowledgeable with writing evaluations and who has written them in the past. Using a service company like SuccessFactors or ADP to deploy your evaluations is fine, but is not required. Someone must still be tasked with designing the questions asked of the employee during the evaluation process.
Make sure your designer fully understands what is being asked of employees during the process, how it pertains to your business and most importantly, that the questions pertain to job performance and not to nebulous concepts like ‘core values’. Make sure the evaluation asks questions related to an employee’s actual job performance. The questions should also be relevant to all job roles within the company. Evaluations that target the sales teams with questions surrounding ‘customer interactions’ won’t apply to technical roles that have no customer facing aspects. Either create unique evaluation question options that apply to each department, or keep the questions generic enough that all job roles fit the questions.
Don’t ‘stack’ your evaluations
By stacking, this means that you should not mandate your managers give a certain number of excellent, good and poor reviews (i.e., ‘stacking’ the reviews towards certain employees — a form of favoritism). If your managers happens to have very good teams, stacking means that one or more than one of these individuals will end up with poor performance reviews, even though they performed well. Stacking is the best way to lose good employee talent.
Your staff has spent a lot of time and effort trying to locate the right employees for each job. With one stale (and lopsided) internal process, you may effectively, but inadvertently walk some employees to the door. Employees won’t stay where they feel they are not being treated fairly even while putting out high quality work. If a good employee is targeted with a bad review, don’t underestimate their intelligence to notice your stacked evaluation system and write about it on places like Glassdoor. Keep in mind that this is especially important for technical roles where talent can be extremely hard to find. Note, there are underperformers, but a once-a-year evaluation process is not likely to find many of them. Only can on-going, regular evaluation processes will find underperformers. Even more than this, only the manager can find underperformers via weekly one-on-one sessions, going through each employee’s work output.
Let your evaluation chips fall where they may. If a team ends up all with excellent reviews, so be it. Don’t try to manipulate some down because you feel the need to reduce cost of living wages. This comes back to paying your employees what they are worth. Note, this assumes that reviews will be tied to merit increases. Don’t assume that employees don’t know that the evaluations are stacked when you stack. That’s not only a condescending view, it way underestimates the intelligence of your workforce. If you’re thinking of decoupling evaluations from merit increases, see the next Don’t.
Don’t decouple evaluations from some form of merit increase
If you decouple employee evaluations from merit increases, you decouple the reason for employees to do evaluations. The question then becomes, “What’s the point in doing this?” If there’s any question surrounding the employee evaluation process, then your employees will not be motivated to participate. This also means that your evaluations will be worthless in the end. And, the employees will also know this. By tying the evaluations to merit cost of living increases, this ensures that all employees are motivated to participate properly in the process. However, keeping it tied to merit also means that this could lead to ‘stacking’. Avoid ‘stacking’ like the plague. If you really want to keep your employees on board, then let the evaluations remain truthful.
Additionally, when you decouple merit increases from the evaluation process, why have evaluations at all? Managers should be regularly evaluating their employees for work output and effectiveness. If they aren’t, then you have a bigger manager problem on your hands. If there’s no real reason to do evaluations, expect some employees to opt-out of the review process. If they chose to opt-out, let them. Forcing them to participate only leads to forced evaluations which may ultimately have them leave the company anyway and provide you with nothing of value.
Don’t require employees to rate their own performance numerically
Numerical or ‘star’ ratings are worthless. Numbers say nothing about the employee’s work ethic or performance. They are a failed attempt at trying to ‘rate’ an individual. The trouble is, if you artificially make the scale low by saying ‘No one is a 5″ on a scale of 1 to 5, then you have made the scale effectively 1-4. Then make the scale 1-4 and not 1-5. If you are using a scale of 1-5, then use the entire scale. If a person is a 5, then they are a 5. They are not a 4. This is similar to stacking. Do not artificially limit the use of something within the evaluation to make high performers appear lower than they are. This is counter productive and unnecessary and makes the employee feel as though they are under-appreciated. If that’s the intent, then it’s a job well done. However, it may lead to employee loss. Again, you spent all that time recruiting the talent, don’t squander that time, effort and money spent. Rating employees and artificially capping the scale is yet another visible employee negative.
Don’t do employee performance evaluations simply because you can
Employee evaluations are important for the manager and the employee to discuss performance issues and where performance can be improved. That’s the point in this process. It is not about anything other than how to get the manager and the employee on the same work page. Running this through multiple managers and multiple staff all the way up the chain to the CEO is pointless. Not only is it a severe time waster for those above the employee’s manager, it’s also a privacy issue that, for some reason, upper management and the human resources department alike think they should be privy to. In reality, any performance issues are between the manager and the employee. Ultimately, because of upper management prying eyes, any actual performance issues are not likely to present on an evaluation because it might actually become a hostile workplace or HR violation issue. Most evaluations are highly sanitized by both the employee and by the manager. Any real work issues are discussed in private between the manager and the employee. They are never included on HR based performance evaluations.
For example, an employee with poor hygiene and who is causing issues around the office could cause some severe HR legal issues if this information is placed onto a written employee evaluation. Yet, it is a performance issue. How do you document this without causing potential legal issues? This is the problem with once-a-year employee evaluations. Employee evaluations tend not to document the types of issues which result in legal issues for a company. These types of issues are sanitized from evaluations for this reason. This also means that company wide evaluations are by their very nature not completely accurate. If they’re not accurate, why do them?
Let the managers handle all performance issues internally. If the process needs documentation, then have the manager do so. But, do so privately. Airing the dirty laundry for all to see is ripe for both hostile workplace issues and could document potential legal issues that could arise should the employee leave as a result of a documented performance issue. Note that anything written and placed into the employee file can be come legal fodder should employee legal issues arise. If the evaluation process documents an illegal activity within the company, then your business is at risk. Leading to…
Don’t sanitize employee evaluations after-the-fact
If there is something written on an employee evaluation that puts your business at legal risk, don’t sanitize the evaluation or destroy it after the fact. This will make things far worse for your business. Instead, leave it as it is. If it’s a legal risk, you can defend yourself in court even if it’s in the document. Removing it from the document or removing the entire document is far more problematic legally than leaving it there. Note, if your employee has to write any part of the evaluation, they can make a copy for themselves. If an employee unknowingly describes an illegal business activity on the evaluation, your business is at risk no matter if someone in your organization deletes or sanitizes it. If you are concerned that some illegal activity could appear on an employee evaluation, it may be smarter not to do evaluations. An employee may keep a version of their copy for their records. You can’t easily expunge an employee’s personal records.
Don’t expect much productivity out of your employees during evaluation week
Employee evaluations kill at least a week of productivity time for every employee in the company. Instead of focusing on their job at hand, they are focusing on paperwork that is not related to their job. Expect that evaluations will lose about a week of productivity just for the paperwork portion alone and turn it into non-productive time. If your employees’ work time is important to you, you need to understand that during the evaluation process, far less output than normal will get done. This means you should choose a slow time of the year to perform evaluations. The more you ask of the employee to do on the evaluation forms, the less actual work they get done. Be careful with this process as it can lead to a lot of lost productivity. Note, there will also be a week or two of aftermath from the evaluation process where employees will reflect, brood and be distracted as a result of the outcome of their evaluation with their manager. Without any upside to doing the evaluation, this process simply leaves that bad taste to fester. Which leads to…
Don’t expect sunshine and rainbows
Employee evaluations are by their very nature negative job experiences. Always. Evaluations never give glowing job performance reviews. They are always there to show all of the flaws and weaknesses of the employee and make sure they feel like crap for at least a week or two following completion of the evaluation. This can negatively impact productivity following the completion of the evaluation. You need to understand that this process is by its very nature a negative job experience. It is never a positive experience. The only positive is a merit increase, if it comes. For an employee’s suffering through another performance evaluation, the upside is that employees will hopefully see a higher paycheck. If you decouple merit increase (as stated above), the employee evaluation process becomes a completely negative experience without any upside benefit to the employee. In fact, there is very little if any upside benefit to the company, either. This project then becomes an exercise in futility. If you really want to make your employees feel like crap for several weeks, this is the way to do it.
Think twice before implementing an evaluation system solely because you think it’s necessary. If employees feel that their evaluation is unfair (many will), expect a number of people to walk away from the company. Expect those who stay to underperform for at least a week following any evaluation. Expect some employees to brood and eventually leave months after their review. You will also need to accept some employee departures as a result. Other employees will realize the exercise in futility and seek a job elsewhere. Some may realize the unfairness of the ‘stacking’ and try to find an employer is more fair about this process. Make sure you are well aware of the full ramifications of an evaluation system before you implement it.
Make sure employees get some kind of positive benefit after the evaluation is complete (preferably a merit increase). If you’re planning to make your employees suffer through this negative job experience, then you need to be prepared to offer some sunshine and rainbows to your employees at the end to make the process go down easier. As Mary Poppins once said, “A spoonful of sugar helps the medicine go down” . You need to find that spoonful of sugar… and I don’t mean literally, either (don’t be funny and put a sugar cube on their desks).
Note that the evaluation process should never get in the way of actual work. Yet, it does. It interjects itself between the manager and the employee in a way that can drive a wedge between the employee and the company. A wedge that might otherwise not be there were sleeping dogs left lying, as it were. Employee evaluations can open a Pandora’s box with some individuals, so be careful with this process.
Do think up a better way than the traditional performance review system
If you can come up with a new improved performance system that works better than the old, stale, negative system, then by all means implement it in your company. Such a system would do wonders for making this process much more smooth. Unfortunately, I do not believe such a thing exists. In reality, having monthly one-on-ones between the employee and manager should suffice as an ongoing performance review system. It’s far less negative than the once-a-year evaluation which is mostly pointless. Do away with the once-a-year evaluation system and implement an ongoing manager and employee relationship building system that keeps the employee far more on track than a once-a-year system which really benefits no-one.
Employee evaluations can both help and hurt your company at the same time. Evaluations can open up problems that may not be necessary for an employee to perform their job properly and at the same time, it always ends up as a negative experience for all involved. If you really enjoy running your employees through the ringer once a year, the stale old evaluation process is the way to do it. Worse, though, is that because it’s a once-a-year event, it doesn’t really serve much purpose unless it is tied to a merit increase. If it’s not tied to a merit increase, this is a fruitless exercise. This is part of the reason many companies no longer do one-a-year evaluations.
Basically, do not feel compelled to run evaluations simply because you think you need them. Think twice before implementing these tired vehicles when they don’t really benefit anyone. If you must set up a performance evaluation system, then conduct it once a month between the manager and the employee. Let them discuss active projects, what’s going on today and focus on current performance issues. Having an on-going regular relevant performance evaluation system is much more productive to job performance today and ends up as a much more relaxed and positive experience. Out with the old and in with the new.
Don’t run an evaluation for an employee with 3 or more managers in 6 months
This one is pretty self-explanatory. However, it should be said that if an employee gets a new manager 2 months before the evaluation process is set to begin, the employee has no hope of a fair evaluation. If the employee’s old manager is still part of the organization, then enlist that manager to complete that employee’s evaluation. If the old manager is no longer part of the organization, then skip this employee’s evaluation.
An employee cannot be properly evaluated with a new manager having 2 or less months of service with that employee. Employees under this circumstance should also have the ability to opt-out of the evaluation process entirely. If they can’t get a fair, impartial evaluation for 6 to 12 months of service that year from their current manager, then the employee shouldn’t be obligated to submit an evaluation. I’ll also point out that change in management team is not the employee’s responsibility. Unfairly penalizing an employee’s yearly performance review because of management changes is not the fault of the employee. It’s the fault of your management team.
Unless there has been at least one manager who has managed that employee for a minimum of 6 continuous months of the year, evaluations shouldn’t be performed for that employee.
← Part 3 | Chapter Index | Part 5 →
How not to run a business (Part 3) — SaaS edition
So, we’ve talked about how not to run a general business, let’s get to some specifics. Since software as a service (SaaS) is now becoming more and more common, let’s explore software companies and how not to run these.
Don’t add new features because you can
If a customer is asking for something new, then add that new feature at some appointed future time. Do not, however, think that that feature needs to be implemented tomorrow. On the other hand, if you have conceived something that you think might be useful, do not spend time implementing it until someone is actually asking for it. This is an important lesson to learn. It’s a waste of time to write code that no one will actually use. So, if you think your feature has some merit, invite your existing customers to a discussion by asking them if they would find the proposed feature useful. Your customers have the the final say. If the majority of your customers don’t think they would use it, scrap the idea. Time spent writing a useless feature is time wasted. Once written, the code has to be maintained by someone and is an additional waste of time.
Don’t tie yourself to your existing code
Another lesson to learn is that your code (and app) needs to be both flexible and trashable. Yes, I said trashable. You need to be willing to throw away code and rewrite it if necessary. That means, code flows, changes and morphs. It does not stay static. Ideas change, features change, hardware changes, data changes and customer expectations change. As your product matures and requires more and better infrastructure support, you will find that your older code becomes outdated. Don’t be surprised if you find yourself trashing much of your existing code for completely new implementations taking advantage of newer technologies and frameworks. Code that you may have written from scratch to solve an early business problem may now have a software framework that, while not identical to your code, will do what your code does 100x more efficiently. You have to be willing to dump old code for new implementations and be willing to implement those ideas in place of old code. As an example, usually early code does not take high availability into account. Therefore, gutting old code that isn’t highly available for new frameworks that are is always a benefit to your customers. If there’s anything to understand here, code is not a pet to get attached to. It provides your business with a point in time service set. However, that code set must grow with your customer’s expectations. Yes, this includes total ground-up rewrites.
Don’t write code that focuses solely on user experience
In software-as-a-service companies, many early designs can focus solely on what the code brings to the table for customer experience. The problem is that the design team can become so focused on writing the customer experience that they forget all about the manageability of the code from an operational perspective. Don’t write your code this way. Your company’s ability to support that user experience will suffer greatly from this mistake. Operationally, the code must be manageable, supportable, functional and must also start up, pause and stop consistently. This means, don’t write code so that when it fails it leaves garbage in tables, half-completed transactions with no way to restart the failed transactions or huge temporary files in /tmp. This is sloppy code design at best. At worst, it’s garbage code that needs to be rewritten.
All software designs should plan for both the user experience and the operational functionality. You can’t expect your operations team to become the engineering code janitors. Operations teams are not janitors for cleaning up after sloppy code that leaves garbage everywhere. Which leads to …
Don’t write code that doesn’t clean up after itself
If your code writes temporary tables or otherwise uses temporary mechanisms to complete its processing, clean this up not only on a clean exit, but also during failure conditions. I know of no languages or code that, when written correctly, cannot cleanup after itself even under the most severe software failure conditions. Learn to use these mechanisms to clean up. Better, don’t write code that leaves lots of garbage behind at any point in time. Consume what you need in small blocks and limit the damage under failure conditions.
Additionally, if your code needs to run through processing a series of steps, checkpoint those steps. That means, save the checkpoint somewhere. So, if you fail to process step 3 of 5, another process can come along and continue at step 3 and move forward. Leaving half completed transactions leaves your customers open to user experience problems. Always make sure your code can restart after a failure at the last checkpoint. Remember, user experience isn’t limited to a web interface…
Don’t think that the front end is all there is to user experience
One of the mistakes that a lot of design teams fall into is thinking that the user experience is tied to the way the front end interacts. Unfortunately, this design approach has failure written all over it. Operationally, the back end processing is as much a user experience as the front end interface. Sure, the interface is what the user sees and how the user interacts with your company’s service. At the same time, what the user does on the front end directly drives what happens on the back end. Seeing as your service is likely to be multiuser capable, what each user does needs to have its own separate allocation of resources on the back end to complete their requests. Designing the back end process to serially manage the user requests will lead to backups when you have 100, 1,000 or 10,000 users online.
It’s important to design both the front end experience and the back end processing to support a fully scalable multiuser experience. Most operating systems today are fully capable of multitasking utilizing both multiprocess and multithreaded support. So, take advantage of these features and run your user’s processing requests concurrently, not serially. Even better, make sure they can scale properly.
Don’t write code that sets no limits
One of the most damaging things you can do for user experience is tell your customers there are no limits in your application. As soon as those words are uttered from your lips, someone will be on your system testing that statement. First by seeing how much data it takes before the system breaks, then by stating that you are lying. Bad from all aspects. The takeaway here is that all systems have limits such as disk capacity, disk throughput, network throughput, network latency, the Internet itself is problematic, database limits, process limits, etc. There are limits everywhere in every operating system, every network and every application. You can’t state that your application gives unlimited capabilities without that being a lie. Eventually, your customers will hit a limit and you’ll be standing there scratching your head.
No, it’s far simpler not to make this statement. Set quotas, set limits, set expectations that data sets perform best when they remain between a range. Customers are actually much happier when you give them realistic limits and set their expectations appropriately. Far fetched statements leave your company open to problems. Don’t do this.
Don’t rely on cron to run your business
Ok, so I know some people will say, why not? Cron, while a decent scheduling system, isn’t without its own share of problems. One of its biggest problems, however, is that its smallest level of granularity is once per minute. If you need something to run more frequently than every minute, you are out of luck with cron. Cron also requires hard coded scripts that must be submitted in specific directories for cron to function. Cron doesn’t have an API. Cron supports no external statistics other than by digging through log files. Note, I’m not hating on cron. Cron is a great system administration tool. It has a lot of great things going for it with systems administration use when utilizing relatively infrequent tasks. It’s just not designed to be used under heavy mission critical load. If you’re doing distributed processing, you will need to find a way to launch in a more decentralized way anyway. So, cron likely won’t work in a distributed environment. Cron also has a propensity to stop working internally, but leave itself running in the process list. So, monitoring systems will think it’s working when it’s not actually launching any tasks.
If you’re a Windows shop, don’t rely on Windows scheduler to run your business. Why? Windows scheduler is actually a component of Internet Explorer (IE). When IE changes, the entire system could stop or fail. Considering the frequency with which Microsoft releases updates to not only the operating system, but to IE, you’d be wise to find another scheduler that is not likely to be impacted by Microsoft’s incessant need to modify the operating system.
Find or design a more reliable scheduler that works in a scalable fault tolerant way.
Don’t rely on monitoring systems (or your operations team) to find every problem or find the problem timely
Monitoring systems are designed by humans to find problems and alert. Monitoring systems are by their very nature, reactive. This means that monitoring systems only alert you AFTER they have found a problem. Never before. Worse, most monitoring systems only alert of problems after multiple checks have failed. This means that not only is the service down, it’s been down for probably 15-20 minutes by the time the system alerts. In this time, your customers may or may not have already seen that something is going on.
Additionally, for any monitoring for a given application feature, the monitoring system needs a window into that specific feature. For example, monitoring Windows WMI components or Windows message queues from a Linux monitoring system is near impossible. Linux has no components at all to access, for example, the Windows WMI system or Windows message queues. That said, a third party monitoring system with an agent process on the Windows system may be able to access WMI, but it may not.
Always design your code to provide a window into critical application components and functionality for monitoring purposes. Without such a monitoring window, these applications can be next to impossible to monitor. Better, design using standardized components that work across all platforms instead of relying on platform specific components. Either that or choose a single platform for your business environment and stick with that choice. Note that it is not the responsibility of the operations team to find windows to monitor. It’s the application engineering team’s responsibility to provide the necessary windows into the application to monitor the application.
Don’t expect your operations team to debug your application’s code
Systems administrators are generally not programmers. Yes, they can write shell scripts, but they don’t write code. If your application is written in PHP or C or C++ or Java, don’t expect your operations team to review your application’s code, debug the code or even understand it. Yes, they may be able to review some Java or PHP, but their job is not to write or review your application’s code. Systems administrators are tasked to manage the operating systems and components. That is, to make sure the hardware and operating system is healthy for the application to function and thrive. Systems administrators are therefore not tasked to write or debug your application’s code. Debugging the application is the task for your software engineers. Yes, a systems administrator can find bugs and report them, just as anyone can. Determining why that bug exists is your software engineers’ responsibility. If you expect your systems administrators to understand your application’s code in that level of detail, they are no longer systems administrators and they are considered software engineers. Keeping job roles separate is important in keeping your staff from becoming overloaded with unnecessary tasks.
Don’t write code that is not also documented
This is a plain and simple programming 101 issue. Yes, it’s very simple. Your software engineers’ responsibilities are to write robust code, but also document everything they write. That’s their job responsibility and should be part of their job description. If they do not, cannot or are unwilling to document the code they write, they should be put on a performance review plan and without improvement, walked to the door. Without documentation, reverse engineering their code can take weeks for new personnel. Documentation is critical to your businesses continued success, especially when personnel changes. Think of this like you would disaster recovery. If you suddenly no longer had your current engineers available and you had to hire all new engineers, how quickly could the new engineers understand your application’s code enough to release a new version? This ends up a make or break situation. Documentation is the key here.
Thus, documentation must be part of any engineer’s responsibility when they write code for your company. Code review is equally important by management to ensure that the code not only seems reasonable (i..e, no gotos), but is fully documented and attributed to that person. Yes, the author’s name should be included in comments surrounding each section of code they write and the date the code was written. All languages provide ways to comment within the code, require your staff to use it.
Don’t expect your code to test itself or that your engineers will properly test it
Your software engineers are far too close to the code to determine if the code works correctly under all scenarios. Plain and simple, software doesn’t test itself. Use an independent quality testing group to ensure that the code performs as expected based on the design specifications. Yes, always test based on the design specifications. Clearly, your company should have a road map of features and exactly how those features are expected to perform. These features should be driven by customer requests for new features. Your quality assurance team should have a list of new all features being placed into each new release to write thorough test cases well in advance. So, when the code is ready, they can put the release candidate into the testing environment and run through their test cases. As I said, don’t rely on your software engineers to provide this level of test cases. Use a full quality assurance team to review and sign off on the test cases to ensure that the features work as defined.
Don’t expect code to write (or fix) itself
Here’s another one that would be seemingly self-explanatory. Basically, when a feature comes along that needs to be implemented, don’t expect the code to spring up out of nowhere. You need competent technical people who fully understand the design to write the code for any new feature. But, just because an engineer has actually written code doesn’t mean the code actually implements the feature. Always have test cases ready to ensure that the implemented feature actually performs the way that it was intended.
If the code doesn’t perform what it’s supposed to after having been implemented, obviously it needs to be rewritten so that it does. If the code written doesn’t match the requested feature, the engineer may not understand the requested feature enough to implement it correctly. Alternatively, the feature set wasn’t documented well enough before having been sent to the engineering team to be coded. Always document the features completely, with pseudo-code if necessary, prior to being sent to engineering to write actual code. If using an agile engineering approach, review the progress frequently and test the feature along the way.
Additionally, if the code doesn’t work as expected and is rolled to production broken, don’t expect that code to magically start working or that the production team has some kind of magic wand to fix the problem. If it’s a coding problem, this is a software engineering task to resolve. Regardless of whether or not the production team (or even a customer) manages to find a workaround is irrelevant to actually fixing the bug. If a bug is found and documented, fix it.
Don’t let your software engineers design features
Your software engineers are there to write the code based features derived from customer feedback. Don’t let your software engineers write code for features not on the current road map. This is a waste of time and, at the same time, doesn’t help get your newest release out the door. Make sure that your software engineers remain focused on the current set of features destined for the next release. Focusing on anything other than the next release could delay that release. If you’re wanting to stick to a specific release date, always keep your engineers focused on the features destined for the latest release. Of course, fixing bugs from previous releases is also a priority, so make sure they have enough time to work on these while still working on coding for the newest release. If you have the manpower, focus some people on bug fixing and others on new features. If the code is documented well enough, a separate bug fixing team should have no difficulties creating patches to fix bugs from the current release.
Don’t expect to create 100% perfect code
So, this one almost goes without saying, but it does need to be said. Nothing is ever bug free. This section is here is to illustrate why you need to design your application using a modular patching approach. It goes back to operations manageability (as stated above). Design your application so that code modules can drop-in replace easily while the code is running. This means that the operations team (or whomever is tasked to do your patching) simply drops a new code file in place, tells the system to reload and within minutes the new code is operating. Modular drop in replacements while running is the only way to prevent major downtime (assuming the code is fully tested). As an SaaS company, should always design your application with high availability in mind. Doing full code releases, on the other hand, should have a separate installation process than drop in replacement. Although, if you would like to utilize the dynamic patching process for more agile releases, this is definitely an encouraged design feature. The more easily you design manageability and rapid deployment into your code for the operations team, the less operations people you need to manage and deploy it.
Without the distractions of long involved release processes, the operations team can focus on hardware design, implementation and general growth of the operations processes. The more distractions your operations team has with regards to bugs, fixing bugs, patching bugs and general code related issues, the less time they have to spend on the infrastructure side to make your application perform its best. As well, the operations team also has to keep up with operating system patches, software releases, software updates and security issues that may affect your application or the security of your user’s data.
Don’t overlook security in your design
Many people who write code, write code to implement a feature without thought to security. I’m not necessarily talking about blatantly obvious things like using logins and passwords to get into your system. Although, if you don’t have this, you need to add it. It’s clear, logins are required if you want to have multiple users using your system at once. No, I’m discussing the more subtle but damaging security problems such as cross-site scripting or SQL injection attacks. Always have your site’s code thoroughly tested against a suite of security tools prior to release. Fix any security problems revealed before rolling that code out to production. Don’t wait until the code rolls to production to fix security vulnerabilities. If your quality assurance team isn’t testing for security vulnerabilities as part of the QA sign off process, then you need to rethink and restructure your QA testing methodologies. Otherwise, you may find yourself becoming the next Sony Playstation Store news headline at Yahoo News or CNN. You don’t really want this type of press for your company. You also don’t want your company to be known for losing customer data.
Additionally, you should always store user passwords and other sensitive user data in one-way encrypted form. You can store the last 4 digits or similar of social security numbers or the last 4 of account numbers in clear text, but do not store the whole number in either plain text, with two-way encryption or in a form that is easily derived (md5 hash). Always use actual encryption algorithms with reasonably strong one-way encryption to store sensitive data. If you need access to that data, this will require the user to enter the whole string to unlock whatever it is they are trying to access.
Don’t expect your code to work on terabytes of data
If you’re writing code that manages SQL queries or, more specifically, are constructing SQL queries based on some kind of structured input, don’t expect your query to return timely when run against gigabytes or terabytes of data, thousands of columns or billions of rows or more. Test your code against large data sets. If you don’t have a large data set to test against, you need to find or build some. It’s plain and simple, if you can’t replicate your biggest customers’ environments in your test environment, then you cannot test all edge cases against the code that was written. SQL queries have lots of penalties against large data sets due to explain plans and statistical tables that must be built, if you don’t test your code, you will find that these statistical tables are not at all built the way you expect and the query may take 4,000 seconds instead of 4 seconds to return.
Alternatively, if you’re using very large data sets, it might be worth exploring such technologies as Hadoop and Cassandra instead of traditional relational databases to handle these large data sets in more efficient ways than by using databases like MySQL. Unfortunately, however, Hadoop and Cassandra are noSQL implementations, so you forfeit the use of structured queries to retrieve the data, but very large data sets can be randomly accessed and written to, in many cases, much faster than using SQL ACID database implementations.
Don’t write islands of code
You would think in this day and age that people would understand how frameworks work. Unfortunately, many people don’t and continue to write code that isn’t library or framework based. Let’s get you up to speed on this topic. Instead of writing little disparate islands of code, roll the code up under shared frameworks or shared libraries. This allows other engineers to use and reuse that code in new ways. If it’s a new feature, it’s possible that another bit of unrelated code may need to pull some data from another earlier implemented feature. Frameworks are a great way to ensure that reusing code is possible without reinventing the wheel or copying and pasting code all over the place. Reusable libraries and frameworks are the future. Use them.
Of course, these libraries and frameworks need to be fully documented with specifications of the calls before they can be reused by other engineers in other parts of the code. So, documentation is critical to code reuse. Better, the use of object oriented programming allows not only reuse, but inheritance. So, you can inherit an object in its template form and add your own custom additions to this object to expand its usefulness.
Don’t talk and chew bubble gum at the same time
That is, don’t try to be too grandiose in your plans. Your team has limited time between the start of a development cycle and the roll out of a new release. Make sure that your feature set is compatible with this deadline. Sure, you can throw everything in including the kitchen sink, but don’t expect your engineering team to deliver on time or, if they do actually manage to deliver, that the code will work half as well as you expect. Instead, pair your feature sets down to manageable chunks. Then, group the chunks together into releases throughout the year. Set expectations that you want a certain feature set in a given release. Make sure, however, that that feature set is attainable in the time allotted with the number of engineers that you have on staff. If you have a team of two engineers and a development cycle of one month, don’t expect these engineers to implement hundreds of complex features in that time. Be realistic, but at the same time, know what your engineers are capable of.
Don’t implement features based on one customer’s demand
If someone made a sales promise to deliver a feature to one, and only one customer, you’ve made a serious business mistake. Never promise an individual feature to an individual customer. While you may be able to retain that customer based on implementing that feature, you will run yourself and the rest of your company ragged trying to fulfill this promise. Worse, that customer has no loyalty to you. So, even if you expend the 2-3 weeks day and night coding frenzy to meet the customer’s requirement, the customer will not be any more loyal to you after you have released the code. Sure, it may make the customer briefly happy, but at what expense? You likely won’t keep this customer as a customer any longer. By the time you’ve gotten to this level of desperation with a customer, they are likely already on the way out the door. So, these crunch requests are usually last-ditch efforts at customer retention and customer relations. Worse, the company runs itself ragged trying desperately to roll this new feature almost completely ignoring all other customers needing attention and projects, yet these harried features so completely end up as customized one-offs that no other customer can even use the feature without a major rewrite. So, the code is effectively useless to anyone other than the requesting customer who’s likely within inches of terminating their contract. Don’t do it. If your company gets into this desperation mode, you need to stop and rethink your business strategy and why you are in business.
Don’t forget your customer
You need to hire a high quality sales team who is attentive to customer needs. But, more than this, they need to periodically talk to your existing clients on customer relations terms. Basically, ask the right questions and determine if the customer is happy with the services. I’ve seen so many cases where a customer appears completely happy with the services. In reality, they have either been shopping around or have been approached by competition and wooed away with a better deal. You can’t assume that any customer is so entrenched in your service that they won’t leave. Instead, your sales team needs to take a proactive approach and reach out to the customers periodically to get feedback, determine needs and ask if they have any questions regarding their services. If a contract is within 3 months of renewal, the sales team needs to be on the phone and discussing renewal plans. Don’t wait until a week before the renewal to contact your customers. By a week out, it’s likely that the customers have already been approached by competition and it’s far too late to participate in any vendor review process. You need to know when the vendor review process happens and always submit yourself to that process for continued business consideration from that customer. Just because a customer has a current contract with you does not make you a preferred vendor. More than this, you want to always participate in the vendor review process, so this is why it’s important to contact your customer and ask when the vendor review process begins. Don’t blame the customer that you weren’t included in any vendor review and purchasing process. It’s your sales team’s job to find out when vendor reviews commence.
← Part 2 | Chapter Index | Part 4 →
How not to run a business (Part 2) — General Don’ts 2
As a second article follow-on to the first part of the series How not to run a business (Pt. 1), I will keep the momentum going. So, without further adieu…
Don’t keep non-producers on the payroll longer than 3 months
Three months is enough time to understand if the person you’ve recently hired can do the job for you. If they are not producing within 3 months, they are either in over their head, they simply don’t understand the job or they don’t really want to do the work. Whatever the problem, performance plans to improve probably won’t help. If you’re a small business, you can’t really afford having non-producers on the payroll for long periods of time. However, for longer term employees, that leads into …
Think twice before letting people go without warning
While I know that it’s common to reduce your payroll burden by letting people go, think twice before you do this. More specifically, don’t do it unless you fully understand the consequences of that change to your business. Letting certain people go can cause short-term damage if that person is entrenched in certain aspects of your business. Basically, make sure that your knowledge base is well spread out. This means, making sure that if you have a software engineer who is the only person who understands a crucial bit of code, that this person does a proper hand-off to another person before they depart. I know that it’s common to let people go without warning to them or to anyone else, but this is the worst way to handle letting people go for many reasons. First, you may lose a brain-trust you didn’t know you had or that your company needed. Second, you’re opening your company up to wrongful termination lawsuits. Both of these can be short term damaging to your business. Third, surprise firings don’t always go over well. You don’t know who is capable of temperamental outbursts and who may show up at your doorstep with a firearm ready to take retaliatory measures. Workplace violence is on the rise, be careful whom you let go and how. In the long term, your business will likely recover, but in the short term your customers may feel the pain. It’s entirely up to you to determine if that pain is worth the hassle of walking people to do the door without warning.
The best plan for non-producers is to give them one chance to step up and begin producing. Explain in very explicit terms what you expect to see in the next 30, 60 and 90 days. Set goals and expect improvements. Make it completely clear that this is their only chance to rectify their performance issues or they will be asked to leave. Basically, give the person fair warning in writing, document it, have them sign it, give them a copy and place the original in their personnel file. So, if they choose not to improve their performance issues, you have a documented copy of what you expect and that they failed to meet those expectations. This also means that when you do walk them to the door, this is not a surprise to them. It also gives you the opportunity to hedge your bets and hire someone to be trained by this person. If they refuse to train anyone, explain that it is part of their performance improvement plan and their job. If they choose not to train someone, then explain that they have failed their performance improvement plan and they need to pack their belongings and leave the premises. You can’t make someone do the work, but you can encourage them. If they choose not to work even after you have asked them to, it’s time for them to leave.
Don’t buy email marketing lists and don’t send spam
The quickest way to tank your business on the Internet and give it a bad reputation is by buying lists of people whom you have never met. If your business is important to you, find people who are interested in your services in other ways than by sending spam email. One of the best ways is by using services like D&B to locate companies that might have need of your services. Then, have your sales people cold call them. Note, that while cold calling isn’t always warmly received by many, it is more favorably tolerated than sending email spam. Cold calling is only between you and the called party. Spam, on the other hand, ends up not only between you and the other party, but all parties in between that delivered the email. The recipient may forward the email to other parties which then involve even more people. This is how reputations get ruined. The bottom line is, don’t send email spam and, more specifically, do not buy email lists.
On the other hand, attending trade shows is a great way to initiate interest in your product or service, is a way to collect email addresses and is the primary way to build your email list. Other ways to build your list is by blogging and simply by selling your product on the web.
Don’t acquire companies without fully understanding what they bring to the table
In the start-up phase when there’s lots of capital floating around, it is tempting to bring in what appears to be a good marriage of technologies into your company through acquisition. There are lots of reasons why you should think and rethink any acquiring plan. While you may bring in technologies you don’t otherwise have, it does a lot of other things at the same time. The merging of two companies is a pretty severe culture shock for the company being acquired. Their business methodologies, sales strategies, employment practices, dress code and lots of other subtle culture issues may clash with your current culture. Bringing in a new company can bring with it things your company may not be ready to handle.
Additionally, it well increases the workload for people who may already be overworked. For example, pulling in a whole crew of new staff requires human resources to hire these people in. It requires adding them to payroll and to benefits. It requires IT staff to procure assets like computers, phones, desks, logins, ID cards, etc. The new company will have accounting books that need to be folded into the parent company’s books. There’s all of the duplicated staff that are probably not necessary (finance, IT, operations, marketing… both personnel and management) that will either have to be let go or given alternative positions.
On top of the logistics of simply folding in one company to another, which requires a substantial amount of time and effort from staff, the products themselves also have to be rolled into your current core business that have yet to be determined useful. For example, if your company is primarily a Business to Business seller and you acquire a Business to Consumer company, you need to understand if that marriage works for your present business model. The questions you need to ask yourself… “Am I planning to sell B2C now?” “Can this acquired company’s technology be used in the B2B space?” “Will this new company provide the revenue needed to justify the purchase?” These are all important questions that materially impact whether you should or should not do the deal. Don’t jump into buying a business solely because it appears to be a ‘hot new technology’. The technology itself does not indicate that that product or service is long-term sellable, viable or, more importantly, sellable to your B2B customers and prospects. Yes, having a vision does help here, but remember that Business to Consumer products generally don’t generate near the amount of revenue that Business to Business products do. Also recognize, as in this example, that selling Business to Business is an entirely different beast than selling Business to Consumer. So, this also means learning curves and retraining for those folks tasked to manage both sales models.
Basically, this single section could fill an entire book. There are lots of considerations when contemplating the acquisition of other businesses. Unless you are completely certain that you are gaining something that your company desperately needs, it may be simpler and cheaper to hire people to construct a similar technology without the additional hassles of folding two companies together. In other words, it may take longer and be more costly to fold together both the companies and the technologies than it would have cost to hire engineers and construct a similar technology yourself. Weigh the costs, think about the outcome and determine if acquisition is truly the right choice.
Don’t give away something you can sell
I’ve seen this so many times now that I’ve lost count. Good will is an important aspect of the sales process. It makes the customer feel like the are getting a good deal. I understand this aspect of the sales process. So, discounts, incentives and giveaways are all good methodologies to managing a prospect’s ‘feel good’ aspect of the deal you are proposing. However, remember that you are in business to make money. You’re not in business to give good will gestures, that is unless your company happens to be a charity or non-profit. Assuming that you are a for-profit entity and not managing a charity, you should never give away things you can sell. This is true of not only goods, but services as well. I know it’s easy to think that your professional services team’s or other team’s time is not worth much, but don’t give professional services away for free. Controlling your sales staff, however, is another matter. Don’t allow your sales team to make deals without understanding the deal and someone in management signing off on the deal. Never allow sales persons to make deals without a managerial approval process. When sales people can make deals without approvals, they will make bad deals for your company that you will have to support for years to come.
Worse, giveaways encourage future giveaways. Basically, once you’ve given something to a customer for free, they will expect it for free at subsequent renewals. Don’t set that precedent. Always charge for every line item. Discount it by a small percent, but never discount anything by 100%. Once you agree to any freebie, you are saddled with that freebie for the rest of that customer’s contract with you no matter how much you find out it is really costing you. Believe me, freebies can easily become some of the most costly parts of a business.
Don’t believe everything you hear from prospects or clients
Prospects are good at finagling the best deal possible. One of the most common tactics is to suggest that your direct competitor gave away a service for free that you are selling. They are then expecting you to give them this service for free. So, here’s the common problem with this scenario. First, you are placing 100% trust into what they are saying should you decide to comply. Don’t do this. Check and double check any statements made by prospects when they ask for freebies. Second, when you cannot find that their statement is true, be prepared to take a hard line with them and discount it by only a small percent. Do not give it away for free. If they decline the deal, you may be better off. Don’t do a deal with freebies simply because you need the deal. In the long run, that contract will become unsupportable. Further, any freebie you do agree to will become a permanent never ending freebie. You cannot undo a freebie once done. Take your business seriously and charge for everything. Again, remember that to make money is why you are in business. If you give away any freebies, five years later you will still be giving that freebie to that customer. Don’t believe everything you hear.
Don’t do giveaways, trips and other incentives for the sales team alone
At least, don’t do it without including the rest of the company in the incentives. It’s quite common in many companies for the sales team to be offered trips, giveaways and incentives to close deals (or whomever gets the most deals). So here’s the problem. You’re already paying your sales team commission on deals they’ve closed (and hopefully after the checks have cleared). This is already an incentive. If they close a $1 million deal (or $1 million in deals) and they get 10%, they’ve gotten a $100k check out of that. That’s a lot of money for a sales person in addition to whatever salary you are paying them. Why are you trying to incent them further by flying them to Barbados or by giving them an iPad? It’s their job to keep up the sales. Giving them trips and giveaways sends the wrong message to the rest of your company’s departments who aren’t involved in these incentive programs. It’s also a very exclusionary practice so that most other parts of the company don’t get these incentives. Yet, these other departments work equally hard at their jobs. If you’re planning on offering these types of incentives, involve the entire company, not just your sales team (which, as mentioned, already have incentives in the form of commission).
Don’t plan releases of products or services on company pre-designated holiday weekends
So while this one may not apply to every single business out there, it is a general rule that applies to most businesses. Let’s talk about which businesses to which this doesn’t apply. If you are a consumer product, like an iPad or the latest cell phone, releasing on a holiday weekend is probably a good idea. Unless, however, your product falls into this category (which most businesses do not), do not release your products and services on national holiday weekends. Do it either the weekend before or the weekend after. Why? Nationally respected holiday weekends has nearly everyone out on that holiday. If your service is business to business, for example, no one will be around to review the changes you’re making. So, if your release breaks something crucial to your customers, they won’t know about it until after the holiday. Specifically, it will be too late for them to fix any problems that may have arisen over the weekend. For example, if your release doesn’t work correctly and sends out a bunch of email unintentionally to a list of your customers’ people, this may end up with a lot of angry people on your hands. Your customers won’t find this out until days after the incident occurred.
Out of common courtesy for your customer’s holidays (let alone asking your staff to hang around on a holiday weekend to release), delay releases to weekends that are not holiday weekends. Asking people to give up a holiday weekend (whether customers or employees) is most definitely not good for morale. Additionally, if you do ask employees to give up their holiday weekend, then expect to make up for that weekend through comp time on another weekend later.
By expecting people to give up a holiday weekend without any payback, you are setting your company up for huge morale issues, staff will come to disrespect you and your decisions and the company will become known for these unnecessary practices in the industry. It also means that employees will see that your company doesn’t respect their home family lives. What you do with your employees does get around the industry and can easily make it a challenge when it comes time to hire new qualified staff. Basically, word of mouth gets around quickly and people simply will not look at your company when looking for employment. Small things like these make a huge difference to your staff, especially to prospective employees and recruiters. These are also the types of actions that prevent your company from being placed on lists like Forbes top 100 places to work. Your company must respect the home and family lives of your employees. Forcing people to work company designated holiday weekends is like handing the employees a cookie and then unceremoniously yanking it back moments before they can grab it and quipping, “just kidding”. Don’t do this. Respect your employees more than this.
Don’t use the company to pay your personal bills
Being the CEO, CFO or any other C-level exec doesn’t entitle you to use the company as your own personal bank account. While there is nothing but your own personal moral compass stopping you (and adamant finance employees) from using the company in this way, eventually this information will leak out to the rest of the company. Some things just can’t be kept a secret, especially the longer your business runs and the more personnel changes that happen. So, unless you want your employees to know that you’re paying $6k a month for your house or $3k a month in car payments or $2k a month in child care costs, pay your home expenses from your own personal checking account. Don’t use the accounts payable people to pay your personal bills for you. Note, to those entrepreneurs who don’t understand computers, technology or the internet, yes, there are banks now that have automatic bill pay that you can set up online.
← Part 1 | Chapter Index | Part 3 →
How not to run a business (Part 1) — Don’ts
While there are tons of articles out there describing exactly what you need to do to start and operate a business, here are tips on what not to do when operating your business. I come from a background of years working in IT and, thus, this article is born from that perspective. Please view the index page to view all parts in this series.
Don’t treat your customers as burdens
So many businesses see only dollar signs next to a customer’s account. They’re more than dollars, they are your livelihood. Without them, you don’t have a business. Always treat your customers with respect and never as a burden. With that said, some people are difficult to manage in their mannerisms, manners, speech or phone etiquette. These types of people can be difficult. If you know that you cannot work with a given customer or client based on their behaviors, you may have to let them go as a customer. There is nothing that says you have to continue to do business with everyone that comes to you for services. If the client cannot show your business and your staff the same level of courtesy, respect and professionalism that you show them, then they don’t deserve to use your products or services.
On the other hand, your staff should always remain professional, courteous and friendly at all times. Word gets around quickly when your people are rude, improper or treat customers disrespectfully. Don’t do it and make sure your employees don’t.
Don’t burn your employees out
It’s very easy to lose sight of what your employees are doing day to day. If all you are seeing is the work being done, but you aren’t understanding how that work is getting done or by whom, you need to stop and smell the roses. In other words, find out what they are doing. Don’t assume that you have enough employees simply because the work is getting done. What you may not see is that your employees could be working after hours and on weekends to get the work done that couldn’t be done on shift. This is both unfair to your employees and causes burnout. Eventually, the employee will leave and you’ll be forced to hire and train someone new.
You’ll also find that after hiring someone new, the work output dramatically drops because the new person won’t carry the same work load as the person who left. Don’t blame the new hire, don’t chastise them and don’t expect the same level of work. You’ll only end up with a revolving door. If your ex-employee was doing the work of two, you need to find that out and hire the appropriate amount of staff to cover the expected workload. You should never expect the same level of work output from a new hire, especially if the person who left was using their own time to finish the work.
Treating your employees fairly and understanding their workload is how you get better productivity. Cracking the whip and expecting immediate results only pushes other work aside for your fire drill. As more and more fire drills result, the less and less other work gets done. This then means the employee is backlogged with some work that will never get done. If getting all work done is important, make sure that you understand the ramifications of a fire drill before you start it.
Additionally, you may have spent a fair amount of time recruiting the talent to your business. If you’ve got talented employees doing a bang-up job, but they are way over worked, they’re eventually going to leave. You don’t want to have to replace that brain trust. It’s expensive, time consuming and can leave your business vulnerable until you find someone and get them trained. It’s cheaper to keep your existing talent by treating them right the first time out. Keeping track of and managing your employees’ burn level goes a long way towards employee retention.
Do not categorize every customer issue as a fire drill
This goes back to the point above. Every customer issue isn’t a fire drill. Be professional, be courteous, but most of all, be realistic with your customers. Don’t promise immediate results when it’s not possible. Doing so throws employees into fire drill mode and other work gets pushed aside. Fire drills result in much lost productivity. Learn to triage and manage these customer situations appropriately.
Don’t expect professional results from fire drill mode
When employees go into ‘fire drill’ mode, all productivity stops. That is, all productivity stops for each employee consumed by the fire drill. The only thing that a fire drill employee is focused on is in fixing what caused the fire drill whether or not they have the tools to do so. Worse, as employees jump into fire drill mode, they also enter the get-it-done-as-fast-as-possible mode. This mode is problematic on many levels. It can leave the issue only partially resolved or temporarily resolved. This means that someone will have to go back later and fix the problem properly and permanently.
Moving too fast can cause mistakes or lead to even bigger problems later. Moving too fast can bypass rational and critical thinking. Moving too fast can halt logic thought processes and prevent people from seeing the bigger picture. These are all important aspects to realize of fire drills. For example, is the problem just for a single customer or is it impacting all customers? Is the problem something that the product or service caused, is it caused by the customer interaction or is it something introduced by a third party vendor? Getting thrown into fire drill mode keeps some of these thought processes from materializing and, instead, employees tend to put blinders on instead of rationally thinking through the entire issue from top to bottom.
Fire drills burn people out rapidly. Eventually, employees get fed up with the fire drill mode and they leave the company. Don’t expect to keep employees for longer than a year or two if your entire business runs on fire drills daily. Note, successful businesses do not operate in fire drill mode all of the time. Yes, fire drills happen, but not all of the time. Treating every issue as a fire drill leads employees to feel unproductive and eventually they burn out and leave.
Don’t expect perfection from employees
We are all human and we are all fallible. Running a business, you have to expect occasional mishaps. That’s not to say that you can’t strive for your employees to reduce mistakes. But, it does mean that you need to set your expectations accordingly to avoid thinking that perfection is the way the company should run.
On the flip side, do treat your employees with proper and necessary fringe benefits. For your business to be considered on Forbes top 100 best places to work, you need to offer a whole lot of perks to your employees. Perks can be costly, but happy employees keep the productivity flowing. Unhappy and dissatisfied employees do the minimum and go home. Employees that are happy to work for your company will turn in a lot more carefully completed work than employees who are dissatisfied or are getting burned out.
Don’t play games with your website
If you intend to do business on the Internet (and who doesn’t at this point?), your web site is the new storefront. It shows off your business and how it works. It is the single most important portal for both your customers and prospects. Without a solid well designed web site, don’t expect high quality traffic or even the right traffic. This means, let professional design firms design your site tuned to the correct keywords. Don’t build the web site yourself from scratch (unless you happen to also be a well known web designer). Let professionals do this work and provide your site with a fresh look. Additionally, trust your web designer. Don’t think you know better than your web designers (unless you happen to have a degree in commercial art). Yes, flaws in the way something works on the site, these need to be corrected. For the look and feel, trust that they know what they are doing. If you are uncertain of a certain image, flow or feature on your web site, do an A/B test (your idea vs the designers’s idea) to find out which one your visitors like better. Visitors always speak loader than you. Treat your visitors with the respect they deserve. Don’t assume that because it’s how you want it that it’s the correct move. Note that that goes for everything in your business, not just websites.
Additionally, once you establish a web site with reasonbly high ranking in Google, don’t up and change it just because ‘it’s old’. Don’t do this unless you are absolutely certain you know what you are doing. If you roll the site out incorrectly, you can easily lose all page rankings you have in Google. If your intent is to target new keywords, then maybe that’s what you want. But, if you had a page 1 or page 2 ranking, by changing key words and content incorrectly, you can expect to drop down to the 20-50 page area (or lower). This is immediately damaging to any business. Note, page rankings move down far faster than move up. So, you’ll pretty much lose your rankings overnight, but your new keywords might take a year or longer to get even close to page 4. You’ve lost a lot of ground and you’ve lost a lot of visitors because your new site is now ranked very low. You can always pay for AdWords to help your business, but pay-per-click is very costly and may not help your page rankings in any substantial way.
Don’t use content management systems for your web site
I know, I know. A lot of people are using WordPress for their home pages. This is way overkill for a home site. Why? First, your content doesn’t change that often on your home site. It’s mostly static. WordPress and other content management systems are designed for adding new content often and rapidly (just like this very blog article you are reading). Corporate web sites don’t change frequently enough to justify all that’s necessary to run a CMS (i.e., Linux, Apache, MySQL and PHP for starters). On top of that, WordPress requires you to build the graphics inside of a specially designed theme which requires specialized coding knowledge. Additionally, for Linux, Apache, MySQL and PHP, someone will also need to understand all of these technologies for when things break and when redundancy is required. This means hiring someone knowledgeable to manage the CMS site, not to mention someone who’s knowledgable with WordPress management.
Second, there’s page delivery speed. For each additional technology layer you add, there’s a performance hit to deliver that page to the browser. The slower the page load, the lower the Google page ranking. Statically designed web sites are the fastest to load. Why? No databases to pull data from, no PHP to interpret and process commands, no extra layers of networks to pull data through, etc. The pages and content are immediately there to download rapidly. Ultimately, a CMS is simply delivering an HTML page to the browser. So does a static web site. The less layers involved, the faster a page can deliver. The faster the delivery, the higher the page ranking. Of course, you can also throw super fast hardware and caching mechanisms in front of your CMS to help speed up delivery, but that can cause other issues for some types of content and, at the same time, cost you more money. The only downside to static web sites is management and deployment. However, tools like Dreamweaver can solve some of these deployment issues. It’s also far easier to hire someone knowledgeable about HTML and Apache alone than it is to find someone who additionally understands PHP and MySQL databases and permissions, let alone WordPress.
Don’t send mixed messages to your customers and prospects
The worst thing you can do is have a muddy browsing and sales experience. Customers want to know what things cost and what they will get in return for that money they spend with you. If you don’t have a clear and concise list of your products or services, then define them before ever allowing a salesperson on the phone. Mixed messages are the quickest way to lose prospects before getting to stage one in the sales process. Clearly define what you offer before getting any prospect on the phone. Additionally, mixed messages can come from different sales people also. For example, based on commission rates, one sales person might offer once price while another offers another. Keep your sales people consistent on pricing. If a prospect calls and is given pricing, make sure that pricing is documented in a quote somewhere. If the prospect calls back, even a different representative who answers the phone can find the pricing they were given.
Don’t overhire
This is a huge problem in Startups. Startup companies tend to overhire in places like sales and under hire in critical technical positions needed to support those sales properly. So, you might have 50 sales people all closing deals, but you have one or two operations people to enable and train those 50 (or more) new customers each month. This goes back to, don’t burn your employees out. Lopsided hiring is a phenomena that upper management rarely sees or chooses to ignore, but continues to be a problem in nearly every startup I’ve seen.
Don’t pay out commissions before receiving customer payment
We all know that closing a deal is great. However, the trap that many startups fall into is paying out commissions on the close of the deal rather than after the customer’s check has cleared. This is a problem for so many reasons. First, it allows your sales staff to game your commission system by finding any deal to close and closing it even if it never has hope of actual payment. This means they will always get their commission, but new the customer never actually makes any payment. Second, you’ve paid out commission to the salesperson, but you’ve never collected a dime from the customer. Don’t do this. Always pay out commissions only after the customer’s check has cleared the bank and only based on the length of the term only after the payment is received. If it’s a 12 month deal paid monthly, pay the employee commissions after receipt of payment by the customer and only pay the sales person on what the customer has paid. If it’s a 10% commission, they will get their 10% of that monthly check after the check has arrived and cleared. Never pay any commissions before the check clears. Never pay out the full commission payment on the deal until all customer monies on that contract have been collected.
Paying commissions in this way does several things at once. It forces the salesperson to make sure the payment is properly received, it forces the salesperson to accurately document the contract to get the correct payment amount from the customer, it prevents paying out commissions without receiving payment by the customer first (which means you aren’t dipping into cash reserves to make payroll), it reduces the amount of work necessary by your receivables person, it prevents claw backs through salary reduction of future pay checks from sales persons if deals fall through after-the-fact, and it just plain makes good business sense. Running your sales department’s commission program based solely on when deal closes is just ripe for major cash flow problems.
You know, you’d think this specific Don’t would be a no-brainer in the business world. In fact, it isn’t and I don’t know why that is. I’ve worked for multiple startups that have chosen this money-burning commission approach. I know, some people have said, “Other startups do it this way”. This is a non-argument and offers no justification for this stupid practice. This rationalization also doesn’t make it sane for your business or the bottom line. It just means the insanity runs deep in other companies. Because another business chooses a high cash burn approach to their sales operations doesn’t mean you need to follow that same cash burn approach. Instead, save that money and invest it places that bring money in rather than lose it. Your sales people don’t need to become millionaires off of bad commission practices. Sure, you can use claw backs to get the money back, but only if the sales person is still working for you. It doesn’t work if the employee has quit and left with money in hand.
Don’t let your sales people promise things that cannot be delivered
Your sales people are primarily working for their commissions. That’s why they are sales people. Once you acknowledge this fact, you can do the things to protect your business from dire sales mistakes. Basically, your sales people are looking for 10% of that million dollar deal. They are not concerned whether your product or service actually is capable of doing what they have sold. Overselling is one of the biggest problems that any organization faces, especially growing startups that have little experience. It takes work, training and proper management to keep this problem in check. Don’t turn a blind eye to this part of your business. Yes, your sales people do bring in the business, but they need to bring in the business based on what is currently offered, not what can be built. This goes back to fire drills. If your sales people are constantly selling vapor products, your business will always be in fire drill mode trying to build something a sales person has promised. Don’t get into this mode or you’ll never get out of it.
When a sales person sells something that doesn’t exist, their commissions should be eliminated for that sale. This immediately deters sales persons from selling non-existent features (even if it’s part of a larger deal). If even part of the product doesn’t exist, neither does their commission on that sale. Commissions are like rewards. Don’t reward your sales people for promising things that are not possible and then rushing to try and fulfill that promise by building something really fast ‘to cover the promise’. This is a bad bad business practice to fall into.
Don’t play games with the books
With Sarbanes-Oxley in play, it’s rather difficult to do… especially in public companies. However, in private companies, all bets are off. If you (or any of your staff) play games with the books, you may never be able to recover from this if you intend to IPO. The quickest way to tank your company is by playing games with the books. It’s pretty simple, hire an accountant, a CPA or someone who’s honest and is willing to do the right thing. At the same time, keep close tabs on your books (payments in, out and general ledger). If you are a C-level exec, don’t use the company coffers as your own personal bank account. While this is extremely tempting, unless you intend for the company to close its doors at some point, don’t do this.
Don’t hop around trying to find the next big idea
It’s great to explore new things, but don’t abandon your tried and true services thinking you have the next big thing. If you have something that’s selling well, keep it in play. Don’t get rid of it simply because you think you have a new idea that is better. Make sure you market test all new ideas before you dump services in replacement for that new idea. You may have dumped your bread and butter for an idea that doesn’t work. Your customers will tell you that really quick.
Don’t rely on self-service business models to sustain a large corporation
Self-service is an adjunct to your business and is not intended to be used to sustain the business itself. If you plan to be in business and sell business-to-business services, don’t expect self-service pay-by-credit-card services to win over large corporations. First, most corporations don’t (and can’t) pay by credit cards and, instead, they prefer net 30, 45, 60 or 90 day terms. Credit cards are almost always intended for small transactions, usually under $1000. Although, some consumer cards allow charges up to $3-4k. Some business cards can go even higher. Yes, some cards like the government P-cards have high limits, but most cards don’t. For the most part, though, credit cards are intended primarily for small transactions. If you are looking for $30k-$1mil contracts, cards are not really the place for this size of transaction. You will need salespeople, you need to extend credit and set up payment terms and you need to hire a finance team to send invoices and collect and book payments.
Second, big corporations expect some level of spoon feeding with regards to the sales and support processes. Expect to assign salespeople to corporations as single points of contact. Corporations expect to talk to the same salesperson each and every time they call. If your sales people change constantly, be sure to do proper turnover and have your new sales people contact those corporations explaining the transition. If you prefer not to assign salespeople to accounts, you may do more harm than good for your business, so don’t do this. Corporations want to feel like their accounts are being handled properly. For the amount of money that a corporation is spending on their contract to your business, this is the least you can do to secure their peace of mind. This goes back to treating businesses and people with respect and courtesy.
Don’t think email invoices alone suffice as for notification of outstanding debt
Email invoices, while convenient, are not always admissible in court. Always send a paper bill for second notices to pay. Yes, this means printing and mailing paper invoices, but that’s just one cost of doing business. Expect to incur this cost.
Don’t think your employees know how to act
Write an employee handbook. Not only is this book a great reference for how to act, how to dress, how to conduct business and simple business etiquette information, it is also a good place to set expectations so when you do have to let someone go, you have a document that states unacceptable conduct. You can also state things such as ‘at will’ terms so that employees know exactly where they stand with their employment with you. Employee handbooks are good places to keep all kinds of information not otherwise easily documented. Sure, you can use a Wiki or other digital media (PDF) for this information, but printing this document to paper and placing it on every employee’s desk with a page to ‘read and sign’ means that at least they cracked open the book enough to read and sign the signature page. Digital documents are not always enough for this. This is a way to protect your business from employee issues when you need to let someone go for inappropriate behavior or when performance issues are at work.
Don’t become fascist about the use of electronic devices
Employees carry iPhones, iPads and portable electronic devices. They’re going to carry them whether you like it or not. It’s a way of life today. You’re not going to change that behavior by mandating a no-cellphone policy in the office. People rely on cell phones for critical personal communications. Don’t expect that you can take away cell phone privileges from them and they’ll be happy working for you. This goes back to perks. Let that be a perk for your employees. You can mandate in the employee handbook (discussed just above) about over usage of devices. Basically, let employees exercise common sense on usage (for example, on breaks, at lunch time, etc). But, if it consumes their day and they’re not productive, that’s a problem that needs to be discussed and addressed.
Some employees also like to listen to music while working, so allowing this is also a perk. If an employee is more productive while listening to music, let them listen. If it allows them to tune out other office noises such as other phone conversations, ringing phones, typing, printer noises and other distracting office sounds, all the better. Of course, if the person happens to be the receptionist, use of headphones may not be an option. Note that anything that calms an employee, let’s them remain happy at work and helps them to concentrate is never a bad thing.
Don’t expect people to give up their weekends for your business
This goes back to burning employees out. If you have so much work that one person cannot get the job done or it requires weekend work to get things done, expect to offer extra salary or comp time. Comp time costs you nothing additional. It’s a straight trade. One weekend day for one weekday off. Don’t expect your employees to work 6-7 days on a 5 day a week salary. Eventually, you may find yourself in a lawsuit for backpay. Don’t do it.
Don’t expect technology to solve every problem
Technology is made by humans. It is, therefore, fallible. It has bugs, it crashes, it doesn’t always work as expected. It doesn’t matter if the software is from your developers or from Apple. Nothing is perfect, expect that it will become a problem at some point. This goes back to fire drills above. Take failure in stride and work through it. Don’t pressure your employees for 5 minute fixes when things go wrong. Let the employees work through the issue properly. The question is, do you want it done right or do you want it done fast? Fast may get you a fix, but it may not be a fix that you’ll ultimately like several days later. Giving enough breathing room to let the technical employees work through a proper fix is critical to ensure proper resolution to problems. Expecting fast fixes only leads to more problems later. This even goes for writing code. Pressing to get software releases out the door ‘fast’, especially if you are a software company, is the only real way to tank your business. If you’re a software business, your brand is built on quality, not quantity. You want your software to work as expected. Rushing to get software out the door, more often than not, leads to failure somewhere along the way for someone. It means your developers have missed critical edge cases that can make the difference between being known for mediocre software and being known for high quality software.
If you think that there’s a way to write speedy software that’s high quality, you’ve deluded yourself. Quality software comes only from producing code that covers 98-99% of every edge case out there and that simply takes time to produce. Basically, this requires bulletproofing the software so that no matter how a user may use the software that it always does what’s expected. Increasing speed of software delivery reduces the ability to test edge cases leaving dangling code that doesn’t always do the correct thing under error conditions. This means the code could run wild, do the wrong thing or, worst case, corrupt data irrevocably. This situation puts technical staff in fire drill mode. Again, you cannot run your business in constant fire drill mode. You hired your technical staff to write high quality code, let them. Yes, by all means set delivery dates, but if a feature is too complex for a release, pull it and release it later. Don’t rush them to get that feature into any specific release.
Don’t let the sales team drive your business
Your sales department is your front end the public. It’s how you sell and do business. But, it is not what drives your business ahead. Your products and services drive your business. The solutions that you create are what become the face of what your business is and does. As an entrepreneur, you may have forgotten that the reason you went into business is to solve a problem. You wrote a piece of software or designed a product to solve a business problem, perhaps even for yourself. Then, you realized you could sell that solution to many different people. It’s the solution that drives the business, not your sales team. Basically, your technical team’s ability to deliver a functioning solution is what matters. The sales team is irrelevant in this equation other than the fact that they answer the phone, make the sale and take payment. Far too many businesses rely on the sales department to drive their business forward. This is the wrong approach and uses wrong thinking. Sure, the sales team is the one reaching out to prospects and locating interested new parties. That’s the sales team’s job. But, when sales begins selling a square peg to fit a round hole that’s where problems begin. This goes back to overselling. The solution is what sells, not the sales team. The sales team is the mouthpiece for the solution, not the other way around. So, the sales team must be trained to sell what is there, not what isn’t. It is not the sales team’s job to make up new features or imply that a feature a customer may be looking for exists. It’s the sales team’s job to understand the solution offered and find prospects where that solution fits their problem.
In this goal, always have a technical person who knows the limits of the solution on every sales call. They are the voice of clarity to keep the sales team from overselling. The technical person can step in and say, “That’s not exactly correct, our product doesn’t do X yet”. This sets customer expectations. However, if X feature is important, it should be added to the list of new features to be added into a future release.
Your business and you
As the owner and/or CEO of your business, you are the champion of your business. Only you can do the right thing for your business. Stop, think and use common sense. Rushing employees to get things done fast is not the answer. Slow down the pace. Let the employees catch up and catch their breath. Let them finish critical projects. If you’re consistently compressing time lines, some tasks will never get done. Compressed time lines are usually driven by customers and this, in turn, is usually driven by a salesperson over promising. These are all practices that must be tempered. Setting the correct pace for your business is the only way your business will succeed. Too fast a pace and your business will never be known for quality. Too slow and the competition will outdo you. Critical, of course, to your business is having creative thinkers on your team. You need a constant flow of new ideas to keep the business fresh and keep your products and services new and innovative. Without critical thinkers producing new fresh ideas, your business will keep wrapping pretty new bows on old ideas. Keep your old ideas the way they are. Don’t wrap pretty new bows into them. Your customers will appreciate that you respect them. Wrapping pretty new bows on old ideas can be insulting to old customers if you’re trying to play it off as a new service. This is the quickest way to lose customers. Keep your existing customers happy and don’t insult them by playing off something old as something new.
Start | Chapter Index | Part 2 →
Patent Trolls or why software patents should be abolished!
The patent system was originally designed to provide exclusive rights for invented ideas to inventors. But, there used to be a catch, the idea must lead to a real world tangible device. The patent system was also conceived long before computers existed. So, at the time when the patent system was conceived, it was designed as a way for inventors to retain exclusive control over their ideas for tangible devices without other people stealing or profiting from those ideas.
The patent system is enforced by the legal system. It is sanctioned by governments (specifically in the US, by the US Patent Office – USPTO and the legislative system) to protect said individuals’ patents from use by others who serve to profit from those previously ‘patented’ ideas. So, enforcing a patent involves suing an alleged infringer and then having a court of law rule whether the alleged infringer has, in fact, infringed. It is, then, the burden of proof of the patent holder to prove infringement. And, of course, it ties up the legal system to resolve this dispute.
Tangible vs Intangible Devices
The patent system was conceived at a time when the ultimate outcome of a patent idea was to produce a tangible physical good. That is, something that ultimately exists in the real world like a pen, a toaster, a drill, a telephone or a light bulb. The patented idea itself is not tangible, but the idea described within the patent should ultimately produce a tangible real world item if actually built. This is why ideas that lead to intangible things were never allowed to be patented and are only allowed to be copyrighted or trademarked.
Fast forward to when the first computers came into existence (30s-60s). Then later, the 70s when the US Patent Office began granting software patents en masse (although, the first software patent was apparently granted in 1966). Software, unfortunately, is not a tangible thing and, for the most part, is simply a set of ideas expressed through a ‘programming language’ with finite constructs. Modern programming languages, specifically, are designed to have limited constructs to produce a structured code. That is, an application that follows a specific set of pre-built rules to basically take data in and present data out (in specific unique ways). Ultimately, that’s what a program does, take data in, process it and spit data out in a new way.
Software Design Limits
Because modern programming languages have limited constructs from which to build an application and which are further constrained by such limits as application programming interface (API) frameworks, operating system function calls, hardware limitations and other such constraints, writing an application becomes an exercise in compromise. That is, you must compromise programming flexibility for the ease and speed of using someone else’s API framework. Of course, you can write anything you want from scratch if you really want, but most people choose to use pre-existing frameworks to speed the development process. Using external frameworks also reduce time to completion of a project. At the same time, including third party API systems is not without its share of coding and legal issues. Programmatically speaking, using a third party API opens up your code to security problems and puts implicit trust into that API that it’s ‘doing the right thing’. Clearly, the functionality derived from the external framework may outweigh the security dangers present within the framework. From a legal perspective, you also don’t know what legal traps your application may fall into as a result of using someone else’s API framework. If they used code within the framework that is legally questionable, that will also bring your application into question because you used that framework inside your app (unless, of course, it’s using a SOAP/REST internet framework).
With all that said, embedding frameworks in your app severely constricts your ability to control what your program is doing. Worse, though, if you are using a high level programming language like C, C++, Objective C, C# or any other high level language, you are limited by that programming language’s built-in construct. So, even if you choose to code everything from scratch, it’s very likely you could write code substantially similar to something that someone else has already written. Because high level languages have limited constructs, there are only so many ways to build an application that, for example, extracts data from a database. So, you have to follow the same conventions as everyone else to accomplish this same task.
Software Patents are bad
Because of these limited high level language constructs, there is a high probability that someone writing an application will write code that has already been written hundreds of times before. And note, that’s not an accident. That happens because do()while, for() and while() loops as well as if conditionals area always used in the same way. Worse, you can’t deviate from these language constructs because they are always the same in pretty much any language. If these constructs didn’t exist, you couldn’t easily make decisions within your code (ie, if X is greater than 3, do this, else do that).
Why are software patents bad? Simply, because languages are written with such limited programming concepts, the probability to reinvent something that has already been invented is far too high. Unlike devising a real world idea where the probability someone could come up with that same exact idea is likely near zero, writing software using language constructs the probability is far higher than 70% that someone could design the same (or substantially similar) code, idea or construct. And. that high probability is strictly because of the limits and constructs imposed by the high level language.
Yet, the USPTO has decided to allow and grant software patents knowing the probabilities of creating substantially similar ideas within the software world is that high. Yes, probabilities should play a part in whether or not to grant patents.
Probabilities
Probability in idea creation is (and should always be considered) how likely someone is to create something substantially similar to someone else. Probability should always be relevant in granting patents. Patents need to be unique and individual. That is, a patent should be granted based on something that multiple people could not devise, guess, build or otherwise conceive accidentally. Because real world tangible items are constrained only by the elements here on Earth, this effectively makes inventions using Earth elements pretty much infinite (at least for all intents and purposes). Because software code uses a much smaller number of constructs that limit and constrain programming efforts, that smaller set increases the chances and the probabilities that someone can create something similar. In fact, it increases probabilities by orders of magnitudes. I’m sure an expert on statistics and probabilities could even come up with real world probability numbers between element based inventions and software code based inventions. Suffice it to say, even without this analysis, it’s quite clear that it’s far too easy for someone to devise something substantially similar in software without even really trying.
Software patents are bad, revisited
Basically, it’s far too easy for someone to devise something someone else has already conceived using software. On top of this, the USPTO has seen fit to grant software patents that are way too obvious anyway. That is, they’ve granted patents to software ideas that are similarly as common place as cotton, strawberries, a nail and yarn. Worse, because of these completely obvious patents, patent trolls (people who do nothing but patent without the intent of producing anything) game the system and produce completely obvious patents. This action has created a land mine situation for the software industry. This is especially bad because it’s virtually impossible to search for existing patents before writing software.
So, as a software developer, you never know when you might step on one of these land mines and get a ‘cease and desist’ notification from a patent troll. That is, someone who has patented some tiny little thing that’s completely obvious, yet your application takes advantage of that thing somewhere because you just happened upon one of the easy to build constructs in a language. Yet, patents should only be granted based on an idea that someone cannot easily create by sheer accident. Yet, here we are.
Ideas now patented
Worse, software is not and has never been tangible. That is, software doesn’t and cannot exist in the real world. Yes, software exists on real world devices, but that software itself is just a series of bits in a storage device. It is not real and will never be real or ever see the light of day. That is, software is just an idea. An idea with a structured format. It is not real and will never have a real tangible physical shape, like a toaster. We will never be able to have tactile interaction with software. Hardware, yes, is tactile. Software, no. The software’s running code itself cannot stimulate any of our five senses: not sight, hearing, touch, smell and taste.. Someone might argue, well software does produce visual and audible interaction. Yes, the output of the software produces these interactions. That is, the software processes the input data and produces output data. The input and output data has sight and sound interaction. You still aren’t seeing or hearing the software code doing the processing. That’s under the hood and cannot be experienced by our five senses. For this reason, software is strictly an idea, a construct. It is not a tangible good.
Patents are a form of personal law
That is, the owner of the patent now has a legal ‘law’ that they need to personally enforce. That is, that patent number gives them the right to take anyone to court to enforce their ‘law’ err.. patent. No entity in government should be allowed to grant personal law. Especially not for intangible things. I can understand granting patents on tangible items (a specialty hair clip, a curling iron, a new type of pen, etc). That makes sense and it’s easy to see infringement as you can see and touch the fake. It takes effort, time and money to produce such a tangible item. Software patents require nothing. Just an application to the USPTO, a payment and then wait for it to be granted. After the patent has been granted, take people to court, win and wait for royalties. This is wrong.
All software patents should be immediately abolished and invalidated
Why?
- Software patents only serve corporations in money making ventures. Yet, software patents really serve to bog down the legal system with unnecessary actions.
- Software patents stifle innovation due to ‘land mines’. Many would-be developers steer clear of writing any code for fear of the legal traps.
- Software patents are granted based on probabilities far too high that someone will produce something similar based on limited high level language constructs
- Because software language constructs are, by comparison, much smaller in number when compared to Earth elements (when inventing real world ideas), probabilities say it’s too easy to recreate something substantially similar to someone else in software.
- Software is intangible and cannot expose itself as anything tangible (which goes against the original idea of patents in the first place)
- Software patents will reach critical mass. Eventually, the only people left writing code will be large corporations who can afford to defend against legal traps.
- Software patents are now being granted without regards to obviousness.
As a result, all software patents, past and present, should be immediately invalidated. If we continue this path of software patents, a critical mass will eventually exist such that writing software will become such a legal landmine that developers will simply stop developing. I believe we’ve already seen the beginnings of this. Eventually, the only people left who can afford to develop software will be large corporations with deep pockets. Effectively, software patents will stifle innovation to the point that small developers will no longer be able to legally defend against the Patent Trolls and large corporations seeking to make money off ‘licensing’. The patent system needs to go back to a time when the only patents granted were patents describing tangible physical goods. Patents that do not describe tangible physical goods should be considered ideas and dumped under copyright law only.
Contacting Amazon.com support — where is that number?
Phone numbers have been updated for easy dialing. Click or tap to dial.
More and more, companies are hiding their support phone numbers behind layers and layers of web pages. They simply don’t want you to call in. They seem to think that their automated systems are so bulletproof that there is no need ever to talk to a human being. Well, Amazon has taken this to the extreme. Amazon is now so hands off, even their Amazon Web Services site has no sales phone number. As if the automated signup and sales process is so fool-proof that you won’t fall into any kind of trap… what a joke!
So, the question begs, how the heck are you supposed to ask questions about their services or about charges on your cards? Clearly, a company can’t do business like this long term. Customer Service is everything and hiding your support people behind layers of web pages is so completely counter to sales and support, I don’t understand how these companies even stay in business.
What are consumers to do except get more and more frustrated? Instead of getting frustrated, this article is here to expose these hard-to-find phone numbers for all to see and use.
Amazon’s Customer Service line:
- 1-866-216-1072 (they can transfer you to other departments, just ask)
- or 1-888-280-4331
- or 1-888-280-3321 (3321 may be discontinued in 2018)
- International customers: 1-206-266-2992. Charges may apply.
- For AWS subscribers, call the above number(s) and politely ask to be transferred to the AWS support team since there is no direct number for AWS.
- Keep in mind that you will need a paid phone support contract with AWS to talk to a representative. Without a contract, they may not talk to you.
- 1-866-540-3229 — Note, they require one-time use pin codes or press # if you don’t have it. It will likely expedite your call to set pincode up from the link. You’ll need to login to do this.
- 1-888-221-1161 — Note, need to login and set up one time-use pin code, but you may be able to skip this step when calling without one. It will probably expedite your call if you set one up.
Rakuten.com:
- 1-888-BEST-BUY (1-888-237-8289)
Frys.com:
- 1-800-856-9800
- International: 1-408-350-1484
- Sales/Customer Service Fax: 1-408-487-4700
- Email: service@cs.frys.com
Netflix.com:
- 1-866-716-0414 — Note, faster if you use the express code from your account
Redbox.com:
- 1-866-REDBOX3 (1-866-733-2693)
Hulu.com:
- 1-877-485-8411 (For Hulu Plus Subscribers)
Virgin Mobile:
- No Contract Plans / General: 1-888-322-1122
- Broadband2Go: 1-877-877-8443
- Assurance Wireless: 1-888-321-5880
Wells Fargo:
- Online Banking: 1-800-956-4442
Airlines:
- Delta
- Reservations: 1-800-221-1212
- App Support: 1-888-750-3284
- International Reservations: 1-800-241-4141
- Skymiles: 1-800-323-2323
- Disability Assistance: 1-404-209-3434
- 711 for hearing or speech assistance
- Frontier
- Reservations and Support: 1-801-401-9000
I’ll add more as I find them. Of course, if you find any new numbers that need to be here, feel free to comment. If any of these stop working, please comment as well.
Enjoy!
Voice ads during your cell phone calls?
Just when you thought that advertisers couldn’t get any more annoying, along comes yet another technology that, on the surface, seems quite intrusive and may even become a privacy issue. This time, it’s on your cell phone.
Paying to hear ads?
It’s not as if cell phone plans and cell plan minutes are cheap. The average cost per minute is around 10 cents. Some postpaid plans may be able to get the cost down to around 7-8 cents per minute, but that’s only for high dollar high volume plans. The average small to mid-sized plan is usually around 10 cents per minute after taxes, fees and other charges have been tallied. With prepaid, the cost is 10 cents per minute. I’ve yet to find one carrier that has less than 10 cents per minute prepaid plans.
That said, because you’re paying for your service, you are also implicitly paying to not have advertising on your phone during your conversations with other people. Advertisers need to learn that when consumers are paying for something, advertising on that space is off-limits. If the advertisers want to help subsidize our costs for something, then we will be willing to tolerate external advertising. It’s a give and take process here. So, advertisers (and those enabling this new technology) need to understand this part of the equation.
What exactly is this technology?
Good question. It doesn’t have a cleverly coined name yet, so let’s call it ‘jam’ (as in they’re jamming up the airwaves with advertising in your cell phone call.. and it also rhymes with spam :). This new technology plans to use the carriers to interject audio advertising into the cell phone’s audio stream during a call. Specifically, during hold music and other ‘dead air’ times.
There’s really only one place in the call flow where such advertising can be injected with new audio and that’s on the carrier’s equipment. It’s also possible that it could happen right on the handset through an actively running app. Either way, ‘jam’ isn’t what people want.
Advertising during dead air? Why would we want that?
Well, the answer is as consumers, we don’t. So, why enable this technology? Because someone can. That and that someone thinks they can make money from this service as well. Good luck with that business model. Anyway, the idea is relatively simple, but definitely not pleasant. Worse, though, is that the advertiser may even have your personal buying habits and interject ‘relevant’ advertising into your call. Not that relevant advertising is bad, but it’s rather creepy when it’s injected into audio conversations of a cell phone. So, you’re on hold waiting for someone to fix your computer and then injected audio steps in and advertises for that vacation to Hawaii you searched on the web just an hour before you called. Ugh, creepy.
Worse, though, is what happens if their dead air recognizing routine fails and it begins injecting advertising in the middle of your conversation? Ewww… now not only will you hear the ad, but likely so will your caller. If you happen to be on a business call… well, all I can say is ewww.. messy and embarrassing.
Opt-out
For such a technology to have any hope of working to even any degree, there must be an opt-out mechanism. If there isn’t such an opt-out system, users will be calling their carriers to complain, that’s a guarantee… especially if such an advertisement interrupts a business call.
Jam on businesses
The primary target for this advertising system is during hold time. I admit that hold music is often boring and repetitive. But, does that give the right to an unrelated third party to inject jam into your phone for their benefit? And, what of the business on the other end providing hold music? They may have advertising that they are counting on to up-sell their newest products. Yet, if jam interrupts and begins selling ‘relevant’ advertising in the form of a competitor, how is fair to the company you’re calling? This system has now injected competitive advertisements without that company’s consent. I see this as a lawsuit just waiting to happen.
Carrier and phone level access
Frankly, I’m surprised that the wireless carriers would even allow this level of access into their network. Unless, of course, these companies can figure out a way of doing it directly into the handset. Either way, it will require very low level access to either the handset or the carrier network to inject this level of audio into a conversation. The trouble, of course, is what happens when their system goes haywire and injects audio at inappropriate times? And, you know this will happen. This isn’t going to make either caller very happy, especially if this happens during a business call or a conference call. I just see failure written all over this.
Don’t rent at Blockbuster Express Kiosks
[Updated: 04/15/2017 — In 2012, Redbox purchased all of the remaining Blockbuster Express kiosks which have now become Redbox kiosks. The original article follows.]
I’ve rented at both Redbox and now Blockbuster. I’ve never had any difficulties renting or returning at Redbox. However, at Blockbuster I had the worst experience when returning my movie. Note, this was the first time I’d ever used Blockbuster’s machine. Note, Blockbuster’s machine sucks.
Poor Vending Machine Design
I’ll start by saying that DVD rentals via vending machine, not the best idea. Yes, that includes Redbox. The issue isn’t renting, it’s returning. If you rent at a store, returning the DVD is actually simple… drop it off in the bin. At a vending kiosk, you’re have to wait to turn in the movie because you have to use the screen to initiate the return function. This means, you have to stand in line and wait until everyone else is done. Stupid.
These machines are monstrous, yet they can’t even provide a proper return mechanism. My experience with Blockbuster returning a rented DVD was horrible. I stood in line 20 minutes waiting to return my movie (singular). After all that, the time was a couple minutes past 9 and Blockbuster still charged the extra $1 fee. Seriously, there is no grace period at all?
The worst part is, however, that when I called customer service, they refused to refund the money. They offered a promo code instead. Hello, no, I want a refund, not a promo code. After the debacle that is the returns process, I don’t intend to rent from their shoddy vending machine ever again. I’d already made that decision right after they charged me the extra day’s fee. This is why I didn’t want a promo code. The bad customer service experience was just the topper that capped it all.
Return Mechanism
These hulking machines are huge. There should be no reason why there isn’t a simple return and go slot (i.e., no waiting). It’s completely ludicrous that you need to wait for someone else to finish their long transaction before you can return a movie. It seriously needs a drop and go slot. A slot that always accepts returns no matter what someone may be doing on the rental side. Their computer already knows that that specific movie copy is tied to my account. There is no reason to have to initiate anything. An always-active returns slot is a no-brainer. Yet, these kiosks don’t have one. Neither does Redbox. However, there are far more Redbox kiosks around. If one is that occupied, I could just drive to another. Unfortunately, with the Blockbuster kiosks, you had to return your discs to the one where you rented. You couldn’t return at just any kiosk even if you did know where another one was.
In this case, the kiosk should shutdown all new purchases for 20 minutes prior to 9PM to allow for express returns. This would put the system into return only mode and allow those only needing to return to push their way through before the 9PM deadline. This prevents those people who want to spend 15-20 minutes hogging the kiosk reading every movie synopsis and hemming and hawing over ever title in the unit from doing immediately before return time.
Blockbuster go boom
It’s no wonder Blockbuster’s kiosks are now a thing of the past. They really had no idea of customer service or how to operate such a rental service to the public. I’ll stick with Redbox, thank you very much. I’ve had no issues with customer service or returns at Redbox. Yet, on my very first call to Blockbuster customer service (I waited on hold for at least 10 minutes), they were unwilling to even do what I requested (refund the extra day fee that they don’t rightly deserve).
So, I called the bank and the bank reversed the charges. Too bad Blockbuster.
Here’s your word of warning. If you want to rent from Blockbuster’s kiosk, you may experience something very similar with returns. Not only is customer service an atrocious process, they won’t even issue refunds when appropriate. Worse, if you go even 1 minute past 9PM when returning, they will stick you for that extra day’s fee (no grace period). I have no respect for Blockbuster and I do not intend to rent anything further from either their stupid kiosk or any store they own.
While these rentals are cheap enough, it’s not worth the hassle when you want to get a refund for ill gotten charges. Believe me, Blockbuster needs to shutter the doors and go away. Let’s hope Redbox makes that happen (and they did) and oh, Blockbuster, you should really take a look at Redbox to see what customer service really is, m’kay?
[03/15/2017 Comment: This article was written before the Blockbuster kiosks were bought out by Redbox in 2012. Thankfully, these Blockbuster kiosks no longer exist. They have all been replaced by Redbox kiosks which are much more abundant and easy to locate and use… thanks to the Redbox app. I leave this article up as a history of how Blockbuster kiosks functioned and as a testament to how bad Blockbuster’s customer service was at the time.]
Business and Politics don’t mix
As Target and Best Buy have so aptly found out, donating large sums of money to political candidates can backfire. I know why companies wish to donate. They want to be able to call in the candidate on local reform when necessary. The issue, though, is that while this may be the goal, the candidate may not stand for what your customers do… especially if you are a retailer. Retailers must sell to the public. The public are the people who support the retailers. However, when these same businesses choose to contribute to (aka endorse) candidates who may have agendas that a vocal part of your buying public opposes, then your company can get into hot water. And yes, Target and Best Buy have found this out the hard way.
Target And Best Buy
Both of these companies contributed over $100,000 that ended up supporting advertising for a local Minnesota gubernatorial candidate who opposes gay marriage and who advocates violence towards gays. While that wasn’t the crux of that candidate’s platform, it was a the part of it that caught the wrong attention from these donations. This set off a firestorm of negative publicity for both of these companies. Gay activists are now calling for boycotts of these stores.
This is cause and effect. This is why companies have no business contributing funds that go to specific candidates. In fact, companies have no business in politics. Yes, I know they want to have hip-pocket legislation, but at the same time, these companies also need to understand the direct relationship of any direct candidate donation to the bottom line. It’s very likely that Target and Best Buy have spent more than their donations in managing this publicity nightmare. This issue also proves that if a company feels the need to donate to politics, they need to do it directly to each local democratic or republican top level coffer. That way, the money is spread out among the candidates rather than going to a single candidate. Even still, politics is a sticky wicket and any contribution may backfire.
Oil and Water
Business and Politics don’t mix and this situation is the prime example of why. If companies want to contribute to political causes, they must understand the negative outcome of those decisions and weigh it carefully against the cost of a PR fallout. Worse, it could alienate customers whom you depend on for your bottom line. Being in business is already difficult enough without making such huge mistakes.
If company executives feel they must have hip-pocket legislation at their fingertips, then they need to find other ways to do it… like, for example, lobby groups. Send these groups to Washington like everyone else and get legislation made in a more generic way.. not by endorsing specific local candidates where their political agenda might conflict with the buying public.
Could be any cause involved..
Note that any donation could have gone to support some other problematic issue. So, any direct political candidate donation is not a good idea for any company.
So, how does Target and Best Buy deal with this issue? Well, clearly it’ll be difficult to get that money back. It’ll also be difficult for them to weather this storm. The best idea is to, obviously, issue a sincere apology regarding the donation. State that they didn’t understand the candidate’s platform and state that they won’t do this again. But, the deed is already done. Of course, a statement that they won’t do it again is probably a lie. It’s only a matter of time before they donate to some other cause that may get them into hot water again.
Companies like this never learn and are destined to make the same mistakes. As a consumer, you need to make your choices about whether you want the money you spend at those companies to go to supporting those causes. Just something to think about.
Random Thoughts - Randocity! 
1 comment