The effective engineer raise a simple question: how does the engineer leverage his or her effort to make a disproportionate and meaningful impact? Before answering the question, we would want to know how to define and measure the effectiveness of an engineer and engineering activities. The author believes that leverage, the value or impact produced per time invested, is the best measurement for the effectiveness. In order to increase your effectiveness, you should focus on either get the same task done more quickly, or to increase the impact of your activities, or to shift to activities with higher leverage.
The foremost and fundamental part of becoming more effective is to adopt the right mindset. Including focusing on high-leverage activities, optimize for learning, and prioritize regularly in order to keep yourself focused.
The following sections of this book are essentially discussing the two major approaches of increasing your effectiveness. Part II of this book focused on execution: how do you get your work done more efficiently.
The first advise it offers it to improve the iteration speed: the faster you can iterate, the more output you could generate within a given time. Many factors could slow down the iteration speed: maybe your team works on a huge monolithic service without enough support on tooling and debugging, maybe your existing service requires constant operation support that your team gets distracted. To become more effective, you should constantly think about what makes you and your team’s iteration speed slow down.
Another advice is to measure what you want to improve. A common mistake people make during work is using the wrong metric to measure the problem. Selecting the wrong metric could be misleading.
Measuring the area you want to improve also help you better drive the work. Whether you are an individual contributor, a tech lead or an engineering manager, you must be in situations when you would like to bring some technical, product work to people’s attention so that you get their consensus on the priority of the work and support to work on it. In these situations, data and metrics are more compelling than words. So the best strategy is to measure the scope of your work: how many order we lost every day due to this issue, how many customers are being affected. You will be much better off with these measures.
The third advice is to validate your ideas early and often. I’ve got multiple opportunities to start new products from scratch. I find it is very useful to deliver the first version of the product as fast as you can, collect the requirements from your customers then try to improve on it. It is very hard to picture every detail of your product before you bring it to your customer. And I give this advice to every engineer working on some project.
The fourth advice is to improve your project estimation skill. Project estimation is hard, but it is important for the team to communicate the expectation to the stakeholders, and for the business to decide the priority of these works. We made many mistakes on effort estiamation, people either tend to underestimate or overestimate the difficulties of their task, and there is an anchor effect on people’s preference. For large project estimation, this becomes even challenging, because we oftentimes underestimate the unknown parts, and they only start to materialize once the team starts to work on them. Of course, there are approaches to reduce the risk of inaccurate effort estimation, for example, ask the people that will work on the task to do the estimation, and timebox the investigation on the unknown part.
For tech leads and engineering manager who held the responsibilities of communicating the expectation and progress to the stakeholders, the effort estimation becomes even more critical. First of all, you should define a clear goal for your project. A clearly defined goal not only helps you better manage the expectations of the stakeholders but also provides with you a good approach to correctly scope the works and prioritize the tasks. Secondly, you should build your project incrementally. Trying to achieve multiple goals in one project can significantly increase the risk your project get slipped, as the complexity of the project grows exponentially.
Part III of this focused on building long-term value: which is the more impactful work for the engineers comparing to other activities like delivery a feature.
The advice from this section includes balancing the quality with pragmatism. An essential topic for most the engineering team is how to improve the quality of the work, except for a few companies like Google, as they introduced such a good code review system to make sure the code is written in good quality. This is not the case for most other engineering teams. Introduce the code review process will be helpful. Another such topic is about tech debt. Tech debt will be accumulated as the team takes shortcuts on the development. It is totally okay to introduce tech debt on the code base, but the team should also have a pan to continuously repay the tech debt.
The next advice is to minimize the operational burden. You must always be aware of the tech decision you make: is it engineering infrastructure you build robust enough that you don’t need to worry about its operation support? Does the tools you provide enough visibilities with the clients to track out the failures easily? Another typical mistake we make is to introduce new technology without enough knowledge about its operational burden.
The last advice is to invest in your team’s growth. Help the people around you be successful, building a better onboarding process, making hiring a priority of the team. All these works would lead to a better engineering culture.
This book is not only a good choice for engineers who want to become more effective but also a good guide for the engineering managers to materialize their ideas of building a better team: essentially only when your team member becomes effective, you will be effective.