Building an engineering team from the bottom up
I was at lunch last week with a repeat entrepreneur turned VC , and I was talking to him about growing our team at Hyperpublic. I told him that we had been successful at building our team from the ground up, but that we had recently lost a very senior engineering manager to a larger, better resourced startup in NY. I talked about how nice it would have been to bring someone on who could blow out our engineering team quickly, and he shared a perspective that I hadn’t heard before but totally internalized. He said that in the long term, he has seen great engineering cultures ruined by the introduction of a fast influx of new, tightly networked blood (i.e. the 10 guys/girls who that senior engineer has worked with previously…aka “getting the band back together”), and that he prefers to back teams that develop the way we have grown to date.
I looked at the senior guy we lost as a sort of “shot in the arm” for our team that needs to grow from 7 to 25 in the next 18 months, but perhaps discounted the change that would come with that type of super-condensed growth. We have managed to assemble an incredible engineering team at HP over the past 10 months, but the process to get here was far from streamlined. We did not have senior DNA on our team who could build a 10 person team over night, but rather started with just Doug and I, both in our 20’s, with some awesome networks (Y-Combinator, LV, GC, UPenn CS, Carnegie Melon CS, etc…) but lacking a deep “stable” of talent accrued over 20 year careers. We built very organically, from the bottom up, relying heavily on our personal networks, one off hack challenges, and the help of our more technical investors, but it required massive effort and patience. My cofounder Doug was (correctly) adamant about not lowering our bar under any circumstance, and we chose to execute resource constrained (and by definition more slowly) as opposed to bringing on people who were not a perfect fit. Sometimes maintaining that discipline was challenging in the face of a never ending product roadmap and a fast moving market, but we shared a belief that to get the smartest people in New York to join us, we would show ourselves to be peers. Each time we added someone great, we became a more attractive team to join, and today things are a lot easier than they were 10 months ago. Granted, we’ve executed across other facets of the business and have matured as a company, but the smartest people we interview always seem to zero in on who they will be sitting next to if they join.
This dude’s advice, that I hope he won’t mind my sharing, was that “there are no shortcuts to building a great company.” I liked that concept. We continue to hire across the stack at all levels of experience, but perhaps now with an increased weariness for anything that looks like a shortcut.
As I always say “if you cut too many corners, you’ll never have an edge.” Jumpstarting a dev team with an existing one simply transfers over those embedded bad habits and doesn’t allow each dev to grow from the previous experience.
Greg Battle
August 2, 2011
i like that quote…
jordancooper
August 2, 2011