They say that a wise man learns from other people’s mistakes. I’ve always found it easier to learn from my own. They’re more personal, and the lessons are clearer. It’s one thing to read that cash flow that kills a business, it’s another being unable to pay salaries because a customer won’t pay. It’s one thing to read that employment contracts are important, it’s another to be sued by an employee you’ve fired whose contract you cobbled together yourself to save a few dollars. It’s one thing to be told to listen to your customers, it’s another to launch a product and watch it flop because nobody wants it.
I do, however, try to understand my mistakes after I’ve made them. Often the lesson is obvious, but sometimes it’s more subtle. Occasionally I come across a blog entry or a paragraph in a book that helps me understand, deeply and with clarity, why what I did was so dumb. It gives me the information I need to interpret my mistakes and to learn from them. Even more rarely – once or twice a year maybe – I come across a person or a book that streams those insights out, sentence after sentence or page after page.
What does this have to do with software? Eight years ago, Simon Galbraith and I set up Red Gate Software. Since then, we’ve grown from 2 people in a bedroom to just under one hundred people. We’ve been profitable almost all that time. I’ve made all the mistakes at the beginning of this post, and more. The mistakes I’ve made aren’t unusual. Everybody makes similar ones starting out in the software business. I have, however, been lucky enough to stumble across a number of people who’ve helped me learn from some of my mistakes.
Here are a couple of examples. The second developer we ever hired was mediocre. After much hesitation, we fired him. In Peopleware, Tim Lister explains how a hot-shot developer is orders of magnitude better than a mediocre one. Even if he costs twice as much, you’re getting 1000 times more so it’s worth it. It just doesn’t make sense to hire mediocre developers. This is something I’ve always known, but until I made the mistake and read Tim’s book I didn’t truly understand it. More recently, we tried to give our developers performance related bonuses. That was a messy and expensive disaster. Before we tried it, I knew the theoretical pros and cons, but until I’d made the mistake and Tim explained why, that knowledge was useless theory.
Jeff Pfeffer’s book Hard Facts, Dangerous Half-Truths and Total Nonsense gives more insights into performance related pay. Not only does Jeff demonstrate that performance related pay doesn’t work, but he also shows that much conventional wisdom is simply wrong. With his help, I took my specific, first-hand, failure implementing performance related pay and turned it into a general rule about conventional wisdom.
Whether you’re a Micro ISV or Microsoft, Tim and Jeff are but two of the people you should listen to. I’ve put together a conference where Tim, Jeff and some of the other world-class thinkers, writers and doers I’ve come across will be speaking. You should go. You can find out more at www.businessofsoftware.org.