This is the essay version of a talk I gave at Jimdo.

Out of Business

Travis CI started out as a small platform for Ruby projects to run their tests on. Back in 2010 and 2011, there was a distinct lack of hosted continuous integration platforms.

It was launched close to the day, three years ago, with a small announcement.

Some Ruby projects quickly adopted it, Rails started officially moving their tests to Travis CI.

Later, in 2011, more language communities discovered the platform. We added official support for PHP, for languages running on the JVM, for Erlang and for Python.

We now also support Perl, Haskell, and anything you'd possibly want to run on a Linux platform. Plus, you can build projects on OS X and for iOS.

Unfinished Business

Initially, Travis CI only supported open source projects. But people and companies kept asking us to use our platform for their private projects as well.

The idea was floated to found a company and turn this into a business, work on Travis CI full time and get paid to do it.

By the end of 2011, a company was founded, and two more people joined the team. We were five people trying to build a business, four of them developers.

In early 2012, we started a crowd-funding campaign to bootstrap our business and allow some folks on the team to be paid for by the company. It allowed us to keep the open source platform running and to improve our feature set.

One of the features coming out of that was pull request testing, which initially was done by having a bot comment on pull requests, annoying the heck out of some people.

We Mean Business

We started working on our product, and we tried to figure out the hardest part about a product, the pricing.

We started thinking about revenue, all the crazy things you have to do when building and running a business.

We launched our product into private beta in July 2012 and started charging in September 2012.

It was all rather hack-ish, and we didn't yet force everyone to sign up for a paid subscription. All the work involved in getting people to sign up was manual. We picked out a few customers and emailed them, encouraging them to sign up and to give us feedback.

Back in Business

This worked surprisingly well and by the end of 2012, we had more than 100 paying customers, allowing us to pay two on our team some sort of wage. Plus, we could pay for our infrastructure.

While that didn't imply a raging success, the signs looked right.

Whilst trying to build up our business, we had to solve scaling puzzles already on our open source platform. This was both blessing and curse.

We were running 7000 builds per day in 2012, compared to 700 in 2011.

In comparison, by the end of 2013, we were running a total of 65000 builds per day.

Solving these issues upfront on the open source would mean we'd know how to solve them when they'd come up on our commercial platform. On the downside, we'd been distracted by these things, rather than being able to focus on the business.

We were able to break Travis CI early on and see the potential affects of any fixes before they'd become critical to our business.

As a challenge to ourselves, there's one special ticket that was opened in early 2013. When our business was in a stable state, we'll be shaving off Sven's mustache.

Business Never Personal

For developers, though, business is tough. Figuring out how much to charge, how to approach customers, how to do customer support (and to understand how important it is), is something entirely new for most.

It posed a big challenge for us, and it took a while to get everyone behind the idea that customer support is essential to our business. When it comes to code, every customers' project is a unique snowflake.

Every project has its own interesting dependencies that can break in the most curious ways. Complex test suites pose challenges for our platform and for our infrastructure.

Solving these can be a tough challenge, but talking to customers about them upfront is what makes them less painful to them.

We spent some time thinking about how we can make Travis CI, how we can surprise our customers. A friend floated the idea of using coffee as an inspiration.

Initially, we wanted to send thank you notes. But we wanted to add an extra twist. A friend suggested we could send out bags of coffees to our customers, combining our passions, and doing something completely unexpected for our customers.

So far, we only shipped some 300 bags, as we had to take a break to tackle some issues, but we intend to pick this idea up again.

Strictly Business

Rather than do strictly business, we wanted to run an open company.

When we have problems that affect our customers and users, we try to be as open as possible about them. They're annoying, but when explained, people do understand that scaling issues can pose unforeseen challenges that aren't easy to solve.

Open operations an unintended marketing channel, if you will. Based on the openness, people can decide whether they want to buy into the fact that we do have outages, that we do have issues, or not.

Marketing is an interesting topic, as we technically didn't do any. None that is directly measurable or where customer growth can be attributed to. Whether that's a good thing or not, I don't know.

