Ruminations on Self Employment and Running a Business

I’ve been self-employed as a contractor and consultant for 20 years. Being self-employed has both its positive and negative aspects. Being your own boss and being able to set your own hours is a positive; worrying about where the next contract is going to come from is a negative. Being able to pick assignments that interest you is a positive; having to take grunt work because nothing else is available at the moment is a big negative. In spite of the negatives I suspect I would have a hard time going back to being someone else’s employee.

What follows are some of the things I’ve learned about being self-employed, in no particular order of importance, and at the end I’ll mention one big thing I haven’t yet figured out. Fair warning: I am neither an attorney (solicitor) nor an accountant, and nothing here should be construed to be legal or accounting advice. It is important that you consult both of these types of professionals when setting up your own business.

Give a little away

I am a strong believer in ‘giving a little away’. In my experience, every time I have ‘given a little away’, I have gotten back more in the long run.

A couple of examples should help illustrate the concept.

I had a customer for whom I provided all software support on one of their plant computer systems. (This system was just replaced, after 32 years of service.) Their systems engineering department has an area called the bullpen, which has white boards on two walls, and a large table with seating for the whole group. It was the practice at the time to gather together to eat lunch in the bullpen every day. Some work got discussed, but mostly it was a social hour.

During one trip to the site there was quite a bit of information on the larger white board regarding a problem they were having with another of the plant computer systems. From the drawings on the board it appeared the problem had to do with serial communications, but if so there were several problems with their understanding of how asynchronous serial communications work. Over the next several days, during lunch, I started asking questions and discussing the problem with the two engineers responsible for the system. By the end of that two week trip I had ‘given away’ my lunch hour almost every day.

The result of my ‘giving a little away’ over the course of several lunch hours was four months of additional, paid work, on a system I had never worked on before. In the winter of 2012 we installed an upgrade to the software which fixed several major and a lot of minor software problems, which improved the mean-time-to-failure of the system by an order of magnitude.

Another example: In the early- to mid-1980s I worked for a company that built industrial control systems based around ModComp mini-computers. These systems had a proprietary, home-grown database sub-system, and historical transaction data that was stored using that database. The systems had a report generator that allowed for selecting and sorting records for reports, but it was slow and not very extendable. (Full disclosure: I wrote that report generator in 1982, and it was still in use at one plant up until November 2013, when the last system of its type was replaced.)

During a trip to one of the sites in the early 2000s, one of the system owners expressed an interest in the possibility of moving the transaction data to a Microsoft Access-based database, so that he could manipulate the data more easily, much faster, and at his desk. I decided to see if I could provide a product that would export the data from the Modcomps and import it to Access.

I don’t have a Modcomp sitting around my office (that would be so cool). They require a lot of space – imagine a small closet (wardrobe) – and have power requirements that would result in my late 1960s house burning down when the aluminum wiring decided to sizzle. My wife puts up with a lot when it comes to the space my business requires, but being homeless was just not part of the deal.

Fortunately, I was able to strike a deal with the systems engineering supervisor at one of the other plants that still had a Modcomp system. He allowed me to use the development computer in their lab to develop the software that migrated the historical transaction data from the proprietary database to a Microsoft SQL server database. In return, I provided support for their systems when needed.

The little bit I gave away in the form of infrequent support for their systems gave me access to the resources I needed to develop a product. I was eventually able to sell three copies of the resulting software, one of which was to the plant which allowed me to use their system to develop it.

Don’t promise to do what you don’t know you can do

The large company for which I worked built in-plant and SCADA industrial control computer systems for public utilities. The systems were defined by a specification document developed by an architectural engineering firm. At that time those documents could easily be four or more inches thick, full of finely wrought details.

The contracts for these systems were awarded at the end of a bidding process. A company’s bid was supposed to include a list of exceptions to the specification, to let the customer know what they weren’t going to get. My company had a standard system that we would customize to meet the specification as closely as possible, but in general it wasn’t possible to meet every jot and tittle of a specification.

