In the right dose, ambition works wonders. It inspires you to achieve more, to stretch yourself beyond the comfort zone, and provides the motivation to keep going when the going gets tough. Rightfully so, ambition is universally revered.

But ambition also has a dark, addictive side that’s rarely talked about.

I just finished 2nd in the ultra-competitive LMP2 category of the greatest motor race in the world: 24 hours of Le Mans. That’s a monumental achievement by almost any standards, yet also one of the least enjoyable experiences I’ve had driving a race car — all because of ambition.

Armed with the fastest and most reliable car, the best-prepared team, and two of the fastest team mates in the business, it simply wasn’t possible to enter the race with anything less than the top step of the podium in mind. Add to that leading much of the race, and a storming comeback to first position after my mistake, it compounded to an all-out focus on the win and nothing but.

That’s exactly the danger of what too much ambition can do: Narrow the range of acceptable outcomes to the ridiculous, and then make anything less seem like utter failure. It’s irrational, but so are most forms of psychological addiction. You can’t break the spell merely by throwing logic at it.

There’s not a graceful way to process this “loss”. Society generally only accepts the notion of “overly ambitious” when there’s a demonstrably large gap between perceived ability and desired outcome. In those cases, though, it’s much easier to shake off reaching for the stars and failing. That’s expected.

But when the ambition is cranked up to the max due to prior accomplishments and success, it can easily provide only pressure and anxiety. When that’s the case, winning isn’t even nearly as sweet as the loss is bitter. When you expect to win, it’s merely a checked box if you do — after the initial rush of glory dies down.

Over-dosing on ambition isn’t just an occupational hazard of sports. It goes for all walks of life. I’ve met many extremely accomplished people who’ve had the grave misfortune of reaching one too many of their goals, only to be saddled with an impossibly high baseline for success. It’s devoured their intrinsic motivation, leaving nothing but an increasingly impossible search for another fix of blow-it-out-the-park success. When that doesn’t happen, the withdrawal is a bitch.

This experience has been a painful realization of everything that Alfie Kohn wrote about in Punished by Rewards and a reminder of the wisdom of Mihaly Csikszentmihalyi’s Flow. Happiness doesn’t lie in the fulfillment of the expected. Neither in all the trinkets and trophies of the world. It’s in enjoying the immersion of the process, not the final outcome.

The New York Times has a fascinating interview about using Big Data to guide hiring and management techniques with Google’s VP of people operations, Lazlo Bock. Two things in particular stood out.

First, “On the hiring side, we found that brainteasers are a complete waste of time”. I couldn’t agree more.

Second, “One of the things we’ve seen from all our data crunching is that G.P.A.’s are worthless as a criteria for hiring, and test scores are worthless”. This ties in well with rejecting the top-tier school pedigree nonsense and downplaying the benefit of formal education altogether. On the last point, Lazlo notes: “What’s interesting is the proportion of people without any college education at Google has increased over time as well”.

But beyond that, the interview is full of good tips on management as well. Especially around figuring out who’s a good manager and how they can improve. If that’s a subject you’re interested in, checkout our newly launched Know Your Company.

About two years ago, The Starter League set out to teach absolute beginners how to code. Since then, they’ve expanded their offerings to include HTML, CSS, and design.

To date they’ve graduated over 600 students from all over the world. A true success story on so many levels.

One thing they’ve noticed along the way is that their best students return back to take additional classes in different disciplines. They may start learning Rails, but then they want to learn advanced HTML/CSS. And then they want to learn visual design.

Further, these students seem to want more than just the independent skills – they want the whole integrated package. They want to know how to build a product and turn that product into a sustainable company.

Announcing Starter School: A truly unique program

So today The Starter League announces their newest — and most ambitious — initiative: Starter School.

Starter School is an intense, full-time, 9 month program. It’s basically the grad school for people who want to learn how to build software and start companies. It’s small and hands on: there are only slots for 52 students. This way every student can get the attention they deserve.

They’ve lined up an outstanding roster of teachers, and put together a thorough, full-time, 9-month program where you’ll learn everything you need to know to build the back-end, design the front end, and bring your product to market. It’s the most well-rounded curriculum I’ve seen yet.

A few folks from 37signals will be teaching. Ryan Singer will be teaching product design. Mig Reyes will be teaching visual design. I’ll be dropping in to teach a few things, too.

