Catálogo de publicaciones - libros

On my weblog I tend to link to this posting quite often. This short blog entry defines the primary audience for my weblog and for this book: someone with a technical background who is involved in the management of a small ISV. I usually refer to this kind of a person as a geek founder. As you’ll see, my definition of a small ISV is somewhat narrow. If you’re running a software company that doesn’t perfectly fit my definition (like a contracting shop or a VC-funded company trying to “get big fast”), keep your eyes open for stuff that doesn’t fit your situation.

This article was the very first entry I wrote for my column on the MSDN Web site. Well, to be completely honest, that’s not quite true. Because I was such a geek, this article is actually the second entry I wrote. The first one was thrown away. In the summer of 2003, Chris Sells (then a content strategist for MSDN) asked if I would like to write a column about the business of software. He said each article should be “of length 2K–4K.” Even though I was accustomed to writing articles quite a bit longer than that, I agreed. I wrote the first draft of the first entry for my column. As expected, it was too long. After a day or two of wordsmithing, I finally got the length under the limit of 4,096 bytes. An hour after I submitted the article, Chris sent an e-mail complaining that my column was too short. Only then did I realize that when he said my articles should be “of length 2K–4K,” he was speaking of words, not bytes! So I started over, and this 2,031-word article is the result. By the way, I should preface this piece with a confession: I was frustrated when I wrote this. I was angry about the way our industry is today. So I wrote a sermon, encouraging the world to stop whining and be positive about the many real opportunities available in our industry. But the truth is I was mostly preaching to myself.

As this book goes to press, I am 37 years old and consider myself fortunate to be in a job that fits me really well, but I have to admit I got here somewhat by accident. I was restless for most of my final year as an employee at Spyglass. On January 7th, 1997, I resigned and decided to go into business for myself. However, I never really planned to build a real company or to sell shrink-wrap products. I just wanted to be self-employed. The company people now know as SourceGear kind of grew up around me, sometimes without my involvement and occasionally without my consent. But fortunately, it turns out that my strengths and weaknesses make me a pretty good software entrepreneur. I like my job, but it is definitely not for everyone. A major goal of this article is to help developers answer the question “Should I be a software entrepreneur or not?”

This chapter is boring, and I am not apologizing for it. If you are going to run a software company, you have to know the basics of accounting and finance. If you are not willing to do that, it is not likely that your company will be successful. On the other hand, if you find these topics to be genuinely interesting, it is even less likely that your company will be successful.

This is the article where I coined the term Micro-ISV, which I define as a software product company with just one person. Some people use this term to describe a company of three or four, but I think I will remain pedantic on this point. (I do offer a special exemption for a company of two where the other person is a significant other. Anyway, the term Micro-ISV has since gained somewhat of a following. Apparently the notion of a single-person software product resonates well with a lot of developers, and people seem to like the way Micro-ISV sounds. The funny thing is that I originally wrote this article with a completely different term. I don’t remember what my original terminology was, but I do remember that I changed it at the last minute, just before I submitted this to my editors at MSDN.

I created Winnable Solitaire primarily so that I could write the Micro-ISV article you saw in the previous chapter. I actually thought I might make a little money on it. In general, I was wrong. My article was successful. It attracted lots of readers, many of whom told me the story of how they were inspired to pursue their own product ideas. But Winnable Solitaire is not a successful Micro-ISV. However, dealing with failure is an important topic too. So, I turned lemons to lemonade and wrote this article.

Everybody seems to love this article. That is, everybody except me. I do value the lessons I have learned, but sometimes it stings to think about some of these stories.

A common mistake is for a small company to hire someone who was previously a success in a large company. The logic seems to make sense. If this person did such great things at XYZ Corporation, that means they are really smart, right? In general, stuff doesn’t work that way. A person can be really smart and also be a really bad fit for the challenges of a small company. Life in a small company is very different from life in a large corporation. People see the (admittedly modest) level of success I have had and assume that I must know a lot. Nonetheless, I consider it very likely that I would not be well-suited to working as an executive in a large firm. Similarly, a programmer who thrived in the environment of a big company is not likely to do well in a small ISV.

Geek founders often think they need a “businessperson” to run the company so they can focus on technology. Most of the time, this is a bad idea.

In a small company, hiring decisions are difficult and risky. It is shocking how easy it is to make a poor decision that has such severe consequences. We should find this to be sobering. We should approach these decisions with a great deal of wisdom. All too often, we do not. Here in the United States, we approach hiring in much the same way that we approach marriage. It has no legal requirement of formal training. Most of us go into the situation unprepared. Over the years, we have picked up a few clichés to guide us. We have watched others do it, so we think we know how. In a disturbingly high percentage of cases, things turn out badly, and everybody within range gets hurt. Some of us learn from the experience and do it better the next time. Most of us don’t. A little preparation would go a long way in either situation. Rest assured that I will not be dispensing marriage advice anytime soon, but I do know a thing or two about hiring.