I read an early draft of An Engineer's Guide to Silicon Valley Startups months ago, but didn't blog about it then because it wasn't published yet. And then, when it was published, I forgot that I hadn't blogged about it yet. Time to fix that. Time to blog.
The author, Piaw Na, worked at a bunch of startups. This book is his advice to some young fresh-out-of-school geek who's considering working at a startup. There's two buckets of info in this book:
- How to figure out whether you'd be happy working at a startup; if you choose a startup, how to be happy; etc.
- The financial shme: what it means when the options plan turns into a stock plan; Alternative Minimum Tax is weird but you still have to pay it; etc.
Kids should read this book for the first bucket of info, but they probably don't know that. So you can tell them to read it for the second bucket of info. And hope that they absorb some of the wisdom from the first bucket along the way.
I shouldn't downplay the value of the financial advice. Suppose you're an engineer hanging out with a bunch of other engineers at the company and something about the stock plan changes. You ask around about the implications: you probably get some shrugs, some answers that aren't even internally consistent, some obvious half-assed guessery. If you're like me, you give up before you find answers. Here are the answers!
But there's also a lot in here about what it's like working at a startup as an engineer. This is pretty useful because there's already tons of material out there for company founders, but not so much for you if you're, say, employee number 40. The material in here has different assumptions: Maybe the company isn't your whole life. There's good advice in here about how to hire, how to run your startup.
I liked this quote from Wayne Rosing about Google's then very-flat engineering management hierarchy in which a manager might have ~40 reports:
I believe there was at least another factor of 10 left in the hyperflat structure. But the keys are very basic: avoid non-engineers in management of engineering, give people creative and intellectual freedom but in a constrained way (hence the 20% time memo) in terms of productivity impact. Preserve a hot young computer science department-like atmosphere with respect for integrity and truth. And last, keep the ratio of engineers to others in balance; Maximize your expenditure on people who create the wealth, not those who take a cut of it.
So there you are: advice to a naive engineer considering the world of startups, leading up to advice on what to do in case you find yourself as the VP of engineering riding herd on a few hundred geeks. It's not as scary as you thought.
