Over the weekend I finished Rework and figured I’d share some quotes from it as well. This book was excellent and the perfect complimentary read to Linchpin. There was a lot of overlap and similar concepts. While Linchpin was more psychology, Rework gets a little more practical and specific in it’s advice. Now, onto the quotes..
“Another common misconception: You need to learn from your mistakes/ What do you really learn from mistakes? You might learn what not to do again…You still don’t know what you should do next.”
They go onto to talk about how the best learning comes from success. This, IMO, is like choosing to build your product based on it’s strengths and not it’s weaknesses. If you’ve done something well then chances are you can do it even better the next time because you will have learned from the success.
“We’re just as proud about what we don’t do as we are of what they do… We’re willing to lose some customers if it means that others love our products intensely… if you had to launch your business in two weeks, what would you cut”
Just a reminder of the classic advice that you can’t make everyone happy. I also loved the discussion that follows about how the are OK when customers outgrow their software.
“The business world is littered with dead documents that do nothing but waste people’s time, reports that no one reads, diagrams that no one looks at, and specs that never resemble the finished product. These things take forever to make, but only seconds to forget.”
I can’t tell you how many times I’ve seen a 60 page specification written when only 10 pages of the functionality are implemented. It’s so much easier to say yes when you are months away from doing something than it is when you are right about to do it. The ones that read the document are blinded by the end of the story about the awesome thing they saw in their heads… which wasn’t really the key part of the feature being described. The writing it just not consistently that good.
In our last cycle there was an opinion that we never wrote specs or planned features. The reality is that, if you lined up the work item descriptions, comps, and real mock-ups we generated nearly 300 pages of documentation. But the hit rate on those 300 pages was MUCH higher than if we’d started out be trying to write 300 pages of functionality. In retrospect we were working hard to remove “the illusion of agreement” that Jason described.
When it comes to reports… I’ve also written my share of reports that I’m pretty sure I could have filled with LOLcats… and no one would have noticed. Critical data doesn’t need to be repeatedly shared. One time analysis, when it’s needed, is MUCH more powerful than regular, de-humanized, status. So, my advice would be to at least try and humanize any required status reports you make and come up with one insightful stat that means something to everyone that week.
“If what you’re doing really worth it? is this meeting worth pulling size people off their work for an hour? Is it worth pulling an all-nighters tonight, or could you just finish it up tomorrow. “
One of the best managers I’ve had put it to me this way “If a difference of 1-3 months matters that much then what you were doing probably wasn’t going to succeed anyway.” Not weeks… MONTHS.
“Interruption is not collaboration, it’s just interruption. And when you are interrupted you’re not getting work done. “
One of the advantages of being a remote worker is that I get 2-3 hours of “alone zone” time. It really is when I’m most productive. I’m not sure how anyone in the office gets real work done without working 12 hour days sometimes. I also enjoyed Reworks rant against meetings that followed this.
“Meet at the site of the problem instead of a conference room. Point to real things and suggest real changes”
+1
“… estimates that stretch weeks, months, and years into the future are fantasies. The truth is you don’t know what’s going to happen that far in advance”.
This continued Reworks assault on traditional planning. Do you think the release known as “windows phone 7” was actually on Microsoft’s roadmap… or did it completely break the long term plan when they saw the market rejecting Windows Mobile?
“How should you keep track of what Customer want? Don’t. Listen, but then forget what people said… The requests that really matter are the ones you’ll hear over and over… You won’t be able to forget them. “
I’ve found this VERY true. The important bugs, features, and requests will simply keep coming up. The ones that seem important to one customer, when it’s not repeated, is probably not that important.
“Geography just doesn’t matter anymore. Hire the best talent regardless of where it is.”
+1
“The more people you have between your customers words and the people doing the work, the more likely it is that the message will get lost or distorted along the way.”
I tweeted “Second hand feedback kills” a week or so ago. This could not be more true. The people that file the best customer reports are the people that simply post verbatims or even recordings of what the customers actually said and know how to ask the best questions. No interpretation can substitute for the customers actual words. The skill is not in the translation… it’s in the interview. The answers should speak for themselves.
“There are four-letter words you should never use in business… they’re need, must, can’t, easy, just, only, and fast. When you use these four letter words, you create a black and white situation. But the truth is rarely black and white.“
+1
“Create a rock star environment… there’s a ton of untapped potential trapped under lame policies, poor direction, and stifling bureaucracies. Cut the crap and you’ll find people are waiting to do great work. They just need to be given the chance.”
This was the part of the book that really overlapped with Linchpin. The simple point was to create an environment where the linchpins can thrive and you’ll get more out of everyone.
Just like Linchpin, there are a bunch of quotes I didn’t share with you all, but that’s why you should read the book. 🙂