Lessons from Rework

by Neville Samuell

 I've been doing a fair bit of business travel lately which has inadvertently led to me doing more reading. One of the books I picked up was Rework by Jason Fried and David Heinemeier Hansson. As a long time Ruby on Rails enthusiast and frequent listener of This Week In Startups, I've followed DHH for some time and have always enjoyed his particular take on things.

The book itself is poignant, unique, and a little bit arrogant (of course). It's a collection of essays on a variety of topics and is fairly short; I flew through it over the course of a couple short-haul flights.  I'm not usually one to re-read books, but I've been going back to it more and more lately to review some of my favourite essays.

 

Workaholism

Our culture celebrates the idea of the workaholic. We hear about people burning the midnight oil. They pull all-nighters and sleep at the office. It's considered a badge of honor to kill yourself over a project. No amount of work is too much work.
Not only is this workaholism unnecessary, it's stupid. Working more doesn't mean you care more or get more done. It just means you work more.

This one stood out to me because I think I've always been guilty of this. I've been known to spend hours at the office working on projects, long after the lights have been turned off and the cleaning crew have come around. At the time, I probably felt like I was doing everyone a favour, but looking back now I think Rework is right. I may have helped the project get back on schedule, but by brute forcing the problem I likely created less than optimal solutions. It's something to think about the next time you're throwing fistfuls of late night hours at a project: are you working like this because it's the right thing to do, or because you are trying to be a hero? In some of these cases, I still think it's absolutely justified and the right decision, but I think it has to be something that everyone decides to do; at that point, it's no longer one workaholic blazing ahead, it's a full team sprint to the finish line. In any case, this is something you have to be conscious of and keep under control.

 

Build half a product, not a half-assed product

You can turn a bunch of great ideas into a crappy product real fast by trying to do them all at once... So sacrifice some of your darlings for the greater good. Cut your ambition in half. You're better off with a kick-ass half than a half-assed whole.

This essay is interesting because it doesn't try to validate itself much, the authors expect you to just accept this as fact. I think everyone generally agrees with this advice, but history shows us that people still seem to prefer to "ship more" instead of "polish less". I think it's something you really need to constantly remind yourself of, maybe by framing it on the wall or wearing it on a shirt. I particularly like the wording here, which I will shamelessly quote for years to come to (try and) win arguments about cutting features.

 

Meetings are Toxic

  "Meetings are toxic". Yeah, the illustrations are pretty great, too.

 "Meetings are toxic". Yeah, the illustrations are pretty great, too.

There's some uniquely painful about meetings, isn't there. People experience an certain brand of cognitive dissonance when it comes to meetings: usually, everyone enjoys complains about them ("If I could just get out of all these meetings I could get some work done..."), but at the same time continue calling them at every opportunity ("We should update the team on this, can you go ahead and book a meeting?"). What is that about?

Rework does a good job at highlighting the structural problems with meetings and the underestimated cost they have on productivity. I think that part of the problem comes from a cultural belief that meeting are the only way to "officially" accomplish something, like a decision, an update, etc. But that should mean there's also an opportunity to challenge "meeting culture" by offering a less intrusive alternative and building a culture to support it. Something like a "decision room" on your company chat server could potentially scratch some of the same itches.

 

Reasons to quit

It's easy to put your head down and just work on what you think  needs to be done. It's a lot harder to pull your head up and ask why...
Why are you doing this?  What problem are you solving? Is this actually useful? Are you adding value? Will this change behavior? Is there an easier way? What could you be doing instead? Is it really worth it?

This one plays back into the workaholic idea. There always seems to be lots of reasons to keep going, like "I've already finished most of it", or "This should be really cool when it's finished", but it's important to remember these reasons to quit. There's nothing wrong with throwing out a day's worth of code when you realize that the feature won't end up adding value, so don't keep chasing after something that really wasn't worth doing in the first place. Poker players know how to calculate pot odds to prevent over-investing in a marginal hand; businesses can do the same thing.

 

These are just a few of my favourites. I don't think there's anything completely mind-blowing in there, but the authors do such an excellent job of enumerating a hit-list of topics to focus on that I know I'll be picking it up over and over again.