10% Engineering Ingredient: Be Insanely Efficient
Free your mental space, free your time
Going from a 10x engineer to a 10% engineer is primarily about efficiency. But at the same time you’ll find out that when you become a better 10% engineer (by having more time), you also become a better 10x engineer (by becoming more effective).
But how can I become a more efficient engineer? I personally follow a simple RADC framework: Reduce, Automate, Delegate, Compound (inspired by the RAD framework from Ali Abdaal’s recent video).
Reduce, Reuse, Recycle
Reduce, means remove unneeded work. This is where you apply the famous Pareto principle or the 80/20 rule. In the software engineering domain you can apply this rule in the following lists:
80% of the information you need to do the work is held by 20% of the team member. This means you only need to regularly meet a subset of your team to understand most information you need to do your job.
80% of the system can be observed and monitored by putting it in the core 20% spot. This means you can put logging only in a few call sites in your system to catch and prevent top issues.
80% of the error/crashes in the system can be fixed by fixing the top 20% of the most-reported bug.
You can achieve 80% sub-optimal decision-making only by understanding 20% of the domain knowledge. This means you only need to learn the high-level or first-principle of a domain. Then you can make a decent decision on 80% of problems occurring in that domain.
80% of the knowledge can be shared just by sharing the top 20% condensed information. This means your weekly report doesn’t have to be lengthy to be informative.
80% of code review issues can be fixed with linter or choosing the right paradigm/language. Focus on the 20% that actually matters.
Reuse means making use of your previous work. In software engineering, it’s generally a sub-optimal practice if you can reuse your work. It means your work could’ve been written such that you only need to build it once and configure it for multiple use cases. That’s why the DRY principle (Don't Repeat Yourself) is very popular among software engineers. Whether you’re a hardcore DRY believer or not, there are few examples where it’s good to reuse your existing work:
Project management template (weekly meeting template, project updates, retrospective).
Building UIKit and Design Language System for the whole app, or the whole product sets.
Recycle means breaking down items into their raw material and reuse them. In product development, I consider this as breaking down a product requirement into smaller pieces where you might observe some tasks are repeated. In software engineering, I consider this as breaking down your system into modular ones so it can be reused for other projects. A few examples:
Building a shared networking library by decoupling it from your main application to be used in your internal tools.
Building a podcast API by decoupling it from your search engine. This is how Listen Notes built its API business.
Facebook recycled React declarative pattern and reused it for their native app application UI library, Litho and ComponentKit.
Automate
Discussion about efficiency is incomplete without automation and productivity tools. In this post, I want to lightly touch on productivity tools from the angle of why we need them vs what they offer - so you don’t have to get attached to these tools when something better appears.
Build your life operating system. Have you ever been in a situation where you forget about things you need to do for a given day? Say no more. You need a life operating system, a system that allows you to take in work, evaluate prioritization, evaluate the time of execution, and feed the system back about things you might additionally need to do.
Building a life operating system will allow you to not have to constantly worry about “what do I have to do today? Am I missing something?” The moment you know you need to do something in the future, the task will be captured in your system. Then it will be placed at the exact date when it should be done. This allows you to not only save time but also mental space.
There are many frameworks that are subsequently powered by different tools you can use to build your life operating system. I personally use a loosely-adopted-overly-simplified GTD framework with Notion and Google Calendar.
Schedule your message. At times, many leaders (especially boomers) love to send non-urgent requests or questions during off-hour (be it on weekends or at night). This is not only inappropriate but also inefficient. Looking from an efficiency standpoint, those messages will not arrive during the productive hour of the recipient, thus they will not get a response that they expect (either timeliness or quality of response). The correct way to approach this is by sending your message to your recipient during their productive times so you get a timely and good response. This also helps build a better work culture.
Schedule your email as well since people don’t read email at night and your email will be buried with other emails in the morning. I usually schedule my emails at 9:41 am on their timezone for the following reason:
Between 9.30 am and 10:00 am because that’s when people start preparing for work. This is also the time when all the other spammy emails are sent already so your email will stay on top of the inbox.
At minutes 37, 41, 53 (or any non-round number) so it doesn’t look like an automated message.
Send it in their timezone because the goal is to make sure they read it at their best convenience, not ours.
Zero inbox is very underrated and not talked about nearly enough. Emptying your inbox is an important tool to free up your mental space to allow you to be more creative and kickstart the flywheel of 10% engineer.
There are top 2 things you can do to empty your inbox. The first one is by unsubscribing to unnecessary emails if you don’t need them. The 2nd one is by adding email rules to move the emails to respective folders or labels if you think you might need them in the future. The goal is to make sure only important and urgent emails go into your inbox, thus into your attention. When you don’t see values from an email list or subscription, add a rule to filter it out, move it to a separate folder, and enjoy less clutter. Don’t worry about false-negative (important emails that get filtered out of your inbox). If they’re that important they will get to you somehow through other means (possibly Slack, WhatsApp messages, or maybe legal letters).
Delegate Work
People are one of the oldest known multipliers to your time and effort. The right people arguably are your greatest asset. But dealing with people is a complex problem because everyone is unique. Doing it incorrectly and you’ll have liabilities instead of assets. Personally, I follow these 4 principles:
Understand their motivation. Everyone has different things that make them tick. Some people simply want the job for the money. Some people want to learn and get challenged. Some people want a bigger title.
Mapping the right work against people's motivation can put the company, team leader, and team member in a win-win-win solution. For example, people who’re motivated by learning will be a good fit for explorative and research-y problems. People who just want to chill might be happy with normal business-as-usual problems (let’s face it, not all urgent and important problems are going to be novel and challenging).
Understanding people's motivation also allows you to delegate work to other people without requiring you to be a team leader or manager. This is called leading by influence vs leading by authorithy.
Invest in onboarding framework and helping with onboarding effort. In his book, Edmond Lau mentioned that investing in an onboarding framework is the highest leverage activity you can do as an engineer (a leader or not). Investing 6 months in building an onboarding framework and 6 weeks for each new team member will give you a massive recurring return of investment by generating effective engineers who will use the knowledge they get from onboarding for years to come.
Give the right bite-size problem to your team member. Giving easy problems to your team member, and your team member will not feel challenged enough and incur opportunity costs. Giving hard problems to your team member and you risk failed projects and frustrated team members. You might need to break down projects into tasks, products into projects, and problem statements into products.
Invest in mentorship. Giving context for an ambiguous problem is relatively easier than breaking it down into projects and tasks. Thus it’s in your best interest to make your team member capable of doing harder, more ambiguous, more complex problems. To allow your team to digest more ambiguous problems you need to mentor them.
There are several mentoring styles. My personal favorite is giving them a harder problem than what they’re comfortable with, giving them enough space (this is the time efficiency kicks in), staying around for their sense of security, and intercepting when needed.
Delegate Knowledge Gathering
Good artists copy, great artists steal.
Within the domain of software engineering and product building, everyone is “forced” to keep learning to stay relevant. There are new JavaScript frameworks every day. New Kubernetes tool every other week. New machine learning algorithm variations every month. New programming paradigm every year. This can get overwhelming real fast, especially as Generalists whose superpower is their ability to connect the dots of multiple domain knowledge to build successful products. It suffices to say that continuous learning is part of the job.
So how do you optimize this learning requirement? There are a few principles that I use to help optimize my time for learning new technology:
Do not reinvent the wheel. In my limited time in the industry, I’ve never seen a problem that has not been solved by someone else. A lot of my failed projects happened because I tried to reinvent the wheel. It’s either the same problem with different flavors of industry, different scales, different companies, or different user types. Sometimes you have to drop your maker’s hat and put your problem solver’s hat instead. Learn from other’s experiences.
Be reactive in your problem finding, be proactive in your problem-solving. Technology is created to solve a problem and make life easier. But at the same time problem evolves (based on the current market situation, company size, problem complexity change). In response to this, I usually try to learn new technology only when I see a problem. Then I do extensive research: understand the currently available frameworks and first principles, come up with multiple solutions, lining up their pros and cons, and future problems based on other people's experience. Finally, I choose the best solution that will work for the next 2 years.
Get a mentor. You need someone with who you can exchange ideas on specific scenarios of your ongoing issues. You also need someone who is a subject matter expert in an area regardless of your expertise in that area. This doesn’t have to be a formal paid mentorship either. This can be your accountability partner, your housemate, your direct reports, your manager, your skip manager, someone you follow on Twitter, someone you meet in a meetup or a stranger you found in a bar.
Stay to Compound
If you’re lucky enough to find a company where you don’t burn out, get fairly compensated, compensations are adjusted frequently, merit-based, and you are constantly learning, then consider staying. Staying in one company compounds. Here’re three reasons why:
It’s not a surprise that the longer you work in one domain the better your familiarity with the tech stack used in the domain is. The more familiar you are with a tech stack, the more effective and efficient you will be in using them in your day-to-day work and planning.
The more senior you’re as a software engineer the more you realize that a lot of software engineer problems are actually people problems. Thus you need to generate social capital to allow you to work seamlessly and effectively with the people around you. Social capital consists of trust within team members, reputation among leaders, and established relationships between the cross-organization cross-functional team. Building social capital requires time and commitment. Thus more reason why you need to stay in one company.
As a 10x engineer it’s important to operate based on the result, not action. And thus understanding business knowledge is paramount. The longer you stay in one company the more familiar you’re about all the funnel within the business. This translates to correct products to build, correct metrics to pursue, optimal prioritization, and correct team composition you need to gather to make a successful project.
That’s the high-level optimization that I do to make my life and work more efficient. Let me know about yours!