The truth about doing less. (First you have to do more.)
Jason Fried at Gel 2006 from Gel Conference on Vimeo.
Easy for you to say…
I’ve been working on this blog post all morning. I thought this post would be simple. Most of the information management challenges plaguing the architects and engineers we work with can be simplified by doing less. All I should have to do is write about what we see and do every day.
Here are three examples :
- A user-friendly intranet? Do less. Less content actually makes an intranet easier to use.
- A project history database? Do less. Less fields to maintain mean that the important fields will actually get captured.
- An expertise database? Do less. Nobody cares if a team member has Microsoft Word expertise. Focus on the skills such as space planning, water-proofing, or feasibility studies that your staff can really leverage in their project work.
So why has this post been so tough to write? Because I felt like I sounded too much like this guy:
Some free advice on how to do less.
Imagine that you’ve finally decided to move from a network-based image library towards a database-driven solution. You’ve never implemented one of these systems before. You decide to start asking around for advice on a successful implementation. I’m one of the people you ask. Guess what my advice would be?
Chris: “Do less.”
You ask me to elaborate.
Chris: “Start by going after the most important projects. You don’t need to chase down images for every project your firm has ever done. For example, seismic upgrades or executive bathroom remodels can probably wait until round two, or three, or never.”
You thank me for my advice. I’m not done.
Chris: “I’d also limit your scope on the number of images you try to harvest from your teams. You should focus on the images that will help you tell the project story now and in three, five, ten years down the road. Focus on the images that endure, not every version of every rendering or site photo that your team took during the project.”
That’s helpful you think. Less projects and less images. Focus on the stuff that matters. You thank me again for my advice.
(I’m still not done.)
Chris: “I saved the most important advice for last. Limit your image keywords to 20 to 30. Your users are going to howl at first. They are going to come with lists and lists of keywords which they “must have” if the system is going to work for them. Their combined lists could easily top 250 keywords. This is fine. This is beginning of the process. Your work, and your team’s work, is to eliminate the fat. A system with 250 keywords won’t get populated and will be difficult to use. Fight for 25 keywords at launch. Stare them down. Play chicken. Do not bend.”
Now you have what I think is the best advice possible on implementing an image management system. I’ve seen it work firsthand with many of our customers and followed the same approach when I was a CIO.
Scope ruthlessly. Design more. Do less.
Here’s the thing – doing less is more difficult than doing more and requires more upfront work. Doing less requires more thinking and more prototypes than doing more. Doing less requires more political savvy than doing more.
You could take the easy way out. For example:
- The easy way to implement an image management solution would be to placate your users and just add more keywords.
- The easy way to design an intranet would be to let your users go nuts and upload whatever they want and design their own pages.
- The easy way for Jason Fried and his software company 37Signals to please their customers would be to implement every feature that his customers ask for.
Each of the three approaches above will end up in solutions that are complex. Complex solutions are expensive to maintain, difficult to support, and horrible to use.
Doing less requires more work in the short run but leads to simple, sustainable, usable solutions in the long run.
Somehow “Scope ruthlessly. Design more. Do Less.” doesn’t have the same ring as “Do Less.” But I think that it’s the complete truth.


Leave a Reply