How do you spot a successful business? It’s easiest to think in terms of size: Google, Starbucks, and Berkshire Hathaway are successful.
If you’re a small business and fixate on size alone, you’ll drive yourself crazy. I will never run a Starbucks-scale company, nor do I want to. But do I want a successful company? Definitely!
Here are the two business metrics that matter at Scout:
- Income per employee
- Employee happiness
We started Scout to make monitoring server infrastructure easier. With our heads deep in code, it took us a while to realize that monitoring our business was just as important. Here’s a look at the financial dashboard we created (as you’ll guess, the data isn’t real):
- Activity by Day – This shows signups, cancellations, and subscription changes for the past two weeks.
- Activity by Week – This is similar to the daily activity table but provides a weekly rollup of the data. It adds the projected monthly revenue and revenue change.
- Paying Activity by Month – This rolls up data by month, adding in churn, average revenue per-account, and lifetime value. It also forecasts the next month’s activity.
Most of the freshman engineering students at my college took two computer science courses together. These were the hardest classes I would take during college (my colleague was a TA for these courses so he deserves partial blame).
The experience for Sam Epstein, a friend of mine, was decidedly different. A project that might take me a week to finish (poorly) would take Sam a couple of hours. This was a seminal moment in my life: while I knew there were smarter people than myself, I thought I could out-work my way to the top. In programming this wasn’t the case. I’d never be Sam Epstein. Not only would I not be Sam, I was pretty average compared to my peers.
Nothing helps you sleep better at night like a staging environment that’s faithful to your production setup. That means your staging environment has the same Linux distro, same version of Ruby and gems, the same Apache and Passenger configuration, etc.
VPS not cloud
We’ve found that an inexpensive “always-on” VPS instance is better as a staging environment than a cloud instance we have to spin up and down. Why? Spinning up a cloud instance takes time. We’re more likely to actually use our staging environment if it’s as low-friction as possible to do so.
A staging environment isn’t free—you’ll spend money on the VPS, and you’ll spend time configuring and maintaining it. However, the peace of mind you’ll get is a great return on investment.
Setting up your staging environment
If setting up your staging environment is difficult, you have something to work on: a repeatable process for configuring production-like boxes. Remember, your staging environment should mimic your production environment as closely as possible. If you have a scripted process for setting up production boxes, then setting up your staging environment will be trivial.
If you’re like many organizations, however, there is no authoritative definition for production. Instead, it has evolved over time with manual tweaks and optimizations. In that case, the staging environment is a perfect opportunity to pull together a repeatable script. It doesn’t have to be automated (ours is not)—but it does need to be written down.
Staging deployments with Capistrano
We Rubyists are lucky—there are tools for just about everything. We use capistrano multistage for staging deployments. It’s straightforward to set up, and makes staging deployments completely frictionless.
You should end up with a “staging” file In your
config/deploy directory, but not in your
config/environments directory. You’ll use the your production environment for staging.
The unsolved staging problem: production-like load
The harder part is simulating production-like traffic on your staging server. In a perfect world, you would have holodeck for deployments. We don’t have a solution for this yet—ideas are welcome!
Previously in Developer Happiness
This is Part 4 in our Developer Happiness series. See previous articles:
A friend of mine is brainstorming a business in the dating space. It’s an interesting idea—a spin on the traditional dating service in potentially lucrative niche. My friend asked me about technology—which technology, who to partner with, etc.
My advice for the dating idea was this: forget the technology. Just do the business.
Groupon rejected a $6 billion acquisition offer from Google. They don’t need to cash out.
Our goal isn’t to get acquired. It’s to say “No” as often as possible:
- No, we’re not going to support Windows.
- No, that partnership doesn’t feel right.
- No, we’re not working late.
Saying “No” means your business is healthy. You can focus on the things you really enjoy working on. Why would you sell?
Duel, Steven Spielberg first film, had an estimated budget of $450K. For comparison, the opening scene in Spielberg’s Saving Private Ryan had a budget of $12 million. However, I’m just as happy watching Duel. It’s the only television movie I’m proud to talk about in public.
Spielberg on his early work:
I could never go back and make those early films as well as I made them, when I was of the appropriate age and naivety to be working on subjects like that. But also, l couldn’t have made Schindler’s List or Private Ryan. It’s a fair trade-off.
There’s a lot to learn from Spielberg. Instead of trying to imitate the engineering feats of giants like Google, Apple, and Facebook, smaller companies like us are better off looking for inspiration in things that do a lot with a little.
We can deliver as good of an experience as the blockbuster apps – but it’s going to be in a different way.
 – From an interview on the Duel (Collector’s Edition) DVD
There are no formal documents to sign if you and your spouse decide to have children. You don’t have to sit through an accreditation class. There is no credit check. You don’t need a high school diploma. Procreation can even happen accidentally.
A baby is a lot like a Rails application: the problem is caring for it, not creating it.
Five years ago, the typical Rails stack was just a couple of pieces: Apache/Mongrel, Rails, and MySQL. While Rails is remarkably similar to its original form even today, the stack around it is dramatically more diverse. We’re deploying to automated infrastructures, using NoSQL databases, messaging systems, queuing systems, and more. With the increased complexity of web applications, I’m surprised we’re not seeing companies dedicated to 24/7 infrastructure support: it doesn’t matter where your app is hosted, they manage it.
My left arm is one inch longer than my right. My right foot is a half
inch longer than the left. For me, trying on clothes is an adventure:
what looks good on the rack often doesn’t on me. I thought of this
recently when we decided to end development of a new product.
There wasn’t anything wrong with this product. It worked, looked good
for a BETA release, and wasn’t a support burden. The problem? We
didn’t use it. The
magnitude of not using our product became clear when we compared it to
Scout, our product that we use daily.
I was back in Michigan a few weeks ago visiting family. These trips always involve a “what do you do?” question at some point. I’m never sure how to answer.