Tuition for the 9 month program is $36,000. The inaugural class will get $3000 off. To help, I’ll also be providing partial scholarships for three highly motivated, sharp students. Other scholarships will be available too. Details will be provided after you submit an application.

If you want to learn the whole stack – programming, design, and business – from some of the best, don’t delay. This is a one-of-a-kind program. Apply to Starter School today or just find out more.

Disclosure: 37signals is an investor in The Starter League.

Today our first five customers started using Know Your Company, our newest product. We’re hoping to roll out around five new customers every Monday for the foreseeable future.

I thought this was a great time to talk a bit about how we’re building Know Your Company. Not the tech, specifically, but the approach.

From the start, I wanted to approach the development of Know Your Company as if we were starting a separate company inside 37signals, not just building another product at 37signals.

So I went back to 2003. That’s when we originally built Basecamp. Basecamp was basically a new business inside 37signals. I looked back at how we did it.

We had a small team of four – two designers (me and Ryan), one programmer (David), and one person who could help with a variety of things (Matt). We were building something to scratch our own specific itch.

We didn’t have much tech to lean on. We didn’t have Rails, we didn’t have a centralized billing system, we didn’t have a centralized log-in system, we didn’t have much experience launching a product with a new business model (subscription pricing), we didn’t have a server farm (we just had a shared server slice on another company’s machine), etc.

Basically, a lot was very new to us, and the newness was invigorating. It allowed us to approach problems objectively rather than fitting our problems into solutions we’d already built before. Think of it more as a bespoke suit than something off the rack.

Basecamp was a bespoke suit, but just about everything we’ve done since then has been trying to fit into Basecamp’s clothes in one way or another.

I wanted to get away from that way of thinking with Know Your Company. It’s just too easy to continue to lean on the things you’ve done, the decisions you’ve made, and the infrastructure you’ve already built.

So here’s what we’re doing.

We’re starting with a small team of four. Me and Jonas on design. Trevor on programming. And Dan as the multipurpose jack-of-all-trades. I’m also doing sales/demos, which is something we’ve never really done before.

Further, just like when we launched Basecamp, I did all the customer support for the first year or so. That’s what I’ll be doing with Know Your Company too.

As for billing, we’re not using Queenbee, our centralized billing system that powers Basecamp, Highrise, Backpack, Campfire, and a variety of other things we sell. Instead, we’re building a bespoke billing system from scratch. Just what we need, nothing we don’t.

This way we don’t have to compromise a business model approach because our billing system is only set up to do things one way. If we have a different idea for how we want to bill customers (or accept payments), I don’t want to be hamstrung by old decisions. I want to have the freedom to make new decisions.

Queenbee also has a bunch of admin tools built in so we could comp accounts, change ownership of an account, look up a customer and update their information, etc. We’ve left that all behind with Know Your Company. Know Your Company has its own custom admin built right into the product. This way we can build specific admin tools to onboard new customers, update accounts, generate invoices, and everything else that’s unique to Know Your Company.

Another thing we’re doing differently this time around is sales and setup. Our default position when building new products is to make them self-service, just like Basecamp’s been since day one. No interaction with us is required to sign up. Just click a button, pick a plan, sign up, and you’re off and running.

That model has obviously been very successful for us. No question about that. But let’s learn something new. Let’s get a feel for what the opposite approach is like. What if we were full-service instead of self-service? What if we were very hands-on, rather than completely hands-off?

So that’s what we’re doing with Know Your Company. There’s no self-service sign-up. If you want to use Know Your Company, we have to give you a personal demo first. Want to sign up? We’ll walk you through it step-by-step. We’ll even load up your employees for you so you don’t have to do any work. And we’ll also populate your account with a specific set of questions so you don’t have to think about what to ask your employees if you aren’t sure what to ask.

Isn’t full-service harder, more time consuming? Yes it is. And wow it’s been worth it. I’m getting to have a nice conversation with every customer we have. I’m getting to learn a lot about their companies, their struggles, and their goals. This is very healthy for us. The product is going to be way better for it – especially in the long-term.

The business model is all new, too. Instead of defaulting to our Basecamp-famous monthly subscription fee, we’re treating Know Your Company more as a one-time investment in each employee rather than an ongoing recurring expense. So instead of charging a monthly/annual fee, we’re just charging $100 per employee one-time. Once you’ve paid $100 for an employee, you never have to pay for them again. You can use Know Your Company with them for as long as they work for you.

Now, we’re not entirely free from the past. There are still a few things we’re leaning on because they aren’t hampering our flexibility.