I happened to overhear an assistant ask a bid manager for the exception list for a bid they were developing. He answered that there were no exceptions. The bid manager’s response set in motion several long-term issues.

First, once the contract was awarded, the bid manager no longer had responsibility for the project. He was making promises he didn’t have to keep – it would be the project team’s responsibility to execute the project. Second, it set the project up for schedule and financial failure, since the time and cost of implementing all of the features that should have been excepted were never accounted for in the bid. (We used to joke that we lost money on every job but made up for it in volume.) Third, it reinforced the idea of ‘win the contract now and fight it out in court later’, which was all too prevalent in the company (and the industry in general) at that time.

I swore I would never run my business this way. As a small business I can’t afford the money it would take to defend myself if something like this got to court, nor the hit my reputation would take.

A quick word about what I call ‘science projects’. It is OK to take on work you don’t know you can do, as long as you are up front and honest about it. In the first example in ‘give a little away’ above, I didn’t know if I was going to be able to fix that customer’s problems. I was going to be working on software I had never seen before, running on hardware with which I was unfamiliar, and could offer no guarantees of success. I made sure to emphasize these issues before taking on the work, so the customer knew what the possible outcomes of the work were.

A working prototype can sell itself

If I don’t know that I can do something, I go off and try to do it. On my time. At my expense. That program I described earlier that exported data from a proprietary database to an SQL database is just such an example. When I started that project I didn’t know Visual Studio .NET (which I used for the PC-side software and the GUI); I didn’t know SQL server (the PC-side data store); I didn’t know if it was going to be practical to move the data over a 19.2K baud serial communications channel – the fastest I had available. (One large 9-track magnetic tape took 8 to 12 hours to convert and transmit.) But once I had it working it was an easy sell.

I had another customer who complained that a critical hardware subsystem was obsolete, breaking down frequently, and impossible to fix. They had asked another company for help. That vendor had sent them a sample of their replacement product, but my customer couldn’t get it to work. The vendor wasn’t very helpful, and my customer was getting frustrated.

I had just purchased a development kit for (what was at that time) a new microprocessor called the Rabbit 2000. I sketched up some circuit diagrams, and proceeded to develop a very ugly, hand soldered and wire-wrapped prototype for a replacement product that would work for my customer. I wrote the firmware, debugged the hardware, and when I was done called him up and said I had a working prototype, and would he have some time for me to visit the site and try it out? He did, I did, the prototype worked, and I eventually sold 150 production-quality units – the largest single project I had up to that point.

The customer is not always right

It is trendy to say that in business the customer is always right. I’ve found in this business the customer is often wrong. The tricky part is knowing what to do about it, and when.

Years ago, when I was working for the large corporation, I paid a visit to a customer site in order to perform an operating system upgrade. This was a non-trivial activity, which required a simultaneous hardware upgrade, since major operating system versions required specific hardware revision levels to function properly.

The customer had procured the operating system upgrade and upgraded boards from the computer vendor. I was brought in to load the operating system and rebuild the application software (which was required because the run-time libraries were upgraded with the OS).

The customer wanted to make a major, system-wide change to one of the global linker options at the same time as the other work was done. Having experienced the joys of upgrading this particular computer system before, I refused. We were already making two large changes to the system – one more than I usually like to make, but necessary – and adding a third large change was just asking for trouble. It’s hard enough to track down problems caused by one change. I believe my exact words were “You may be able to find someone in the office who is willing to do it your way, but it won’t be me.”

We ended up doing it my way, but not without a fight. I backed out the change to the linker options (the customer had already made that change to the build script), and we did the OS and hardware upgrade. I then researched the linker option change, and discovered that other architectural aspects of the system precluded what the customer wanted to do. Had we lumped all three changes together the system would have crashed, and we wouldn’t have had a clear idea of where the error was located.

