Yikes, a very long time has passed since my last post, I guess this is what happens when you start a company. Nearly every train ride I think, I should write something because I enjoyed doing this last year. It also got me thinking about time and why I haven’t been doing this other than the most obvious reason – too busy. Why too busy? To the point… the importance of speed in business.

About 12 years ago, I was co-founder of a brand new startup – pre-money, 15 slides and a chair at a local VC office. In 1999, we were funded with $4M and off to the whiteboards to figure out some details of what to build. In about 9 months or so, we had our first software product and I was busy leading a Professional Service team in an effort to customize and integrate enterprise software at customer sites – different days for sure. Our Engineering team was about 15 people and built software using the waterfall discipline after writing design documentation in word, conducting cross functional design reviews and laying out a series of risk based interim milestones. They were perhaps the best Engineering teams I’ve ever worked with – they built rock solid, well thought out, very stable stuff and always right on schedule. Very early in the company, I felt the pressure to go quickly. Not just because I’m impatient, but because I understood the importance of speed to our business. I was actually infamously quoted as asking for “Crappier code quicker” which was counter-intuitive coming from the Services guy and political correctness has never been my strong suit, so my opinion on over engineering was very thinly failed by this comment. The Agile discipline architects produced a more eloquent approach to what I was attempting to facilitate.

In any case, I’ve learned many lessons, gains significant experience and transitioned to leading my own Engineering teams – mostly Agile based and all Software as a Service in the cloud, thankfully. So now I’ve been reflecting back on my keen interest in speed and why. It got me thinking about the old cliche – “Quality, Time and Cost – pick two”. In 1999, I was definitely looking to swing the pendulum away from quality in favor of speed. Today, I still believe that speed is the highest priority of these three. Speed is a super important advantage in so many environments. In the sports world, there are tons of examples like a speedy base stealer yielding more runs, but maybe just as importantly the second order benefits that are forced on a competitor under time pressure. A competitor under pressure is forced to act quickly, with much less think time will make more mistakes and change from their most advantageous strategy. A speedy football defense gains many types of competitive advantages by forcing the quarterback to think quickly and make mistakes. In the cool new startup circles, speed is the key ingredient of the popular “Fail Fast” rally cry. There is no doubt that the speedy first mover advantage is a killer advantage – I could rattle off a hundred companies that are fueled primarily by speed to market – see Groupon for a spectacular example. Sure, there are some counter examples, like Google, but the scales are definitely tipped towards the speedy lot.

So what exactly gives in the closed equation of Quality, Time and Cost. In my experience, cost is almost always fixed in practice – ye’ old budget, so argue as you may but you got what you got. Does this mean that Quality is low man on the totem pole – am I back to crappier code quicker. Actually, no. Features turn out to be the governor, in my opinion, which brings me to exactly why Agile is the discipline that allows a business to launch with a minimally valuable feature set , learn and innovate quickly.