If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.
Antoine de Saint-Exupéry (attributed)
There are a lot of ways to build bad engineering teams, and very few ways to build great ones. I’ve come to believe that the attributed quote above spells out pretty much the only way I know how to build a great development group. (If you can’t stomach the poetic misuse of “axiom” in my title, call it “The Little Prince Method” instead — yup, same Saint-Exupéry.) Belief in this idea seems almost religious — you either get it or you don’t. There’s no logical proof that supports it, just a bunch of anecdotes that bear common themes. If you accept it as a guiding principle, you can easily derive from it a small set of rules that guide engineering in the right direction. If you do not accept it — and I would say that nearly all executives, investors, pundits, and even engineers in the software industry do not — then it will seem like lunacy to run a development group on this idea.
I was recently asked how I run our development team. I said, “Well, basically I blog about something I think we should do, and if the blog post convinces the developers, they do it. If not, I lobby for it, and if that fails too, the idea falls on the floor. They need my approval to launch something, but that’s it. That’s as much ‘running things’ as I do, and most of the ideas come from other people at this point, not from me and my blog posts. I’ve argued against some of our most successful ideas, so it’s a good thing I don’t try to exert more control.” I’m exaggerating somewhat; of course I haven’t blogged about all of our ideas yet. But I do think of myself as Lobbyist-in-Chief, and I have lots of good examples of cases where I failed to talk people into an idea and it didn’t happen as a result. One person I said this to asked, “So who holds the product vision, then?” and I replied, “Well, I guess I do,” but really that’s not right. We all do. The product is the result of the ideas that together we’ve agreed to pursue. I recruit people based on their interest in and enthusiasm about the ideas behind Wesabe, and then set them loose, and we all talk and listen constantly. That’s how it works — and believe it or not, it does work.
I’ve heard lots of ridiculous ideas about why Google has been able to recruit so many great people, and anyone who thinks it has to do with use of logical puzzles in interviews is out of their freakin’ mind. I don’t believe any single interviewing technique, nor any combination of techniques, is repeatably great at finding the best engineers (as I said in my VCAT post earlier this week). I attribute Google’s success at hiring to three things primarily:
- I suspect that several of the early leaders of Google’s engineering group (I’d identify a chain of Larry Page, Urs Hölzle, and Wayne Rosing from the people I’ve encountered, although I’m sure there are others I haven’t) have golden guts about hiring developers and keeping them happy, and were able to find and recruit people using whatever techniques work for them individually;
- Google has a very clear and memorable idea about what they do — organize the world’s information and make it universally accessible and useful — and by luck or design or both, that mission is at once admirable, idealistic, and lucrative; and
- past recruiting successes plus retention plus #2 have all snowballed, so that the engineers who have been hired make sure they hire other people they like and want to work with (which is the best recruiting technique of all), and people who would be great hires seek out jobs at Google.
I think most other things that have worked for Google flow from those three. For #1, you have it or you don’t. For #3, it’s happened or it hasn’t. #2 is the best target you have for hacking your engineering management technique. Are you working on a great project? Do you have a clear statement of what it is? Do you promote it out to the world so everyone knows what you’re doing, and the people who love the idea will come find you?
If not, you’re left with applying strong doses of money, hope, command and control, and baling wire (to tie down the developers who want to go work at Google instead). I’m not saying baling wire won’t work for a while — it can. The more common name in the industry is “golden handcuffs,” by which is meant a very strong economic incentive to stay. But Google did not start out paying top dollar for engineers; far from it. They started out teaching people to yearn for something vast and endless and amazing, and that works.
Let’s take a counter-point to see this more clearly: what is Yahoo!’s mission? What sea is it they want to sail? I have no idea. If I’ve heard it, I’ve forgotten it, while with Google I was able to type it in off the top of my head, nearly word-for-word, above. There are a lot of great people at Yahoo!, but I don’t think they applied to work there because they have a clear, common goal to pursue, and at least some of them seem to agree.
The best way to get developers to build something great is to make them believe your goal is worthwhile. If you do, control from the top will not only be unnecessary; it will be impossible. That’s the best situation you can hope to create, and frankly I love that so many people don’t believe that, since it makes things so much easier for those of us who do.
Previous engineering management hacks: