I really enjoyed the 7 myths of Entrepreneurship on Tim Ferriss’ site. The examples are from software development, but apply to most small tech firms. Having been through 6 startups of my own, I pretty much agree with everything said. More to the point, these ‘myths’ are the more common pitfalls I witnessed over and over again. That said, I think there is more to be gained here, and some important points were left on the cutting room floor. Specifically:

  • Code Ninjas: If you have been in development long enough, you have run into a code ninja. I have seen a single person architect, write, and maintain a full-featured OS ultimately installed on a quarter-million machines. My friend Tony tells an awe-inspiring story of a ninja rewriting the core of a UNIX Kernel in a week – after 115 other engineers had failed for a year. I don’t think Java could have happened without Gosling. I will say you don’t have to hire ninjas to succeed, and many excellent teams lack one. People get caught up in striving for greatness, and think a ninja is their key to greatness. Sure, it’s better to have one than not. But the real trick is to find a ninja who’s not a prima donna, as they have the capacity to belittle, pout, and de-motivate as easily as they can produce, teach and inspire. Software development is not a lone-wolf exercise, so if you’re not sure if a possible ninja can coexist with the rest of the team, play it safe.
  • Running Hot: It’s not just that running hot burns developers out – it’s a sign of mismanagement. Management pushing too hard means unrealistic expectations, or a willingness to push developers to the breaking point (typically using pride as motivation), or both. “Instilling a sense of urgency” is usually a BS way of saying “work harder”. Don’t get me wrong – sometimes you need to push. I have seen engineering oriented-companies be very lackadaisical about delivering product. The Ask version of Ingres was a prime example. But running hot means burnout, lower quality, and turnover. My tactic was to get developers to invest the extra hours in reading about their profession on the train ride home. Technical books, magazines, web groups, conferences, and classes educate. More importantly, learning tends to inspire. It’s hard to be creative when you can’t sleep and are stressed out, and inspiration doesn’t come from slogging through 40 task cards without a break.
  • Deadlines: The single biggest friction point, and one of the hardest management tasks, is managing to deadlines. It also shows the greatest disconnect between sales and development teams. Builders view deadlines as arbitrary, and in their cycle, the code is done when it is done. Sales needs something – anything – to sell, and in their cycle predicable delivery is everything. Yanking stuff at deadline pisses sales and prospects off regardless, and getting stuff back on the queue is a nightmare. Agile can help. Better and stronger product management helps. Vetting sales requests helps. Promising less helps. Ultimately there is no right answer, but the friction can be mitigated.
  • Hiring: HR is the single greatest detractor to hiring the right people. There, I said it. HR tends to enact hiring standards that weed out the best candidates before they are even interviewed. Hiring managers get the same stale set of resumes because they are what made it through the HR weeding process. And HR only goes by a) a misinterpretation of what you told them to look for, and b) what their peers are doing. To avoid the resultant poop-colander effect – where only correctly shaped poop gets through – many companies adopted ‘quirky’ hiring practices. And these tricks work – you get a different set of poop candidates. Not better, just different. Two years later you contract with a head hunter – who simply does a better job of understanding your requirements, idiosyncrasies, and biases than HR – and they find you candidates you can accept. Because they are paid very well to understand what you want. Managers: You want better candidates, so do your own screening!