Re:Effective Engineer – Notes
by mzzter on Thursday December 28, 2017 @01:02PM
(#16023647)
Hi Edmond, is “high leverage” a phrase you use in the book? From the notes, “leverage” is defined as “impact / time invested.” Why did you choose “leverage” to describe this concept? “Leverage” suggests to me that it is grown with the idea of using it to climb a career ladder, but I’d like to hear your thoughts on this, as I have read just these notes and not the book yet.
[ Parent
| on HN ]
Yes, "high-leverage" is a phrase I use in the book. I learned about leverage when I read Andy Grove's High Output Management.
Why the word leverage?
Time is our most limited resource. And so the way to really increase our impact (say by 10x) is not to increase the number of hours you work, but to increase your rate of impact, which is how I define leverage in the book.
Another way to think about leverage is in terms of a lever, which lets you apply a little bit of force, have it amplified, and then move large boulders. Many of the stories and strategies from the book talk about these leverage points in engineering, e.g. investing in iterating speed or validating your ideas early and often, where small bits of effort end up having a disproportionate impact.
Re:Effective Engineer – Notes
by davidjnelson on Friday December 29, 2017 @05:54PM
(#16032572)
What’s the right level of completion for validation? A few weeks for a prototype seems reasonable, but even that can result in feedback that isn’t or isn’t considered fast enough.
Re:Effective Engineer – Notes
by brucephillips on Friday December 29, 2017 @05:56PM
(#16032591)
It depends. Easily communicated product ideas can be validated on day 0 by talking to users.
Less easily communicated ideas often need at least a demo. Dropbox is one example.
Thanks for your response, I understand it better now. Sorry for what must have seemed like a stupid question.
Leverage directly implies multiplication. Leverage, the physical concept, multiplies force or torque (rotational force). The analogy applies finance: multiplying your profitable strategy with borrowings to multiply the gains. The analogy also applies in software: multiply the uses of your code to increase the value it creates.