Here’s another example; same customer, same system. The engineer discovered that in one of the peripheral cabinets we had routed a control signal through both sides of a double pole, double throw relay. (The outgoing signal went through one pole; the return through the other.) He wanted to rewire the cabinet because using both sides of the relay would decrease the mean-time-to-failure of the relay. Doing what he wanted would have meant incurring a huge cost to change the wiring, plus the cost of changing the drawings, and at the time it cost them $1000.00 USD just to have a draftsman change the date on a drawing – all to protect against a supposed increase in the likelihood of the failure of a five dollar relay whose mean-time-to-failure was already much longer than the expected life of the system. An expletive was involved on my part (I was much younger then). Not very professional, and I regret my reaction to this day, but I got the point across. The system as delivered was in use for 15 years (more than twice its designed lifetime). Even if they had to replace that relay once a year, the total cost of repair was a fraction of what the redesign and rework would have cost (without even including the time value of money).

I don’t recommend profanity, but I do believe that it is better to withdraw from a project or a task than to take part in something which you believe to be misguided, unethical, or illegal.

Pay attention to finances

It always amazes me when I hear about a small business owner who doesn’t have any idea of the financial health of his or her company. Yes, I know we don’t go into business to do the accounting (unless you’re an accountant!), but it’s important – you have to do it. It may not be practical or affordable to hire someone else to do it for you, and even if you can afford it, you need to have some understanding of the system and the numbers.

Rule Number One: Everyone gets paid before you. Everyone. Particularly taxing authorities. The last thing you need is to get crossways with a government tax agency, at any level. I file three monthly tax forms, three quarterly tax forms, and multiple end-of-year tax forms. Most of them have money due with them. File the reports and pay the tax due, on time. It’s the best way to stay out of trouble.

Rule Number Two: Keep great records. Not just good, but great. We write software for a living, which requires an attention to detail required of few others (some – my wife – might call it anal retentiveness). Use that attention to detail to organize your records to a fare-thee-well. Have a place for everything, and file everything in its place. Keep all of the records and receipts required by your tax authorities, plus some. You are less likely to get in trouble for keeping more records than required.

Several years ago my company was audited by the state taxation division. A discrepancy was flagged between the income stated on our end-of-year tax returns and the income on which the company had paid gross receipts tax (similar to a VAT). The discrepancy was due to the fact that almost all of my business comes from out of state, which is not subject to the state GRT.

Audit day came, and if I could have been plucked like a string I would have rung a high C. I had pulled three years of company sales records, invoices, and check stubs. I had copies of all my contracts and purchase orders. I had all of my personal tax returns. I had an official letter from my attorney documenting the section of state law that exempted the out-of-state work from GRT. Everything was laid out on my dining room table (I work from home), in folders, labeled, in chronological order.

The audit I had dreaded took 45 minutes. The auditors told me they wished all of their audits were that easy. They put a letter in my file explaining the nature of my business so the next time I got flagged it would be available to that auditor. I haven’t heard from them since.

Understand the concept of risk

The two most common contractual ways a contractor or consultant is hired are time and materials (T&M) and fixed cost. In a T&M contract you get paid by the hour, and are reimbursed for expenses and any materials you purchase to fulfill the contract. In a fixed cost contract you say you will do the work for a set amount of money, in a set amount of time, and you are responsible for paying for all of your expenses and materials. Your contract may also be a hybrid of these two approaches.

This is where the concept of risk comes in. In a T&M contract, most if not all of the risk is on your customer. They may specify a limit to how much they are willing to spend (a ‘not to exceed’ clause), but in the end if the work takes more time and money than originally estimated it is their problem. In a fixed cost contract all of the risk is on you. You have to deliver a defined scope of work, in a fixed amount of time, and it doesn’t matter to your customer how much it costs you to do the work.

If you are going to take on a fixed cost contract, be very sure you can do the scope of work, in the amount of time specified, and at or below the costs you estimate. (Don’t promise to do something you don’t know you can do.) I prefer T&M contracts, but have taken fixed cost contracts when the work is something I have done before. I also add risk to the quote, by increasing my hourly rate and over-estimating time and expenses. It is very important that the scope of work and time constraints be very well defined before signing the contract. Also keep in mind that you are on the hook for warranty work on fixed cost contracts, so you should figure extra money in for that, as well.