For one, we’re using 37id – our centralized sign-in system. Know Your Company customers can sign in with the same username/password they use for their Basecamp accounts. That’s easier for them than having to sign up with another username/password.

We’re also using Rails, which we didn’t have the luxury to use when we built Basecamp. And we’re leaning on our sophisticated server infrastructure and the things we’ve learned about email, too. But the load we’re putting on the system is barely a pimple so I don’t feel so bad about that.

And of course we have the reputation and trust build up behind 37signals over the last 14 years.

But as far as our development approach goes, this feels the closest to the feeling we had when we were building Basecamp nearly 10 years ago. Lots of new things, lots of new approaches, a feeling that we can build whatever we need rather than fitting new ideas into old decisions.

If you’re interested in becoming a customer, please review the introduction letter I wrote. If it resonates with you, and you fit the profile, drop me an email and I’d love to show you around and maybe even get you started.

As we watched Apple unveil iOS7, the 37signals Campfire room quickly turned to awe of what they had achieved. A redesign so shocking and deep bestowed upon a product so popular left many mouths agape. Whether you happened to like the final product wasn’t as relevant as marveling at the vision, drive, and sheer determination to pull it off.

Apple has a way of making people feel like that.

But what followed next is at least as interesting: We all sought to explain just how they did it. Is it all Ive’s eye? Is it that they explore more ideas than anyone else? Is it never accepting “good enough”? Forgoing customer input and trusting their own instinct? Hundreds of triple-A designers and developers?

There were lots of suggestions. But stepping back a meter or two, it was clear that we all simply reached for our own grandest ambitions and rebranded them Apple’s secret sauce. Theorizing why Apple is able to do what it does is an organizational Rorschach.

That doesn’t make it a useless exercise. Au contraire. It just makes it more about you than them. It lets you tease out your goals and aspirations for your own work and process. It’s a kick in the ass to marvel at greatness and think of reasons “why are we not as awesome as that?”.

An organization as rich and storied as Apple has a thousand reasons for why it got to where it is. Pinning it on any one answer is futile, but it’s sure to spark a healthy debate. Indulge.

Rails ships with a default configuration for the three most common environments that all applications need: test, development, and production. That’s a great start, and for smaller apps, probably enough too. But for Basecamp, we have another three:

• Beta: For testing feature branches on real production data. We often run feature branches on one of our five beta servers for weeks at the time to evaluate them while placing the finishing touches. By running the beta environment against the production database, we get to use the feature as part of our own daily use of Basecamp. That’s the only reliable way to determine if something is genuinely useful in the long term, not just cool in the short term.
• Staging: This environment runs virtually identical to production, but on a backup of the production database. This is where we test features that require database migrations and time those migrations against real data sizes, so we know how to roll them out once ready to go.
• Rollout: When a feature is ready to go live, we first launch it to 10% of all Basecamp accounts in the rollout environment. This will catch any issues with production data from other accounts than our own without subjecting the whole customer base to a bug.

These environments all get a file in config/environments/ and they’re all based off the production defaults.

Continued…

For a long time I’ve felt like the only thing worth working on is the next most important thing. Why spend time working on something that’s less important if there’s something more important that needs work?

I’ve changed my mind on this. I think it’s always good to be working on two things: The next most important thing, and the next most interesting thing.

It’s hard for an interesting thing to compete for your attention if your only criteria for attention is criticality. Interesting things are rarely critical. They’re exploratory. And if you only think in terms of what absolutely needs your attention right now, you’ll never leave room for things that might satisfy your curiosity. That’s important too, just on a different level.

It’s in this spirit that I hope we have the courage to be more experimental at 37signals. Experimental design, experimental tech, experimental business models, experimental strategies, experimental experiments that may lead to brand new insights and outcomes we didn’t know we were capable of before.

I’m looking forward to the surprises.

The latest Basecamp for iPhone release involved an immense amount of refactoring with how HTTP requests and HTML pages were rendered. In a previous release, my coworker Sam wrote several methods that didn’t serve to reduce duplication, but instead their purpose was to increase clarity. Since the focus is on comprehension rather than just reusability, it’s easier to understand what is going on and jump in to solve the next problem.

This pattern has been eye-opening, and I’ve been using it to hide implementation details and remove comments explaining what chunks of code are doing. Instead, the name of the method explains what is going on. The gist here to communicate Intention Not Algorithm:

Continued…