Written by: Lawrence Waugh, Founder of Calavista Software®
My company, Calavista Software®, recently turned 21 years old. Turning 21 is a milestone in most people’s lives, involving liberation, celebration, and sometimes even some self-reflection. When I was 21, my entire life was before me. That’s true of most people – according to the Social Security Administration, over 98.6% of Americans survive to celebrate their 21st birthday, and can look forward to another nearly 60 years (on average) to experience life1.
Businesses, on the other hand, have a much rougher go of it. According to JP Morgan Chase, 20% of small businesses fail in their very first year 2. By the 10th year, more than 2/3 are gone, and not even 1 in 5 see their 21st anniversary. I spent a lot of time looking forward when I turned 21, and don’t get me wrong – as Calavista turns 21, I‘m busy planning our future. But I also can’t help but spend a little time looking backwards, contemplating why we’ve been able to endure when so many others haven’t. What lessons have 20 years and 2 Recessions taught us along the way? What things do I wish I’d known earlier, and that could maybe help other companies as they navigate their early years?
It turns out there are a lot – far too many, actually, to cover in a single blog. So, this will have to be the first in a series of posts – a preview of sorts, where I talk about “things to come.” Some of them may be interesting, others not so much. But hopefully someone out there can get some value from some hard lessons we I’ve learned over the years.
History
It may help to know a bit about Calavista’s story before we begin, to see if any of it resonates. We started life in the rubble of another company immediately after 9/11. I was the VP of Engineering at a small software company that was working on a product much like LinkedIn – before that existed. I had become laser-focused on how to write software faster, with higher quality. The team and I had come up with some interesting tricks and tools. We evolved the concept that rather than go through endless “Develop, then Test, then fix, then Test, then fix…” cycles, code just needed to be shippable all the time – essentially, what later became the core principles of Continuous Delivery.
We’d written some tools to facilitate this model (automating builds, enforcing regression testing, etc.) and we were making huge strides in our productivity. Then the 9/11 attacks came, and our company needed to furlough us all while they arranged their next funding round. Rather than scatter to the winds, and then try to get the band back together, we decided to stay together and use these principles to go write code for other companies for a month or two, until the funding came in.
But it never did. And Calavista found itself alone with nothing but some smart people and what we thought was a better way of writing code.
Pioneering CI and CD
So that’s what we did: we used our tools and methodologies to work on projects for other companies, scraping for whatever work we could find. After a while, people started asking us if they could just buy our tools, so we took some time to productize them, and re-launched ourselves as a software and services company. We actually got a few patents awarded on the core aspects of Continuous Delivery.
We still used our tools to write code, but we also sold those tools. The problem was this was before even things like Continuous Integration were in vogue. We’d show up at a prospect and try to convince them that they should stop letting developers just write code however they wanted and adopt more a more rigorous and accountable process. It usually didn’t go well. After all, who were we to be talking to Fortune 500 companies about how they wrote software? We sold our software tools to some visionaries, but it was a painfully slow process, and eventually we gave up and just re-focused on using those tools and methodologies to write software for others.
Ultimately, the market embraced the concepts, so lately when we talk about how we write software, it resonates with most people, and we rarely have to explain the whys of what we do. And though I still miss our own tools (there were things they did that no one else does, even 20 years later) – it did give us the ability to move off of our own software onto commercial frameworks, which let us concentrate more on our own delivery. Now we’re just one of many companies that focus on process and DevSecOps (I’d like to think one of the best…) – but that certainly wasn’t always the case. It’s been a long road.
21 Years of Experience
So that’s who we are and where we came from. And now getting down to it: what have I learned – especially what have I learned that might be useful to others?
Given our business, there’s obviously a ton I’ve learned about running software projects. But those things are the subject of a lot of other posts and are really only relevant to software companies, so I’m not going to talk about any of that. Focusing on business in general, I’d say the things I’ve learned the hard way have fallen into several broad categories:
- Building a Company – founders, formation, and the first hires
- Sales and Marketing as a young company – what do you need, and who does it?
- Finding your Product – it might not be what you think
- Customers – the good, the bad, and the ugly
- Offshoring – then and now
- Working with partners – who do you want in the foxhole with you?
- Creating a company that can survive a crisis – it’s going to happen…
We haven’t reached the Exit point yet, so that will have to come later :).
If any of that’s interesting, stay tuned. And I’d love your feedback – feel free to drop me a line if you have any.
– Lawrence Waugh