The one business-changing thing we did in 2013 was to finally put up a landing page for our product and to actively let people try out our platform and allow them to pay for it.

That's our secret to strictly business.

If you don't give people the opportunity to try out and pay for your product, how and why would they?

Business as Usual

When we finally solved our bigger technical challenges to scale out the platform, we were faced with new challenges: people.

Something every company experiences at some point in its lifetime is to hire people.

We started hiring a few more people in 2013, people working remotely from the start.

We wanted them to feel like they're a part of the team, like their happiness is what's most important to us.

This is a tough challenge, and we have yet to figure it out. I'd say we're doing pretty okay, but there's always room for improvement.

One thing we're trying out currently is support rotation, with everyone on the team involved, no matter their status. The more everyone on the team knows about the product, the more eyes we have on ideas to improve it. The more everyone is exposed to customer issues, the higher the incentive to fix them.

We give people on our team the freedom to do whatever they like, whenever they like. A happy team with a focus on customer value leads to happy customers and a healthy business.

That's our ideal.

At the beginning of 2014, we have 700 paying customers. That may not sound like a lot, but it's close to infinity when you're starting a business from scratch.

We're running a bootstrapped business, we've turned down VC funding multiple times, and proudly so.

Open source is still at the core of our business and our team.

We believe in the power of building good products with people who are passionate about them.

Also, there was this:

Things that have been on my mind lately:

  • Implement lifecycle emails for our product to get new customers more to work with, using

  • How do I best write the copy for these emails?

  • How can I increase customer retention?

  • How can I reduce customer churn?

  • How to get everyone on the team doing customer support?

  • How can we actively approach customers to get more insight into their problems?

  • What kind of better and more insightful content can I produce for this and our company blog?

  • What blogs can I run guest posts on?

  • How can I funnel more visitors from our blog to our product?

  • How can I make sure that everyone on our team is happy?

  • How can I adopt selling bacon as part of our business model?

These are only a few things that keep my brain busy.

So many things in my head, so little time to do all of them.

Life running a small business is never boring.

I'm a newbie, every single day.

Tags: smallbiz

I got to read a lot of great books in 2013, shaping a lot of my current thinking both in terms of business and web operations. If you're looking for something to read, follow along!

Effective Monitoring and Alerting

I've developed an interest in improving our monitoring, and this book delivered some good insight. The book is a quick read, and it ends up delivering a great idea for how a monitoring system could be structured, without going too much into implementation details.

There's a distinct lack of books on this topic, so this one is good to start with.

The Signal and the Noise: Why So Many Predictions Fail — but Some Don't

From the guy who predicted the 2012 election results, a great introduction on statistics, probability, written in an entertaining style (i.e. not boring you with too much math). Gives lots of examples from Nate's personal history of getting into numbers and probabilities. Very entertaining read and will definitely make you think about these topics some more.

The Black Swan: The Impact of the Highly Improbable

Nassim Taleb has an interesting writing style, to say the least. Among slews of bashing other people and polishing his own ego, you'll find streaks of genius.

The Black Swan is a great read on managing risk, or the inability of managing certain risks. If you're running any kind of application in production and are actively involved in operations, this book is a must-read.

The book's point could be made in a significantly shorter version of it, but that would of course deprive you from the joys of reading about Taleb's personal feelings.

The Art of Capacity Planning

This book is a classic, and I only got around to reading it this year, shame on me.

It's wonderfully short and to the point, dealing a lot with monitoring and making your capacity planning work in the best ways possible.

If you haven't read this book yet, start right now. It's timeless for anyone working in web operations.

Friendly Fire: The Accidental Shootdown of U.S. Black Hawks over Northern Iraq

A book describing in great detail the shootdown of two helicopters over the no-fly zone in Iraq in the early nineties.

Why is this relevant and interesting? It's pretty terrible that people have died during this incident.

The fascinating parts of this incident and the book are in what happened in all the parties involved in the incidents and in the organizations as a whole, for years leading up to the event.

