“Empower engineers and technical leaders with the tools and mindsets to perform at their highest levels, so that they create the meaningful impact they’re capable of.”
That mission started with me writing and self-publishing The Effective Engineer three years ago. And then recently I co-founded a company Co Leadership (coleadership.com) to focus on leadership development full-time.
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.
The perspective I'll offer is that good sales copy is also a skill, just like engineering or any of the other skills you mention.
To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.
Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.
The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.
They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.
Wow, that is an amazing story. Thanks for sharing.
It really hammers home how hard it is to disentangle good & bad advice and how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
They're orthogonal dimensions. My fault that this isn't clearer.
Here's a simpler ordering of operations:
1. Start with the most valuable, highest-leverage thing you want to focus on.
2. Figure out what the riskiest bit of that thing is. Focus on de-risking it.
3. When you're de-risking (or more generally whenever you're just doing that thing), start simple. Beware of adding in unnecessary complexity.
I like the bottom-line perspective you provide at the end, of "success = preparedness + luck."
Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.
For every person who rode a powerful technology wave, there are also many others who rode the wrong ones.
One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight.
On the outside looking in, skeptics might have thought that it was nothing new. But the MVP provided validation around what future customers actually thought.
My main takeaway from that story (and that I share in the book) has always been to validate your ideas early and often, so that you can get more signal on whether the assumptions you're using to shape your behavior are accurate.
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.
At Quip, we run one coding interview that happens on a laptop, and where your conversation and discussions with the interviewer, including how you handle suggestions and feedback, matter a huge deal.
For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.
For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.
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.
There's for sure a tricky balance on what fits into a CS education.
I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.
I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.
Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.
Your observation is a great one, and I'd love to see more data on this as well.
A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success.
I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of coaching and listening skills can have a transformative impact on participants.
If there are engineers you highly respect on your team, their code is a great place to start.
Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.
Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.
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.
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.
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.
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.
It's less about management and technical ability, and more about soft skills and hard skills.
A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful:
"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
“Empower engineers and technical leaders with the tools and mindsets to perform at their highest levels, so that they create the meaningful impact they’re capable of.”
That mission started with me writing and self-publishing The Effective Engineer three years ago. And then recently I co-founded a company Co Leadership (coleadership.com) to focus on leadership development full-time.