But getting there is a serious challenge. We have five kids, one van and at least 17 hours on the road. So there is a great deal of planning that is done up-front. We plot out where to get gas, what rest stops to hit, what snacks to bring and where to find the first Chick-Fil-A once we cross into Tennessee. The goal is to have no surprises; to know exactly what we are doing.

And that is how we used to build software as well.

Not too long ago, we would sit down at the start of a project and write down everything we were going to do. We would plot out the bugs we were going to fix, the features we were going to add and how much time each step would take. We would spend weeks or months creating documents and charts filled with details. The final schedule would be meticulous in detail and brimming with confidence.

And then the van would crash into a ditch just outside of Indianapolis.

I’ll get into the hows and whys of that particular phenomenon in another blog, but first, I wanted to touch on how we do scheduling at RadBlue.

At the start of each development cycle, we have a short list of issues that we want to tackle. All of these issues relate to our goal of making our products better for our customers.

Then, we get in the car and start driving.

Going into a development cycle, we know that the journey is never going to be a straight shot. In fact, we know we aren’t going to get to the original destination. Our customers are great at voicing their opinions – on both the current products and on sneak previews of the work in-progress. And all of that input helps steer the car.

Our development process is a fluid one. We are constantly revising the schedule and feature set based on the latest information. Sometimes the input changes our direction by a few degrees. And sometimes the input completely changes our direction. Sometimes we head toward Disneyland, but end up at Disney World.

For a small, agile company like us, this is the best possible way to respond to the needs of our customers. It allows us to focus on what is needed and deliver it in a timely manner.

It’s probably the worst possible way to pilot a family to the ocean. But it’s a great way to build software.

But I am getting ahead of myself.

In 1990 I had a startup software company that I loved. It was called Frontline Software Technology. Now, Frontline was, by just about every conceivable business measure, a sad little enterprise. We were very small, we had a very small venue stream and we mostly got taken advantage of by everybody we dealt with. But that’s not what we were about.

Everyday, when we got up, we thought about our customers. We actually cared what they did with our software, what they thought about our software and what they thought about us. We realized pretty quickly that if even one of them walked away from us, we were doomed. So we bent over backwards, everyday, to keep them.

We added features on a daily basis, we shipped out new versions each day if need be (this was before the Internet), we dialed into their systems to debug problems. We worked with our customers to understand what they were doing when our software let them down. We knew our customers by name, memorized most of their telephone numbers, we knew what they did in their jobs because we talked so often. Each day was exciting because we were in the trenches delivering value to our customers.

And we were happy.

Fast forward nine years. Our little four person startup had morphed into a 150-person behemoth. We had a whole floor in a Chicago high-rise, we had outposts in London and Paris, we had sales reps spanning the globe. We had 40+ programmers, we had 24×7 support, we had three levels of management, we had HR and lawyers and all of that. And, oh yeah, our customers. Our customer base comprised the biggest telecom players in the world, both old and new.

And I was unhappy.

We no longer cared about the customer. They didn’t figure into the equation. Once you had spent your whole day dealing with the beast that was the organization, you had no time or incentive to even think about the customer. We existed because we existed, a perpetual motion machine, a mobius strip of human motivations.

I had started out as a programmer, moved to VP of engineering, went back to programming and then got out to do R&D. But just watching those last two years, as the customer faded further and further away from the daily conversation, became too much. We had gotten so far away from the Frontline days that I couldn’t take it anymore.

So on Thanksgiving, 1999, I exchanged my C++ compiler for an exercise bike and waited for the inevitable hammer that was the end of the dot-com era.

I’ve gone over all of this old ground for a reason. In my next post, I’ll tell you what it took for me to pick up my compiler again, and why I won’t be putting it down anytime soon.

–Marty