My T&M contracts usually invoice once a month. On fixed cost contracts I try to negotiate a payment schedule that includes small start-up payment (particularly if I have to buy hardware), regular payments based on partial deliverables, and large payment on delivery. I also usually let my customer keep five or ten percent of the total cost as a retention payment, payable upon completion of some sort of integration test. This shows that you are committed to sticking with the project to completion.

Several years ago I quoted a fixed cost contract for an interface to hardware that was new to my customer. Since the hardware was new to me, too, I wrote into my proposal that the quote was contingent on getting assurances from the hardware vendor that we would have their full support. When I learned that the hardware vendor wasn’t going to provide any support, I was able to convert the contract to T&M, moving the risk from me to my customer. It turned out that because we had to work out the details of the protocol without help, the work took 35% longer than I had estimated (and my estimate had been very conservative to begin with).

On a related note – beware the ‘budgetary estimate’ trap. An estimate tends to become ‘the price’. If you are asked for an estimate, always estimate high. You can always decrease the price, but it is very difficult to increase it once the estimate is out there.

Invest in your skills and your tools

As a reader of this magazine (and perhaps a participant in the yearly conference), you already appreciate the benefits of keeping your skills current. Your skill set is what you are selling to your customers. It pays to keep up to date. In addition to the ACCU, I belong to the IEEE, the Computer Society, and the ACM, and try to work my way through the magazines that come with the memberships. I attend one professional conference every year, and hope to bump that number up to two next year. (ACCU Bristol 2015, here I come!)

Good tools are also important. Since I design circuit boards as well as write software, over the years I’ve bought a quality soldering iron and de-soldering station; a digital oscilloscope; and an inexpensive logic analyzer. (I have a better tool set than some of my customers.) There are at least six PCs in my office, of varying vintage, including two that I purchased to support work for just one client. Being willing to spend money on tools to support a customer is an easy way to show your commitment to their project.

What about software? There is a lot of free software out there, and I use some of it, but most of my customers are Windows shops, so I have an MSDN subscription. I also have three subscriptions for PC-Lint – one for each of my main development computers – and two licenses for Windows Office tools (desktop and laptop). I also have a license for backup software. (Don’t forget to do backups! And make sure you can actually recover backed up files.) Accounting software and end-of-year tax software round out the list.

Other ‘tools’ you may need, that may not be obvious, and may not be directly tied to your work: a desk, chair, filing cabinets (to store those excellent records), printers, internet access, phone line and/or mobile phone, and a dedicated FAX line.

I mention all of this because this stuff costs money and has to be budgeted from your income. Remember, everyone else gets paid first.

Insurance

As much as we may hate to admit it, we all make mistakes, and some mistakes are more costly than others. Insurance is a way to mitigate the risks associated with mistakes, and to protect you and your family from the costs of those mistakes.

My contracts typically require three types of insurance: errors and omissions (E&O), general liability, and automobile. E&O insurance is professional liability insurance, which pays off in the event of a professional mistake. General liability insurance covers non-professional liability (such as injury to another person). Automobile insurance covers accidents you may have while on a customer’s property.

I work in the nuclear power industry, which makes it very difficult for me to find an insurance carrier, and makes the policies I can get more expensive than they otherwise might be. (A colleague pays one third of what I do because he didn’t disclose that he works in the nuclear industry.) I could save a lot of money by not declaring my nuclear work, but that would likely result in my policy being invalidated the first time it is needed. Be honest about the industries in which you work. Insurance is about mitigating risks, so it makes no sense to risk the insurance.

Sometimes it is just business

