I saw your google tech talk a while ago, and I really like the concept of leverage even though I usually dislike this genre
https://www.youtube.com/watch?v=BnIz7H5ruy0 I think people get too religious about effectiveness.
I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?
1) It's also important to align your energy levels and what you want to do with your list of high-leverage tasks. When you're really excited about doing something, even if isn't strictly the highest-leverage thing you could do, you can actually end up creating more impact because you do a much better job of it.
2) Sometimes what's needed is just a change in perspective about things you need to do. I play with this a lot in the leadership coaching that I do. For example, I hate responding to emails because processing them all feels like a chore. But if I reframe responding to emails in my mind to be hunting for gems that might lead to new opportunities, I'm much more likely to go through them (at least the ones that are gems).
And oh yes, there were definitely discouraging points. The story about early, negative feedback from my wife (that I posted in another comment) was one.
Another is that ten months into book writing, around the start of 2014, I started feeling a sense of intense FOMO from reading Hacker News. Stripe had raised a valuation round of over $1B, and WhatsApp had been acquired for $16B. That led to moments where I would wonder "What in the world was I doing writing a book?" and "When will I ever finish?". I had just finished a first draft, I wasn't sure how rewarding financially the book would be, and I was feeling like I had removed myself from the startup game.
That led me to start looking for jobs, which quite fortunately, also led me to my current role at Quip. So everything worked out in the end.
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.
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.
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.
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.
Hi Edmond, your book was great and I enjoyed reading it!
I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...
In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora).
The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.
Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.
That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.
For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.
Would be interesting to hear more about the projects that failed. How big of a rewrite was it? How long did it take before the group or a manager recognized that the project was failing? How did the group deal with the failure in the social sense?
Yep! I've read The Effective Executive. One of my big motivators for writing the book was that there were all these great ideas that were encapsulated in business books or personal improvement books, and very few books that would tie them back to engineering. That's the gap I wanted to fill.
Your observation is a key reason why taking the time to define your impact and to measure it is so important. As Drucker says, what gets measured gets improved.
In business contexts, your engineering impact generally ties back to the business value you create (i.e. revenue and profit). If there is already some model for translating your area of work to revenue (e.g. increase users -> increase revenue, reduce fraud -> increase revenue) then that can also give another proxy metric to optimize for. So for example, when working on Google Search Quality, we would often just optimize for long clickthrough rates, knowing that strategically, the ads team would take care of turning returning searchers to revenue.
It gets harder when you're working on areas like bigger bets (where you can have high impact but it is unknown for a long time) or in trying to understand an infrastructure investment in terms of its business value to the company. There, it may be sufficient to just know that something is of strategic value and then measure your impact in terms of those strategic goals.
What was the process like? How much time did you spend relative to other projects, and how did you incorporate your principles of leverage into creating the book?
In many ways, it was similar to building a startup product.
I quit my full-time job at Quora and spent ten months full-time on the book (with bits of traveling). Like any other project, I drastically estimated how long it would take. I estimated one year; it ended up taking almost two. I finished the book while working full-time at Quip.
At times, it was an amazing adventure. I loved going around Silicon Valley and interviewing people like Mike Krieger or Sam Schillace to get their stories and their most valuable lessons.
Other times, there were also intense periods of self-doubt. The first person I shared a chapter draft with was my wife. She's also an engineer and by default can give quite critical feedback. And, wow, did I feel shut down after my first round of feedback. It's confusing! I don't understand the point of this! etc.
I ended up spending two months iterating by myself on my next drafts to build up more confidence before sharing with more engineering friends -- they then really gave me the support I needed to feel confident about writing the book. The experience was a great lesson in how new ideas need to be nurtured, and you need to either find supporters who will nurture that for you, or ask for the type of feedback you want (which is what I now do with my wife). It was also a valuable lesson in getting feedback sooner on your project before you are too emotionally attached to feel comfortable about asking for feedback.
All in all, it's one of my proudest accomplishments in my career.
I also just remembered that I wrote this blog post a while back on what self-publishing taught me about shipping products. It also shares a few vignettes and lessons from my self-publishing experience.
I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?