Previous Entry Share Next Entry
Paul Graham's essays are delightfully refreshing
Over the past couple of days, both mindways and metahacker have pointed me at the writing of Paul Graham, one of the folks behind Y Combinator. The best way to thank them seems to be passing the link on.

The essays are largely about how to succeed with an early-stage startup. Graham has a good view of this, having done it himself and by now helped a *lot* of others get there. These essays are basically distillations of what he's learned about it.

The truth is, Graham isn't saying an awful lot I hadn't already figured out. I've been doing startups on and off for literally my entire career (my first job was my father's startup company, which never really got off the ground but taught me a lot), and I know the game pretty well. Still and all, I expect to spend much of the next month working my way through these and thinking about them.

Tangent: hmm. How many startups *have* I been in? Now I'm curious. Let's run through my jobs:
+ Aero Micro / System Dynamics (technically two companies, but they had the same three employees, so...)
? HDI (growing rapidly when I was there, but didn't quite *feel* like a startup)
- Intermetrics / Averstar (medium-sized, old and well-established)
- Looking Glass (small, but pretty much in its groove by the time I got there)
+ Trenza (my Doomed Bubble Company)
+ Buzzpad
+ Applied Messaging / Convoq / Zingdom (arguably Convoq and Zingdom were two successive companies that shared most employees and a bit of code base)
+ CommYou
? Memento (small, but not originally growth-oriented; OTOH, my project was the part of the company that *was* supposed to scale aggressively)
+ Querki
So Querki is roughly my sixth startup, about what I figured. Anyway...

Some of what he has to say is already explicitly factored into Querki's business plan -- for example, his most recent essay, Do Things That Don't Scale, talks about the way you have to fight for every single user when you're a larval startup, and that's what I expect August - February to be like for me. Indeed, his discussion of hardware startups is weirdly appropriate to me -- just as a hardware startup needs to assemble its own components by hand at first, I expect to do a *lot* of hand-holding for the early-stage Querki Spaces, both as customer support and to help me learn what needs improvement.

That said, he does fill in some extremely useful details -- for example, his essay Startup == Growth gives a maginificently useful concrete metric for solid success as a startup (5-10% growth per week), which I'll be factoring into the plans for next year. Indeed, his viewpoint that growth is *everything* for a startup is bracingly useful -- he advocates being extremely disciplined about this as a way of keeping yourself focused. That makes oodles of sense, but hadn't occurred to me before.

And even when he's saying things I already know, it is *remarkably* comforting to hear someone experienced saying them. Do Things That Don't Scale is particularly valuable there, since it confirms that my plans are the appropriate way for things to start. (Indeed, he largely implies that this is the *only* way to start.)

Anyway, these are great essays -- topics and approaches that sound like common sense, except that most startups completely fail to understand this stuff. Well worth reading for anybody in the startup world...

  • 1
In the small world department, pg founded Viaweb (which became Yahoo! Stores) along with Mark Nitzberg; Mark is my CTO.

He mentions Stripe. Stripe is amazing. I mean, the culture. The kind of startup I'd work for. Freedom, fun, pleasure to be there, smart friendly people.

I was just mentioning Graham to a junior colleague the other day --- in particular, his The Art of the Essay. It's probably the best piece of writing-about-writing I've ever read, and certainly the one I've recommended the most. I especially like to point engineers whose communication skills are lacking at it: they often suffer from the sort of miseducation about writing he opens by trashing. But my main point to people like my coworker is Good code is a clear expression of clear thinking. The best tool for clarifying your thinking is to write out your ideas. But never mind me: Here, look at what this famous millionaire LISP-hacker has to say about writing....

  • 1

Log in

No account? Create an account