Our Thinking

Get Reworked

Posted by Dave Gillies on May 14, 2012 3:47:53 PM

In its dust jacket, it claims to show you a better, easier way to succeed in business. Rework (http://www.amazon.ca/Rework-Jason-Fried/dp/0307463745/ref=sr_1_1?ie=UTF8&qid=1336313211&sr=8-1), a New York Times Bestseller book by Jason Fried and David Heinemeier Hansson, explains that to succeed in business you must stop talking and start working – and promises to show you the way. A tall order, but it is backed by the success of the authors with their revered 37signals (http://37signals.com/) suite of collaborative productivity tools and their popular blog, Signal vs. Noise (http://37signals.com/svn).

I love this book for its no-nonsense, pull-no-punches messages. I recently reread it and thought I could write about some gems that I think apply well to technology and consulting. Here are four that I can relate to.

Embrace Constraints

"I don't have enough time/money/people/experience."

I know, I know, these words never come up on your projects. The authors suggest that less is a good thing. They say that constraints are actually advantages and that limited resources force out the waste and encourage creativity. As a consultant I live in this reality most of the time, with pressures to deliver a system or a plan sooner, to do it with a smaller team, or with cheaper hardware or software. On a recent engagement, the team shifted to two-day sprints in an effort to go through five analysis, design, develop, test cycles in just two weeks. We all thought it was a little bit crazy, but I would argue that the results were of higher quality than had we spent twice as long and allowed the feature set to bloat. In my experience, constraints are real, but with the right attitude and leadership, they can be motivating.

Illusions of Agreement

"The problem with reports and documents is that they create illusions of agreement. One hundred people can read the same words, but in their heads, they're imagining a hundred different things."

I've been lucky to have a career in technology with variety, but I've filled a developer role the most. Where this hits home for me is when building a system based on Use Cases provided by an analyst. Analysts, go easy on me, I've filled that role too, I know how frustrating it can be when some hapless developer builds a bungalow rather than the Taj Mahal that was imagined. The authors suggest that it is prudent to remove abstraction as much as possible. In my experience, if one can build a mockup, a prototype, or a proof of concept, one can build consensus and discover misunderstanding much faster than words, tables or flowcharts can. At the very least, team members should imagine ways to come to real consensus and never be afraid to say "I don't understand. Show me again."

Your Estimates Suck

"Estimates that stretch weeks, months, and years into the future are fantasies. The truth is you just don't know what's going to happen that far in advance."

My belief is that this statement is a bit too bold. On projects I've been on, the trend is that if you don't know what's happening at least a few weeks out without at least some amount of certainty, you are probably destined for failure; it is said "a failure to plan is a plan to fail." Still, the sentiment rings true. We almost always think about best case scenarios and we don't know what we can't know. I have heard it described as a "lost keys" scenario: You get up in the morning, ready to head to work, but you can't find your keys; imagine your Project Manager asking you how long it will take you to find them. Still, without estimates, planning any kind of deliverables involving a contract is unimaginable, and I wouldn't hire a contractor to build my new garage who couldn't give me an estimate. The solution is to estimate in the smallest chunks you possibly can. You're still going to be wrong, but you'll find out sooner, adjust sooner, and be able to communicate in terms that all parties can understand. The impact will be far easier to absorb.

Four Letter Words

"There are four letter words you should never use in business… need, must, can't, easy, just, only, and fast."

The authors argue that these words create a black or white situation and should therefore be avoided. 

I enjoy this because consulting is often about compromise. I have worked on more than one project where we had taken over after one or more failed attempts. In each case, I believe our team was able to succeed because we avoided four letter words and asked "Can we get away with...", "Which is more important?", "What's the best result?", or "What else can we try?" From another angle, I've definitely made the mistake of uttering "easy" and "fast," and my project managers and teams will tell you it was often anything but. I've learned this lesson. Be flexible and resourceful. Look for the grey in any tough spots. Oh, and you probably shouldn't use the other four letter words either. 

In tone, Rework doesn't take itself too seriously, and you won't find anything revolutionary. But if you think on its points and relate them to work you've done or are doing, I'm sure you'll pick up some quick wins.

 

Topics: Professional Effectiveness

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts