From Nothing To Something. How To Get There.
techcrunch.com
techcrunch.com
(Plus 'button goes over here' type input is actually really valuable - when working on UI stuff you tend to get tunnel vision and/or implement what works with the underlying design rather than what makes sense to a user who has no idea about the structure of the data.)
Its not my path (Go out, get job, learn how to do things there, start own business), but it definitely brings some advantages with it.
I've built many trading systems but getting my own thing off the ground has been really really hard. I'm getting there slowly but looking back I think I'd have been more sucessful if I had tried to start a company right from college.
In corporate america, all you do is take care of your own small corner of the business. Namely either sales, business or coding. Building a business means knowing all three.
Working in M&A at a bank would basically mean that he created word documents containing lies of how great an acquistion a certain company is for potential buyers. I have 3 friends who do this for a living. I would bet 0 of them would have a clue how to start their own business.
In his case he (ie working for the aquicuirer) would be reading these documents and trying to decide if they make sense and which company to buy. BS because mostly your say really doesnt matter.
My path was the opposite of many people: I worked for 2 startups, founded one, am now working for a big company, and hope there's another startup in my future. Google was the first company I've worked where I didn't have to set up the build system. And naturally, Google's build system is better than anything I've ever set up.
When you work for a big company, you get to draw on the accumulated wisdom of thousands of people that have come before you. A lot of things that seem obvious once you've looked at them - like how to organize your code, or how to design C++ programs with clear object ownership, or how to unit test libraries with lots of dependencies - require lots of laborious trial and error to get right before yourself. Many startups are filled with people that are fairly new to programming (because that's all they can get) and don't have that experience. You can easily go through several jobs thinking that SourceSafe and zip files count as a version control system, it's normal for functions to be 400 lines long, and deployment consists of FTPing a JARfile to the production servers.
The weakness in big companies is that you don't see all the false steps that led to these "best practices" being instituted. So you might leave and found a startup thinking that you absolutely must have 100% unit test coverage for everything, because that's the way things were in your 100+ person division in the old company. Or you might go too far in the other direction, and think that you don't have time to setup a decent build system. It takes experience - in both environments that have them and those that don't - to understand the particular circumstances where "best practices" are really best practices.
IMHO, the ideal career setup for founding a startup is to intern at startups in high school & college, then work for a fast grower or big company for a couple years afterwards. (And start lots of little companies while you're in classes, of course. ;-)) Startups typically demand more from interns than big companies do, because there's more to do, and you also get to see firsthand all the problems caused by inadequate development practices. And then you can see things done right at a big company, with enough time to actually dive into the meat of it. You still probably won't succeed with your first company (almost nobody does), but at least this'll expose you to what both success and failure looks like.
By big company what you really mean is "work for google".
Again the only thing you'll learn is tech. You wont learn sales or business or accounting.
Taking your example of organizing code and designing C++ code, you could develop these skills by just working on open source code will give you that.
Infact I use a lot of the tools/programming idioms/libraries that I've learnt from the open source community at work. It actually gives me an edge over the crap they do at my big-company.
Again, if by "work for big company", you mean work for Google then I totally agree.
Man, I have failed again in my quest to experience every kind of employer.
I think my next job is going to be at McDonalds. I've never worked in food service, and perhaps it won't be quite a distorted perspective as where I've ended up.
That's true, but you still have the opportunity to learn about other aspects of the business even if you're not responsible for them. I talk to people in other departments, go to their (open) seminars, read about what's happening. Not to mention large corporations have many, many training classes in various areas. I'm a software developer, but I took in-house classes in Finance, Recruiting (improving interviewing skills), Communication, Influence, and more.
Don't just sit in your little corner and you may be amazed at how much you can learn.
For those people with a lot if communication happening via ICQ and MSN and whatsoever, this is a very strong and helpful thing.
vs.
"worked in IBM’s mergers and acquisitions department..."
How much more of the man can you work for?
God, ain't that the truth. It's an unrecoverable error. Learned that one the hard way.
His entire product is just an HTML front-end to libpurple, which is 99% of his codebase. And that is FAR from "nothing"
And libpurple isn't even mentioned in the article, yet a ton of space is wasted on how he kept thinking about a "next great thing". What an asshole.
At least Pidgin folks openly say "we are GTK+ front-end to libpurple". Will it kill these SV types to admit building HTML front-ends to open source products?
There was something very right about Zed Shaw's rant regarding open source licenses.
same thing goes for the servers, everyone starts out thinking that they need some server farm, just in case they hit some success. Here is a dirty little secret, don't expect overnight success, you'll have plenty of time to grow into needing that big server, but there is no point in wasting money on something you don't need.
Definitely true. One remark though: "plenty of time" won't be entirely true. When you first need to scale up you probably don't have any kind of server monitoring set up. There's more important stuff to be done. This means that you will notice far too late that you're out of capacity. It will be hard work and it will be painful for you and your start-up.
It scales for you, and you only pay for what you use. So if your site starts out slow, you'll be paying similar costs to a shared server. If your site takes off, you'll be paying similar costs as a dedicated server. But the important thing, is that you won't have to bother guessing which will be the case for your site.
For every 50 consumer startups that email Techcrunch/Venturebeat/Gigaom etc... one will be covered. If this does not happen, then getting that first set of beta users will be extremely time consuming (unless you resolve to less-than-ethical methods aka SPAM).
Products like Meebo took off from the start. I am sure most issues they had were around hiring, scaling, and monetizing. Most startups' problem is not what to do with the traffic or how to afford more servers, larger teams. The biggest problem we have is not even building a prototype or convincing someone to partner with us. The issue is how to get users.
Maybe in his next posts he will touch this subject.
Maybe it's not a typical symptom in the HN community as much, but in general, I really hear a lot of people working on startups from the outside in: high concept, powerpoints, spreadsheets, raising money, legal nonsense, THEN finding someone to build their idea.
It's good to be reminded occasionally to just build the product when you're getting started.
Hyper-focus, have patience and persistence, and constantly keep improving the service. There is no other way. TechCrunch only helps you for a day. But after that day is over, you are back to the same problems again.
However, I still find the OP useful. I can't tell you how many aspiring entrepreneurs I've met who need a reality check. This post provides it succinctly and understandably. Granted, this crowd (HN) is pretty much already on the next step, but a lot of people are stuck on that first one.
We've been in those publications multiple times, and since I run Google Analytics with goals, I know how many new users and transactions they send. It's de minimus. The links might be good for PageRank, but you'd rather be in Lifehacker anyway.
If you think users will come because you get into these pubs, please try harder.
I run Google analytics with goals too for my website and at my day job. And let me tell you that in both cases I am pushing products that no one is jumping to write about. The same is true for (arbitrarily) 9 out 10 companies. Hence organic traffic is not easy to create, and paid traffic is as good as throwing money off the windows.
So when giving advises, give advises to this group. Not the one who can built a product and gain traction easily. I have not done this successfully so I cannot tell anyone how to but here are a few examples:
- Don't go to major blogs first, go to smaller ones (TC used to be small when Meebo launched in their living room) and create a relationship there. Find a few competitors or a business that is complementary to yours and do a Yahoo Link Search/Google BlogSearch to figure who is writing about them (call it regression analysis if you want), and drop them 4, 5 lines and ask them "Can you please present us to your audience". Email users with an "Invite your friends" link. SEO is a marathon, not a Sprint. Be steady and set a goal to email at least 5 new blogs/newpapers everyday. Call a couple local radio stations, or TV stations, everyone is looking for a story. If people don't answer after 21 days email again with a polite 2 liner, because sometimes your emails get overlooked. Email the guys at Startupschwag, and ask if they can include your startup in their next mailer. Etc....Be HOTDAMN PERSISTENT, because the "only thing you can control is INPUT".
Maybe a budding lawyer can shed some light on the benefits of incorporating before you have anything truely worth incorporating.
Best 2 people to do a start-up?
A programmer and a business guy? No.
A programmer and a designer? No.
2 programmers. Yes.
Classic.
Seriously though, having someone who comes from the aesthetic/UI side is a lot more useful than the generic "MBA" type who has a big vision and just needs someone to build the site. For instance, Flickr and Typepad both had a hacker/designer founding team. One of the recent YC teams had 2 designers and only one hacker and have been doing really well. The best example is probably Apple, SJ had some technical skill, but his real art was designing the UX, but had SW to handle the technical challenges. I'm all for the coder/coder team, but a great designer is not a bad addition!
My ideal founding team would have three members: a frontend engineer/designer, a backend engineer, and a business/marketing person. I think this is basically what Seth was saying, and I've also heard the RescueTime founders say that this is a great combination (it's what they have).
I wouldn't really want to go without the business person entirely, simply because somebody has to hold the entire product vision in their head, and the engineers usually have plenty to think about anyway. The tension between "C'mon guys, we can make this better" and "Okay, let's dive in and make this better" seems to be necessary for great creative works. That was really Steve Jobs' role in Apple - as I understand it, he did basically none of the coding. It also helps to have someone take care of all the interruption-driven tasks of running a company - following up on leads, talking to the press, drumming up excitement, getting feedback from potential customers, etc.
The cleverest app, or piece of coding is useless if the user doesn't get what they want from the experience of using it.
Brilliant design doesn't have to be flashy or clever, and of course, the simplest interfaces are always the best. There is a huge amount of skill and intelligence involved in taking what is a potentially complex idea or concept, and expressing to the user, not only how to use it, but also what the app is capable of, in a simple, graphical way.
There's been a of of discussion on HN about the new Sequoia site. I think I'm one of the few who think it's brilliant, because it already assumes a lot about its users, and that if they're on the site, they probably have a pretty good idea already of why they're there. The site is tailored to those people, they don't need to be hand-held with descriptions and explanations. This would be completely out of place in many other instances, but the designers knew their users, and what their needs were, so built accordingly. The web is a graphical interface for information, great design is crucial.
The OP made the point about a team...my point is that this has to a be a balance of skills, each member understanding their value and importance to the project, and understanding and valuing the importance of their colleagues. Teams made up of entirely one skill set will never be as productive as one with a wide range of skills.