I really enjoyed reading It Doesn’t Have to Be Crazy at Work recently. It’s another bestseller from Basecamp. After reading Rework before, a lot of things felt a bit familiar. Too familiar, perhaps. But their new book still has a few new ideas and covers things from a different angle. Well worth a read.
Working remotely, and at a company with very similar culture and values to Basecamp, a lot of what they write about resonated. Much of the way we structure things at work was inspired or wholesale copied from Basecamp to be completely honest. Why reinvent the wheel when someone hands you an instruction manual for building a perfect one?
But some things caught me by surprise. It felt a little too zen, or even contradictory in some cases? But it definitely gave me pause. Maybe we’re doing some things wrong, and can improve even further? I’m still unsure, but hope we can experiment with some ideas. Let me jump into a few examples…
6-Week cycles
David and Jason make a pretty compelling case for organizing their work into 6-week cycles (with a 2-week cool-down period in-between). We also found that organizing our work this way does wonders. We are more focused, but not rushed. We are better prepared for the challenges before even starting (using pitches, another great idea). And we probably avoid the biggest mistake of all: starting working on something that doesn’t matter, or matters less.
Not all our work fits neatly into 6-week projects however. Some work is more ongoing, repetitive, or influenced by outside factors.
Customer support might be such an example. Or let’s take A/B testing as another, since it’s something close to my heart. For those not familiar with it, it’s the process of evaluating two variations one against the other. Think two different pages on a website, with different copy, visuals, etc, and measuring which variation works better — let’s say, get more users to sign up. The nature of those tests is that they take a bit of time to plan and execute, and a potentially much longer time just waiting for the data to come in. To detect a difference with statistical significance requires time even on busy sites.
So it’s really hard to fit A/B testing into 6-week cycles. There could be a number of tests running in parallel on different pages, and each test can be in a different phase. So we structure this work as an ongoing “team”, rather than broken down into project cycles.
Which brings me to the next point, Goals.
Goals
The authors make a pretty convincing case for why goals are meaningless. And by and large I couldn’t agree more. Especially when it comes to those long-term goals. It’s virtually impossible to make predictions with any degree of accuracy. But only having 6-week goals is also too limiting.
If we go back to our example of A/B testing: work is ongoing rather than split into 6 weeks cycles. But it doesn’t mean we shouldn’t have goals. And those goals can be quite simple. We found that introducing quarterly goals for teams like A/B testing actually works wonders. The goals are very simple. We basically sit down once a quarter, and look at our backlog of ideas for A/B testing, and then decide which tests we are likely to achieve during the next quarter. Those goals are really helpful keeping us focused and on track.
Dunno where you are
Here’s a quote from “The presence prison” chapter that sums the author’s point wonderfully
As a general rule, nobody at Basecamp really knows where anyone else is at any given moment. Are they working? Dunno. Are they taking a break? Dunno. Are they at lunch? Dunno. Are they picking up their kid from school? Dunno. Don’t care.
It’s a very powerful idea. And if I could work this way, having this level of complete freedom, it would be pretty awesome. But people (and companies) rely on collaboration for a lot of tasks. So whilst I can hugely benefit from writing code uninterrupted for a number of hours. Once I’m finished, I would benefit just as much — or even more — if my colleague reviews my code. Or if the copy I needed to tweak is adjusted.
I totally understand the asymmetry of asking for answers and giving them, and agree that it should be minimized to reduce interruption. “protecting the time and attention” is the phrase they use and it makes total sense.
But how do 6-week projects run when people need to work together and keep things in-sync? can projects function well completely asynchronously and with no interruptions? I know from my own experience that I often get blocked waiting for feedback. I’m not in a rush, and with some degree of planning, I can work around those delays. But it still feels like it’s blocking me.
The book suggests one mechanism called “Office hours”. People publish times when they are available to answer questions. This definitely helps, but I’m not sure how it helps if Jasmin’s office hours are Thu afternoon, and if my project depends on her input on Monday morning…
I wonder if this level of freedom is attainable in most businesses. I really want to find mechanisms to make it so, but it feels a little too unrealistic to me right now.
Another curious thought I have is this: If Jason (Basecamp’s CEO) asks Jasmin something on Monday, would she really wait until Thu to respond? or would Jason really wait until Thursday? from my personal experience people are still quick to ask, and the pressure to answer still exists, especially when it comes to “higher-ups” (even in a very small organization). So what’s the trick??
Holidays
The book makes a very good case for letting people take proper holidays and relax, to give everyone a chance to disconnect. And they’re quite generous with their holiday policy. There are a few things that we do differently however, and I think they work better for us. At my workplace, each person gets 45 days of holiday per year. It sounds like a lot, and it probably is, but those days include public holidays however. We figured that each country has different public holidays, and accounting for all of them was virtually impossible. Furthermore, each person can decide whether they work or take the day off on public holidays as well.
A few things I wasn’t sure about though with Basecamp’s approach:
- Not tracking holidays – this sounds like a grown-up thing to do, and it makes sense. But also not entirely fair or helpful. How do I know if I took more (or less) than I ought to? It’s hard for me to keep track of it and remember. And it won’t be fair on others if I take more holidays. We also try to encourage people to take holidays, and we can do it better if we track them. Some people need more pushing than others. Yes, believe it or not, people aren’t always taking the holidays they deserve. So tracking isn’t always evil in my opinion.
- 4-day weeks over summer – Basecamp switches to 4-day weeks over summer. It sounds awesome, but breaks on a few levels. First of all, not everyone’s summer is the same… Hey Australia! The other problem is that it’s a forced holiday. I’d rather keep my holidays to travel to SE Asia for a long stretch rather than sprinkle holidays. So I’d rather work 5-day weeks over summer.
- What happens around Christmas? – this time of year, almost everyone’s on holiday. It’s a great time to spend with family. But who keeps the lights on? and what about those who want to work during this time? (I don’t celebrate Christmas). So technically it’s not a problem, but practically we have to juggle partly-available teams or projects, and scheduling tasks to fit the holiday schedule. It’s not much different from other businesses I guess, but I still wonder how Basecamp manages those 6-week projects during the holiday season
I don’t think any of those questions or problems are fundamental, but still something that made me ponder.
Priced to lose
This was a big eye-opener for me and I truly admire Basecamp for doing this. They essentially eliminated user-based pricing and stuck with a per-account pricing, for all their accounts. This means that if a company has 5,000 employees, they pay Basecamp the same as a company with 5 employees. And the genius part of it, is that it gives Basecamp the power to choose features, etc. The big fish clients don’t influence their decision more than the small ones. This is awesome.
There are two questions I have about it however:
- Can small companies afford this? – if you’re a small company with a limited number of clients, it seems dangerous to price your product with a one-price-fits-all. Imagine supporting 5,000 employees who pay you the same as 5. If every employee has only 1 support question per year, that’s 5,000 support tickets… same goes for server load, traffic, data storage etc
- Is this the full story? perhaps I’m cynical, but I would imagine that Basecamp’s primary audience is small businesses. Perhaps some medium ones, but is there really a 12,000 person company all using Basecamp for $99/mo? Or maybe it works because the average company using Basecamp is actually 5 people or less?
In any case, hats-off to Basecamp for doing this. I really admire the simplicity of a single price plan. I think it takes a certain mass to be able to pull this off though. Otherwise, you’re leaving money on the table, and when you’re small, every cent counts.
Closing thoughts
There’s lots to admire and learn from Basecamp. Especially if you’re a small company selling your services online. And I greatly appreciate the fact that they share their recipes openly with the world. If you haven’t read their books, then I recommend doing it sooner rather than later. If you have any answers or suggestions to my questions, I’d love to hear them.
