Stripe Press has launched, with a book called High Growth Handbook, by Elad Gil, about taking a successful start-up through the stage where it has hundreds of employees. Books scheduled for later release include one from Tyler Cowen and a revised edition of Martin Gurri’s Revolt of the Public that includes a forward from yours truly.
I liked parts of Gil’s book. It focuses on an interesting phase for a business–not a start-up, not mature, but in the process of growing from sub-Dunbar to super-Dunbar, from a tribal band to a Weberian bureaucracy.
But I would have been much more demanding as an editor. I would have gotten rid of all the advice that I think is non-actionable, “Make sure you hire a ____ who is smart.” “Don’t do too little X, but don’t do too much, either.” etc. On some topics, I would have pressed for more specific examples, as when the author interviews Patrick Collison, who says
some of these companies–by no means all, but some of them–are in the process of making either major cultural or organizational errors
You don’t have to name names, but at least describe one or two of the types of errors you are talking about.
In fact, I would have asked Gil to devote more discussion to companies that failed in the high-growth phase. What went wrong at MySpace? Netscape? AOL? Napster?
There are some actionable ideas in the book. One of them is for an executive to circulate a document that describes “how to work with me.” If I had thought of doing something like this back when I was in business, here are some things I could have written, some to communicate with my supervisor, some to communicate with people working for me:
1. Don’t give me too many things to do at once. I need to feel like I have my work under control.
2. If you want me to do something that requires my utmost concentration, let me work on it in the morning.
3. If you want me to do something that I hate doing, find someone else to do it.
4. I often give vague project assignments. Push back with clarifying questions, until you know what to do or until I back off because I realize that I don’t really know what I want.
5. When I give a deadline, it is the last possible moment to complete a project. When you miss a deadline, I am devastated. When you just make a deadline, I am disappointed. Get it done sooner.
6. I hate it when people focus on assigning blame. When something goes wrong, focus on fixing it.
7. I like sharing interesting articles and books that I come across. Feel free to do the same with me.
8. I believe in hiring people for attitude and ability, not for experience.
9. The key attitude is being oriented toward solving problems rather than just complaining. I will not tolerate a chronic complainer.
10. I’ll let a software developer get away with being a prima donna*, if you’ve got the right combination of ability, conscientiousness, and stamina. Show me you can really get stuff done, in which case I’d rather keep you happy and let other employees get annoyed than the other way around.
*I define a prima donna as someone who thinks that their superior talent demands recognition and special treatment
Items 8 and 9 are huge; attitude isn’t everything, but it comes damn close. I cringe at the thought of working with people who majored in “grievance studies” in college. How can they be anything but toxic to a business?
Is there such a degree?
Regardless, if you are doing the hiring its easy enough to pass over the Evergreen graduates if you want.
Women’s Studies, African-American Studies, Minority Studies, …
Scary, for sure!
I helped interview and hire entry level positions for a Fortune 50 company for a good while and I can say I never saw “Minority Studies” on any resume. But hey, maybe its a thing now.
But back on topic, my last boss was a #5. If I had just known then what I know now, we would have had an easier time. We’re still good friends though.
On #10, there’s a huge difference between big, complex dev Ops development which “must” be done with a team, and small up to medium work that one guru can do, even if he’s a jerk.
The prima donna is ok in small & medium development, but becomes deadly as the need for teamwork goes up. Deadly in the S curve kind of sense.
#1 Lots of good analysts need few jobs with more concentration per job; most managers have “easier” jobs that require more often switching focus and especially better personal communication. (Women are usually better managers than coders, relatively).
#6 seems good, for fixing an occasional problem. Too little blame assigning, or wrong blame assigning, will lead to an excess number of problems. Only with “blame” does the team learn, in practice, how to avoid similar mistakes in the future.
The optimal time for blaming is AFTER the problem is really fixed, not before fixing it.
“The prima donna is ok in small & medium development, ”
I’m not even sure I agree here. Alienating coworkers, customers, business units, or whomever else you come into contact with will quickly overshadow any talent you may have as a developer.
I don’t know a lot of developers who haven’t play-acted the part of the prima donna on occasion. I do it myself. It can be good for a laugh and it can be a tension reliever. But I’ve met no worthwhile software developers who are actually like that.
#4 is essential for working with every executive I’ve ever worked for.