We are not all born entrepreneurs.
And to say the truth, not many of us can turn down a secure job offer from a company like Microsoft just to go tinker with our ideas turning into business.
But the fact is that fortune only favors the brave.
When you have a business idea, you’re not guaranteed of automatic success, but you’ll never know how much you can achieve if you don’t try at all.
There are chances that your business will fail several times, but you’ll learn, you’ll get up and try again, and again and again.
Introducing: Tom Preston-Werner, Co-Founder of GitHub
Before going Github fulltime, Microsoft had just acquired Powerset where Tom worked for$100 million. With the acquisition, Tom could either sign on as a Microsoft employee or quit and go GitHub full time.
At 29 years old, he was the oldest of the three GitHubbers, and had a proportionally larger amount of debt and monthly expenditure.
Microsoft offered Tom a great deal; enough to make anybody think twice about anything. Salary + $300k over three years juicy. In Tom’s own words…
“… I was faced with this: a safe job with lots of guaranteed money as a Microsoft man –or– a risky job with unknown amounts of money as an entrepreneur.”
At this time, the GITHUB project was just starting out and the prospects was unpredictable. No one could say for sure if it would succeed or not.
The odds were piled up against him but he quit all the same and joined his friends to go GITHUB.
What is GitHub?
L to R: Rick Olson, Tom Preston-Werner, and Chris Wanstrath. (Photo by Dave Fayram.)
GitHub is a social networking platform that offers programmers a place to store their code and work on open-source projects. It is a web-based hosting service for software development projects that use the Git revision control system.
GitHub offers both paid plans for private repositories, and free accounts for open source projects. As of May 2011, GitHub was the most popular code repository site for open source projects.
The site provides social networking functionality such as feeds, followers and the social network graph to display how developers work on their versions of a repository.
GitHub also operates other services: a pastebin-style site called Gist that provides wikis for individual repositories and web pages that can be edited through a Git repository, a slide hosting service called Speaker Deck and a web analytics platform called Gauges.
In summary GitHub is the go to place to share code with friends, co-workers, classmates, and complete strangers. Th website claims that Over four million people use GitHub as at today.
10 Harsh Lessons Tom Preston-Werner Wants Every Entrepreneur to Learn.
Here is the source of this article. I have deleted some parts of the write-ups because I don’t like long articles.
1. Start Early
Back then, the Git landscape was pretty barren. Git had only recently become usable by normal people with the 1.5 release. As for Git hosting, there was really only repo.or.cz, which felt to me very limited, clumsy, and poorly designed. There were no commercial Git hosting options whatsoever.
Despite this, people were starting to talk about Git at the Ruby meetups. About how awesome it was. But something was amiss. Git was supposed to be this amazing way to work on code in a distributed way, but what was the mechanism to securely share private code? Your only option was to setup user accounts on Unix machines and use that as an ad-hoc solution. Not ideal.
And so GitHub was born. But it was born into a world where there was no existing market for paid Git hosting. We would be creating the market. I vividly remember telling people, “I don’t expect GitHub to succeed right away. Git adoption will take a while, but we’ll be ready when it happens.” Neither Chris nor I were in any particular hurry for this to happen.
I was working full time at Powerset, and he was making good money as a Rails consultant. By choosing to build early on top of a nascent technology, we were able to construct a startup with basically no overhead, no competition, and in our free time.
2. Adapt to Your Customers
Here’s a seemingly paradoxical piece of advice for you: Listen to your customers, but don’t let them tell you what to do.
Customers want a solution to their problem. To save time they will formulate what they think is a solution and give it to you, in the hope that it will speed up proceedings.
Think like a doctor. When the patient turns up, he or she may have a diagnosis in mind. But it is up to you to study the symptoms and deduce the condition independently of what the patient thinks.
Remember: a potted request from a client is a symptom of some deeper problem they wish to solve.
3. Have Fun
Working on a startup is tasking. Burnout is a real and dangerous phenomenon. Fostering a playful and creative environment is critical to maintaining both your personal health, and the health (and idea output) of the company.
4. Pay attention to Twitter
People have a tendency to turn to Twitter to bitch about all the little bugs they see on your website, usually appended with the very tiresome “FAIL”. These are irksome to read, but added together are worth noticing. Often times these innocent tweets will inform a decision about whether an esoteric bug is worth adding to the short list.
We also created a GitHub account on Twitter that our support guy uses to respond to negative tweets. Offering this level of customer service almost always turns a disgruntled customer into a happy one.
5. Deploy at Will!
In the world of web development, the target is your ideal offering, the bullets are your site deploys, and your customers provide the feedback mechanism. The first year of a web offering is a magical one. Your customers are most likely early adopters and love to see new features roll out every few weeks.
If this results in a little bit of downtime, they’ll easily forgive you, as long as those features are sweet. In the early days of GitHub, we’d deploy up to ten times in one afternoon, always inching closer to that target.
Make good use of that first year, because once the big important customers start rolling in, you have to be a lot more careful about hitting one of them with a stray bullet. Later in the game, downtime and botched deploys are money lost and you have to rely more on building instruments to predict where you should aim.
6. You Don’t Need an Office.
All four fulltime GitHub employees work in the San Francisco area, and yet we have no office. But we’re not totally virtual either. In fact, a couple times a week you’ll find us at a cafe in North Beach, huddled around a square table that was made by nailing 2×4s to an ancient fold-out bulletin board. It’s no Google campus, but the rent is a hell of a lot cheaper and the drinks are just as good!
This is not to say that we haven’t looked at a few places to call home. Hell, we almost leased an old bar. But in the end there’s no hurry to settle down. We’re going to wait until we find the perfect office. Until then, we can invest the savings back into the company, or into our pockets. For now, I like my couch and the cafe just fine.
7. Hire Through Open Source
Beyond the three cofounders of GitHub, we’ve hired one full time developer (Scott Chacon) and one part time support specialist (Tekkub).
We hired Tekkub because he was one of the earliest GitHub users and actively maintains more than 75 projects (WoW addons mostly) on GitHub and was very active in sending us feedback in the early days. He would even help people out in the IRC channel, simply because he enjoyed doing so.
I met Scott at one of the San Francisco Ruby meetups where he was presenting on one of his myriad Git-centric projects. Scott had been working with Git long before anyone else in the room. He was also working on a pure Ruby implementation of Git at the same time I was working on my fork/exec based Git bindings. It was clear to me then that depending on how things went down, he could become either a powerful ally or a dangerous foe.
Luckily, we all went drinking afterwards and we became friends. Not long after, Scott started consulting for us and wrote the entire backend for what you now know of as Gist. We knew then that we would do whatever it took to hire Scott full time. There would be no need for an interview or references. We already knew everything we needed to know in order to make him an offer without the slightest reservation.
The lesson here is that it’s far easier and less risky to hire based on relevant past performance than it is to hire based on projected future performance. There’s a corollary that also comes into play: if you’re looking to work for a startup (or anyone for that matter), contribute to the community that surrounds it. Use your time and your code to prove that you’re the best one for the job.
8. Trust your Team
There’s nothing I hate more than micromanagers. When I was doing graphic design consulting 5 years ago I had a client that was very near the Platonic form of a micromanager. He insisted that I travel to his office where I would sit in the back room at an old Mac and design labels and catalogs and touch up photographs of swimwear models (that part was not so bad!). While I did these tasks he would hover over me and bark instructions. “Too red! Can you make that text smaller? Get rid of those blemishes right there!” It drove me absolutely batty.
This client could have just as easily given me the task at the beginning of the day, gone and run the business, and come back in 6 hours whereupon I would have created better designs twice as fast as if he were treating me like a robot that converted his speech into Photoshop manipulations. By treating me this way, he was marginalizing my design skills and wasting both money and talent.
Micromanagement is symptomatic of a lack of trust. The remedy for this ailment is to hire experts and then trust their judgment. In a startup, you can drastically reduce momentum by applying micromanagement, or you can boost momentum by giving trust. It’s pretty amazing what can happen when a group of talented people who trust each other get together and decide to make something awesome.
9. You Don’t Need Venture Capital
A lot has been written recently about how the venture capital world is changing. I don’t pretend to be an expert on the subject, but I’ve learned enough to say that a web startup like ours doesn’t need any outside money to succeed.
I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions.
In the end, every startup is different, and the only person that can decide if outside money makes sense is you. There are a million things that could drive you to seek and accept investment, but you should make sure that doing so is in your best interest, because it’s quite possible that you don’t need to do so. One of the reasons I left my last job was so that I could say “the buck stops here.” If we’d taken money, I would no longer be able to say that.
10. Open Source Whatever You Can
In order for GitHub to talk to Git repositories, I created the first ever Ruby Git bindings. Eventually, this library become quite complete and we were faced with a choice: Do we open source it or keep it to ourselves? Both approaches have benefits and drawbacks. Keeping it private means that the hurdle for competing Ruby-based Git hosting sites would be higher, giving us an advantage. But open sourcing it would mean that
I trust that this has made a good read for you. Let us know what you think