Glenn Reid wrote a post last week on working with Steve Jobs. I find these articles fascinating. A little insight into the way he worked. One of my favorite portions:

Not only did [Jobs] know and love product engineering, it’s all he really wanted to do. He told me once that part of the reason he wanted to be CEO was so that nobody could tell him that he wasn’t allowed to participate in the nitty-gritty of product design.

When Infinity Softworks started it was real small. There were three of us. Soon, though, everyone left and I was doing it myself. My goals were to prove to myself I could write commercial-quality code and manage the development process. I also was excited to do marketing, sales, customer support. I wanted to do it all. I figured it was the fastest way to figure out what I enjoyed and what I wanted to specialize in.

At some point, I added more people and we decided to raise a round of funding. Rather then embracing what I was good at and getting help for the rest, I moved on to the next experience: raising money, managing people. I left running the business to those I brought on board. As you might expect, the company went sideways.

Giving up everything led me to understand that what I really loved to do was product. I loved the design aspects, thinking through how customers work with them, refining and improving them. The mistake I made was not learning, in those first few years, what I was really good at and understanding what I needed to do to build a successful business. I understand that better now. I understand, as we consider a growth plan again after all these years of treading water, that in order for Infinity Softworks to be successful, I can’t turn over complete control of the company to those who come on board. I can’t imagine giving up the product vision again.

My mistake 12 years ago was thinking adding more people meant I didn’t have to do as much. In some ways that’s true. Other people run those aspects of the business. I was no longer solely responsible for development, marketing, sales.

But in other ways that’s false. My job needed to move higher up the tree. Instead of digging around in the roots, I needed to be watching the landscape, making sure we could see the entire forest. It didn’t mean giving up the product. It meant making sure the entire team was working toward the same vision.

Adding more people doesn’t mean less work. I understand now it means I do even more.

I always wondered about this: if your service is designed to be most valuable with multiple people then how do you get the first ones? The quintessential example is the telephone. Doesn’t do any good if only one person has a phone. The fax machine had the same problem. So did Twitter and Facebook.

Fred Wilson talked about this issue in relation to the bookmarking service delicious:

The first users of delicious were barely aware of and rarely used its social aspects. They just wanted to store their bookmarks in the cloud instead of in their browser. And they liked the tag based classification system. And they liked being able to use their links from any device. That was the single person utility delicious was built on.

But because bookmarks were public by default which resulted in most links being shared with others, a large social system developed. The delicious popular page was an important web destination in its day and most of those visitors never posted a link to delicious. They consumed others’ links.

As we’ve been working on new stuff here, we’ve wanted to make sure that it is social naturally. Sharing stuff, after all, is very human. But in order to get the first person to use it, it must also have utility for a single person. Or, as Fred puts it, social systems must have single user utility, too.