This book was an eye-opener for me on how I think about production incidents. It covers in great, great detail the events in a socio-technological organization, the US military.

There's so much to learn in this book that can be applied to web operations.

The Field Guide to Understanding Human Error

Sidney Dekker is a great writer on topics are very relevant to web operations: humans.

Human error is a common excuse for production incidents, all the more so when a plane crashed or other bad things happen.

Dekker puts these things in perspective, and he's helped shape my thinking a lot. What a human does in a particular situation, why he does it and how the organization and the work environment have shaped his understanding of a particular situation.

A great and highly recommended read, goes nicely with Snook's "Friendly Fire."

Managing the Unexpected: Resilient Performance in an Age of Uncertainty

I didn't know what to expect from this book, I bought it on a hunch.

It turns out it's an important read when it comes to managing risk and achieving organizational resilience. Fits in perfectly with the books mentioned just before.

It looks at a slew of different industries and on how they handle risk and risky situations. Fire departments, air travel, and lots more.

It introduces the concept of a high resilience organization and a lot of great ideas, which are picked up by Dekker in a book introduced below.

Thinking in Systems

The book on complex systems and systems theory.

I was amazed, only in hindsight, how important this book is. It introduces the idea of complex systems and how parts in a complex system interact with each other, how they influence each other, how even just small changes in one can have long and delayed effects on others.

The book introduces these concepts in ways not directly related to web operations and software, but you'll notice the relationships right away.

This is the book to read. Read this one first, read it now. The most influential book I've read in 2013.

After reading "Thinking in Systems", you'll see systems and complex interactions between systems everywhere. You know why? Because there are systems everywhere.

Small Giants: Companies That Chose to Be Great Instead of Big

Running a small little business myself, I strive to get as much inspiration and insight on how others running their companies as possible.

This book has been a big inspiration for me. It covers a dozen or so companies that did everything they could to build a balanced workplace with happy employees and a long-lasting legacy rather than go for the big buck or for outside funding.

Lots of great stories in this book. If you're running any kind of business, this is a great read.

The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA

This book is so chock full of insight on behaviors and interactions in socio-technical organization, it kept blewing my mind over and over.

It's about the Challenger incident in 1986, and everything contributing to this incident over years leading up to it.

The level of detail extracted by Diane Vaughan is amazing. She introduces the term "normalization of deviance" in the book, a term that stuck with me, and that I'm now seeing everywhere. It provides a description for something that naturally happens, whether we want it or not, but that seems unavoidable.

Again, this book isn't directly related to software, but it's so very relevant to what we do in web operations. Humans, human interaction, organizations and culture. I found these bits to be the most interesting and fascinating bits when it comes to running anything in production.

If you're curious about these bits too, then this book is for you. Together with "Friendly Fire", it provides amazing insights and learnings for running your own operations team or how to improve human interaction and culture at your company overall.

These books are very relevant to the ideas of DevOps.

Drift Into Failure

Now that you've read "Thinking in Systems", "Managing the Unexpected", "Friendly Fire", and "The Challenger Launch Decision", here comes Dekker putting all of them together, quite literally.

I was quite amazed to find references to all of them in this book.

The books left me wondering a bit on how you can detect normalization of deviance, what you can learn from the Challenger and Iraq incidents, from high-resilience organizations.

This book is Dekker helping you find answers.

Read "Thinking in Systems" first, then "Friendly Fire", "Managing the Unexpected" and "The Challenger Launch Decision", and then read "Drift Into Failure" to find more practical applications of what's been introduced in the other books.

I've had my mind blown several times by all of them. They're pretty amazing eye-openers.

Thinking, Fast and Slow

Just started reading this, but it seems relevant to the topics of biases. Had it on my reading list for a while now, so it's about time to read it.

Will have to report back on this soon.

Free Bonus Reads

If you need more business-related reading, I posted a list of the books that influenced how we run our company over at Travis CI.

Here's to more reading in 2014!

Tags: books