Edmond Lau - The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

My first job out of Stanfords Computer Science program was as a Product Manager at Google. It was an amazing first job. I shared offices with engineers who had written the textbooks I used in college. I helped create Google Maps, which is still my proudest achievement as a product designer and engineer. And I learned how to be effective on large scale software projects. By the time I left Google to start my first company, FriendFeed, I had worked on so many projects at scale, I felt extremely confident I could start one myself.

However, being a product manager at a large company is different than founding a startup. For one, you are judged differently. While, in theory, product managers are judged on the success of the products they work on, in practice, large companies also judge product managers on their ability to manage all the people and departments that have a stake in a products outcome. Did you engage the PR team enough time before launch? Did you integrate your product with the CEOs pet project? Did you convince the competing executive of your product direction before the big executive review? At software companies that arent as enlightened as Google, product managers are judged more on these political issues than they are on any aspect of the products they work on.

Thats why so many engineers and product managers that come out of larger companies have trouble with the concept of leverage that Edmond Lau talks about in The Effective Engineer. They are effectively trained to care about low leverage activities because the bureaucracy that trained them values and rewards them. The most successful engineers Ive worked with in my career were the few that were able to see past these bureaucratic idiosyncrasies and recognize the one or two things that would really impact their products success. The engineer that taught me the most about leverage is, without question, Paul Buchheit.

Paul was one of the co-founders of FriendFeed. He had previously created Gmail, and while we hadnt worked together much at Google, we had enough mutual respect to join forces with Jim Norris and Sanjeev Singh to start a company together in mid-2007. More than any person Ive ever met, Paul was willing to challenge conventional thinking, and he completely changed my perspective on engineering and product management.

Whenever we would encounter a challenging technical problem, I would ask How should we do this? Paul would respond, often obnoxiously, Why do we need to do it at all? Instead of trying to solve impossible problems, he would more often challenge the assumptions so we could simply work around them. At times, it almost seemed like Paul was lazygiven any sufficiently hard project, Paul would question the purpose of the project. But he was almost always right. Unless the project was destined to make or break our nascent company, why spend our precious engineering resources on it?

Working with Paul proved to me through experience that engineering was much more about leverage than programming ability, and Ive tried to apply that lesson to all my subsequent jobs. When I became the Chief Technology Officer of Facebook after the company acquired FriendFeed, I spent as much time canceling projects as creating them. At Quip, the company I founded with Kevin Gibbs in 2012, we felt so strongly that effective engineering was not correlated with hours of effort that we have proudly embraced a nine-to-five culture unheard of at Silicon Valley companies.

I love the culture of Silicon Valley. I love that young engineers have as much of an impact on our industry as veterans, and I love how our industry redefines itself every decade. But I also think the culture of working endless hours is unnecessary and abused by ineffective managers around our industry. In addition to being unnecessary, that aspect of our culture is one of the main things that prevents people from choosing long term careers in software engineeringit is unsustainable for people with families, and it creates a homogeneous, immature atmosphere at the companies where it is ubiquitous.

Im happy Edmond chose to write this book because I think Silicon Valley would be a much better place for both managers and engineers if people embraced working smart rather than working hard. Its neither counterintuitive nor hard in practice, but very few people do it, and I hope more people embrace Edmonds philosophy and techniques to make their companies and careers more successful.

My first few years working at startups stand out as some of the longest in my career. They were a relentless grind punctuated with intense personal growth and countless emotional roller coasters. My team almost never worked fewer than 60 hours each week, and months would go by where we would toil away for 70 to 80 hours. Id start my work day in the office; Id regularly spend lunch consulting with my team; and then Id continue to work from home after dinneror sometimes even stay in the office until midnight. Even while visiting family over the holidays, Id still squeeze in time to code and to respond to emails on my laptop.

After all, the nature of startups meant that we were the underdogs fighting formidable competitors. The harder we worked, the more value we could produce, and the more likely it was that our startup would succeed. Or so I thought.

A few experiences forced me to reconsider this assumption. There was the custom analytics module that I spent two weeks buildingand that the customer never used. There were the new tools to improve content quality that we spent months tweaking and perfecting before launchand that never got the user adoption we wanted. There were the weekly traffic spikesfollowed by hours spent spinning up and winding down extra servers. There was the time when I was hiking up the Mauna Loa volcano in Hawaiiand I got a text message saying that the infrastructure generating analytics reports for customers was down, and could I please take a look.

I worked the long hours because I wanted to make a meaningful impact, but I couldnt help but wonder: Was putting in 70- to 80-hour weeks really the most effective way of ensuring our startups success? Our intentions were sound, but could we have worked smarter? Could we have reduced some of that effort and achieved the same impact, or possibly even more?

In the ensuing years, Ive come to learn that working more hours isnt the most effective way to increase output. In fact, working too many hours leads to decreased productivity and burnout. Output may even turn out to be negative when its necessary to repair the mistakes made by overworked and fatigued engineers.