edmondlau

My mission is to:

“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.

Awesome, I'm happy you enjoyed it!

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.

Thank you! It means a lot to me hear its impact on you -- stories from readers are what keep me excited about doing this work.

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.

Awesome! Thanks for adding your notes to the discussion.

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.

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.