It’s hard to not take things personally when you’re in business for yourself. Being told your services are no longer required, when you have done nothing to deserve getting fired, can be a blow to the ego. It is also hard to not get a contract or a job after spending time and money trying to earn it. It is important to recognize that businesses make decisions based on business requirements. It may not be personal to them – it shouldn’t be personal to you.

It can help to be able to separate a person’s corporate persona from their private persona. I have worked with several people who were great individuals, but terrible bosses. At work they were holy terrors; get them away from work and they were good friends, gracious hosts, and delightful to be around.

On the other hand, if you did something that deserved firing, you should take the time to reflect on what you did and why it led to the outcome it did.

Be scrupulously honest and ethical

As an individual, your reputation is one of your two most important attributes (the other being your technical competence). A good reputation opens doors to other work. Customers may recommend you to their peers, and give you good references when asked. A bad reputation can easily put you out of business, and once acquired can be devilishly difficult to turn around. The best way to earn and keep a good reputation is to run your business as honestly and ethically as possible.

Ethics is about how we act when no one else is looking. It is not that difficult to run your business in an ethical manner. Do the right thing. Act as a faithful agent for your customers [ NSPE ]. Generate accurate invoices. Pay your vendors and your taxes on time. Follow the law. Tell the truth.

Want more information on ethics? Look to the codes of conducts and ethics provided by our professional organizations for guidance. The BCS has its Code of Conduct [ BCS ], as does the IEEE [ IEEE ] and ACM [ ACM ]. If you are licensed by the BCS (in the U.K.) or one of the state boards of engineers (in the U.S.) these codes may have the force of law. (My professional engineering license requires that I take at least one hour of ethics training a year, and yes, it is unethical – and illegal – to not get the ethics training and say you did.)

Admit to your mistakes

We call them bugs, but they are really mistakes. When you make one, be willing and able to say “I made a mistake”. I know I hate saying those four words, and the best way to keep from having to admit to a mistake is to work very hard to not make one, but none of us is perfect. (Fran – I made a mistake committing to this deadline. See, that wasn’t too hard.)

Growing the business

At the beginning of this article I mentioned there is one aspect of being a business owner that I have never been able to figure out. (There are more than one, but this is the big one.) I remain a one-man shop, mostly because I’ve never been able to solve the chicken-and-egg problem. I can’t afford to hire someone unless I have paying work for them to do, and I can’t take on more work than I can handle because of the risk of not being able to find someone to do that work.

It seems that real entrepreneurs (read ‘risk-takers’) don’t spend a lot of time worrying about those types of issues. I do. It goes back to not taking on work that I know (or at least reasonably expect) I can’t do. If you have a solution to this problem, I’d like to discuss it with you.

Afterword

I didn’t set out to be an entrepreneur – I just fell into it. My wife wanted to move closer to home, which was out of state, which meant I had to leave my job of 13 years at the large company.

At about the same time, the large company sold off the division for which I had worked. My adventure in self-employment began with a phone call from a long-time colleague at one of the newly created companies. “We have a couple of weeks of startup work at a water treatment plant in Modesto, California, starting next Monday. Are you interested?” “Sure,” I replied, “I’ve got nothing else to do.” And off I went.

Before those two weeks were up I got another phone call. “We’ve got two weeks of startup work at a water treatment plant in Norfolk, Virginia, next week. Are you available?” (For those of you keeping score, those cities are on opposite coasts.) “Sure”, I replied, “I’ve got nothing else to do.” And I’ve had nothing else to do ever since.

Acknowledgments

Thanks to Fran and the reviewers for their making this a better article.

References

[ACM] Association for Computing Machinery, Code of Ethics http://www.acm.org/about/code-of-ethics

[BCS] BCS, The Chartered Institute for IT, Code of Conduct http://www.bcs.org/category/6030

[IEEE] Institute of Electrical and Electronics Engineers, Code of Conduct http://www.ieee.org/about/ieee_code_of_conduct.pdf

[NSPE] National Society of Professional Engineers, Code of Ethics http://www.nspe.org/resources/ethics/code-ethics