Drawing from my personal experience that bagged me multiple offers over $800k, this guide will walk you through optimizing your resume, LinkedIn, and online presence to win more interviews and ultimately secure that dream job.

📝 Sculpt Your Resume

The first impression is the last, and your resume is your first impression. Use LinkedIn's features to craft a comprehensive resume that complements your traditional one. Emphasize displaying your skills, experience, and cultural compatibility, which are top priorities for recruiters. Highlight your most notable achievements, relevant skills, work experience, and academic qualifications. Prune out outdated or irrelevant data and avoid lengthy paragraphs or text blocks. Keep your resume concise and restricted to a maximum of two pages. For additional pointers, check out this article on how to write an impressive developer resume.

🔗 Build Your LinkedIn

LinkedIn is your professional digital identity, a platform that makes you visible and accessible to potential employers and recruiters. Even though I once stated that job titles are overrated, recruiters still use them as a preliminary filter to evaluate your suitability for the job.

Make it a point to underscore the skills you've applied in your experience. Not only does it enhance your profile visually, but it also enables hiring managers to spot your profile when they're in search of a candidate with specific skills.

🔍 Operating LinkedIn

LinkedIn's search feature can be your ally in discovering job opportunities and connecting with professionals in your field. Pro tips: following companies can increase your profile's visibility and inform you about job vacancies.

Set your profile to indicate that you're open to new opportunities without tipping off your current employer.

Personalize your messages to your connections, expressing your interest in particular roles or companies. Regularly posting relevant content helps exhibit your expertise and engage with your network.

📧 Approach the Head of Engineering

Skip recruiters and directly contact the head of engineering, engineering directors or VPs, who are more likely to engage with you. Engineering managers might lack the authority to make hiring decisions; hence it's wiser to target higher-level decision-makers. Check out this thread for more insights.

Leverage online tools and resources to locate the email addresses of the head of engineering. Use ChatGPT-4 to draft personalized and engaging emails.

🕵️ Work with Headhunters

With their vast networks and expertise, headhunters can help you secure interviews at premium companies. Always respond to headhunters professionally and politely. Collaborating with headhunters costs you nothing but time, as the hiring company pays their fees.

📥 Manage Recruiter Reachouts

Treat each interaction with a recruiter professionally and respectfully, as they can be your gateway to new opportunities. Create a separate folder in your inbox to keep track of recruiter emails, ensuring easy access for future reference. Stay connected with recruiters, even if they've moved to a different company, as they might still provide valuable leads.

🌐 Job Portal Applications

Make use of diverse job portals to boost your job search efforts. Some well-known platforms include remoteok.com, angel.co, workatastartup.com, weworkremotely.com, and jobboardsearch.com.

🌟 Build Your Online Presence

Maintain an active online presence to build credibility and authority in your field. Keep your LinkedIn profile current and actively interact with your network. Share industry updates and insights, and engage with professionals on Twitter. Publish articles on Medium to showcase your expertise and experiences. Start a Substack newsletter to share your thoughts and insights with subscribers. You can also start a YouTube channel to share tutorials or industry insights. And remember, a little bit of light-hearted content or "shitposting" is okay too.

💻 Contribute to Open Source Software (OSS)

Although contributing to OSS can be demanding in terms of time, the benefits are undeniable. Make substantial contributions that enhance the project and exhibit your skills. Despite the commitment involved, OSS contributors often find themselves with a higher success rate in securing job interviews.

🎲 It's All a Numbers Game

At the end of the day, be prepared for a fair share of rejections. Always bear in mind that it's a numbers game. Rejections are not a reflection of your worth; they simply suggest that the role wasn't the perfect fit for you. Devote time and effort to refining your resume, expanding your network, and differentiating yourself from other candidates. Your funnel of interview might look something like this:

How do you market yourself?

Note that this writing was from 2021, so it might not be applicable anymore with all the tech winter happening.

These companies might not be hiring in the place where you live, thus making the table above not relatable. But you can try building your own list based on the table above as an example.

I personally would join Facebook as a new grad to learn, get promoted fast, and get the FAANG credibility on my belt. Then either build a startup or join one as a very early employee. Or maybe just have an early retirement in LinkedIn or Google.

As a leader, your success can be traced to your decisions. So you need to make decisions better (correct ones, and timely).

I want to share one simple decision-making framework that I think will help you make decisions efficiently (but probably not effectively):

Is it a one-way or two-way decision?

A one-way decision is a decision that once taken and implemented, is something you can’t reverse or take too much effort or cost to rollback

Few examples:

• Should I hire/fire this person (reverting this decision is usually hard, and unethical)

• Which vendor should I use for our cloud computing platform? AWS or GCP? (vendor locked. Migration takes multiple months or years)

• Which vendor should I use for the analytics tool? Datadog, New Relic, or Honeycomb? (choosing one vendor will risk us into a vendor-locked situation)

A two-way decision is a decision that can easily be reverted. It’s not correlated to how big the decision is

Few examples:

• Should we try selling a subscription model or a one-time purchase? (we can find new buyers to try new models)

• Should we show the onboarding page or not? (we can always experiment)

• Should we use tabs or spaces? (we can just change the linter and code formatter to enforce one or the other)

• Which analytics tool supports OpenTelemetry that I should pay to help us today? (we can change our vendor to other vendors who support OpenTelemetry)

The framework is quite simple to execute:

• Given a problem, is it a one-way decision or a two-way decision?

• If it’s a two-way decision, then YOLO. Don’t think too much about it and just do it (any of them is fine).

• If it’s a one-way decision, is there a way to frame the problem to become a two-way decision (check the analytics tools decision-making example above).

• If it’s still a one-way decision, only then we should spend some time thinking deeply about the decision.

Thinking about decisions in one-way or two-way decisions allows you to avoid paralysis analysis, move fast, while preventing costly mistakes. It doesn’t guarantee you get the correct, best decision tho.

So, how many decisions have you made today?

This is copied from the email that I sent company-wide. It’s about mindset of innovating and building from first principle (vs working iteratively or building based on what the management tells you)

Let’s discuss the history of ice that involves innovation and working from the first principle. To help with the explanation, let me tell you a story about the advancement of the ice industry as told by Guy Kawasaki, paraphrased to my flavor.

Ever since the beginning of civilization, food preservation has always been one of the (top) human problems. Back then, there were several methods to preserve food, like drying, salting, smoking, and pickling. One of the more interesting ways to preserve food is by chilling it with ice.

Using ice to help households preserve food started by harvesting ice from ice lakes. Ice blocks are cut into transportable pieces and delivered directly to the end customer.

Then humans advanced to transport the ice more efficiently. Instead of delivering the ice directly to every household, ice blocks are transported into a temporary warehouse and then delivered to households as needed. The goal is to preserve the ice for a longer time as ice is created naturally during winter and needed during other seasons when the temperature is higher (putting a lot of ice blocks together in the warehouse will help keep it frozen for a longer time). It also improves the efficiency of how ice gets delivered to the end customers. Ice blocks supply chain was born.

Then later, in 1800 ice factory was born. Instead of harvesting the ice that’s only available during winter, ice is created through artificial refrigeration. Humans grasped the ability to create ice all year round. The factories needed to make ice at scale to make the business profitable. They created a lot of big blocks of ice and only cut it for household consumption as needed.

These days every household has a fridge that can make small ice blocks for themselves. This newfound invention then enables new kinds of use cases beyond food preservation, such as making cold drinks during a hot summer.

Imagine if humanity stopped innovating and kept optimizing how to build the best ice supply chain. Imagine if companies only listened to the complaints of the supply chain worker, optimized how they work, and didn’t bother to stop and think from the first principle on why they need to deliver ice to begin with (clue: customers just need the ice, they don’t care how it’s being procured).

Maybe the innovators of the year 1800-1900 might’ve contemplated these questions:

1. Do we always need to deliver the ice we harvest directly to the end customer? Can we deliver the bulk of ice blocks more efficiently? (ice harvesting → ice harvesting supply chain)

2. Why do we need to optimize the ice supply chain, to begin with? Can we create a machine that creates ice? (ice harvesting supply chain → ice factory)

3. Do we need factories to make ice? Can each individual household make its own ice? (ice factory → fridge)

Maybe in the future, we will not need ice to keep our beverages cold and preserve our foods. Maybe in the future, we will have a blowtorch-like tool for cooling instead of burning. As long as we don’t stop asking questions, we don’t stop thinking from the first principle, and we don’t stop innovating, the possibility is endless.

Innovation is not when we make our team consume and process Google Sheets better and faster. Innovation is when the system automatically contacts our farmers to buy 2 tons of dates and 4 tons of bananas two weeks from now based on customer demand with anticipation of Ramadhan and Eid al-Fitr. Innovation is a step-function change in how we operate, market, build, and consume that solves the first principle problem.

So I encourage you to ask yourself these questions:

1. Are we blindly listening to users’/customers’ complaints without understanding what they are trying to accomplish? (aimless iteration)

2. Are we just providing services in response to competitors, the hype of the market, or what has worked in other markets (non-first principle)?

3. Are we innovating on solving their problem from the first principle?

If you want to become a 10% engineer, there are three setups in your control that you need to have:

1. Stay in the right company

2. Work with the right boss (manager, investor, or yourself).

3. Be in the right team

Let’s dig deeper into them.

🏛️ Stay in the right company

You want to be in a company that evaluates based on outcome (product metrics, stability), not output (hours worked, line of code submitted).

Many variables are involved in generating “outcome” (other stakeholders’ skill level, market condition, leadership decisions), which make it relatively more challenging than generating “output.” But these variables means there are a lot of leverages you can push to generate those “outcome.” With the right setting, knowledge, and experience, the companies that appreciate “outcome” will be a better company to work at for engineers who want to massive impact with little effort (a.k.a. 10% engineer).

For the reason mentioned above, generally, product companies are a better fit for 10% engineers than developer agencies. This is also reflected by the salary product companies can give to their engineers compared to developer agencies.

Finally, evaluate a company by investigating the founders and executives’ (C suites or VPs) pedigree. Like DNA, founders and executives typically don’t create their own culture - they inherit from their previous workplace. Building culture takes years to execute, evaluate and evolve to see what works. Only exceptional people (read: mutations) can generate cultures from scratch. We can’t rely upon everybody to be able to do this. Join a company where the founders or executives come from a company that has great cultures.

🏭 Work with the right manager

When I started my career, I wanted to work on a cool product. Due to my previous internship experience, I thought working at Facebook was not cool, and I decided to join Parse, a company acquired by Facebook. It took me 1.5 years to get promoted, significantly slower than my peers who get promoted in 6 months to 1 year. Mind that I have plenty of working experience before (internships, building products, freelance projects, founding a consulting company), so my engineering skill is not that of new grads.

Ultimately I realized that this happened because Parse experienced multiple reorgs, causing non-negotiable three manager changes within 1.5 years. The manager changes meant my next manager needed to relearn my career path: the gap to promotion, what project I should build, what skill I should learn and display, and peers I can learn from.

A good manager is not just someone who leads and supports the team. They are a great teacher. They are a great mentor. They are a great listener. They help resolve conflicts. They help unblock your project. They give you the spotlight. They acknowledge and celebrate your success. They support and raise you on failures. And most importantly, they usually are in the best position to put you in the right place so you can work on projects with maximum impact and the least amount of work.

To find the right manager, find someone who embodies the following qualities (inspired by this book):

1. Set expectations for your work

2. Provide the proper material support (laptop, licenses, devices) for you to get the job done

3. Play favorite and have “heroes” for each role

4. Utilize people strengths and weaknesses (vs. assuming everyone should perform and act the same way)

5. Build a culture of recognition and appreciation

6. Give timely feedback in a manner that you can accept

7. Care about your life beyond work

8. Encourage skill development and allow (or even encourage) failures

9. Listen

10. Build a culture of quality and high-performing team (which also means firing low-performer)

11. Facilitate and encourage social activities beyond work

In the future, I might make a follow-up post to talk about a practical way to find great managers.

⚽ Be in the right team

Software engineers don’t work alone. They work with other engineers, product managers, designers, data analysts, and other parties. Each of us will push a different lever to get the team to the desired goal. Software engineer writes code; the designer draws mockup; product manager creates product strategy and roadmap.

It’s critical that you work with the right partner. Because at this point, you should be working with a company that evaluates a team based on the outcome, not output. No matter how good your code is, if your design sucks or your product direction is wrong, your impact is virtually 0.

How do you spot rockstar designers or product managers? I don’t have an excellent framework for this yet (I’ll update my writing as I formulate one). But here’s how you can learn how to have a knack for spotting a good product manager:

1. Go to a big tech product company. Don’t go to consulting/agency, tech-enabled, or tech-lead company. You have to be in a company where product managers (and maybe engineers) are first-class citizens.

2. Work with a product manager comparable to IC5 (senior level).

3. Observe how they work: and how they strategize (come up with the direction, build a roadmap, set up processes) and execute (project management, communication with stakeholders, drive meetings). See how they balance between going deep into execution vs. taking a step back to strategize.

4. Now try working with an IC3 or IC4 product manager and observe the difference.

Once you’re in the correct setup, what do you do next? You manage your setup

🥺 Managing your manager

Regardless of how democratic, bottom-up, meritocratic your company is, your manager will be the most important people you should work with. Your manager will affect > 80% of your projects, teammates, promotion, compensations, career growth, work, and life satisfaction. This is why it’s essential to understand your manager’s motivation.

Understand how your team gets evaluated. What does success look like? What are the north star metrics? What are the levers to move your team toward that north star metrics?

Understand how your manager handles shit from their managers/leadership. What does failure look like? What happens to them if the team fails?

Continuously gather context about what’s going on in the team, not just from a technical and product standpoint but also about your fellow team member. How’s everyone feeling? Is anyone pursuing a promotion at the moment? Who’s highly motivated, and who’s demotivated? How many more people do we need to hire?

Finally, once you have enough context, you can start formulating a plan with your manager. Create a plan with your manager and agree on it. Nothing a manager loves more than a team member who can write their own plan, so they only have to course-correct (vs. making everything from scratch). Then get your manager to agree on the deliverables and the timeline. Don’t forget about our previous concept about leverage: the more variables you took into account in your plan, the more challenging it is, but also the higher the leverage is.

Once you’ve agreed on a plan, your next step is to communicate often with your manager. Tell them your worry. Tell them blockers. Tell them about project updates. Tell them all the wins, all the failures, all the learning. Complaining is not bad. If your manager has a problem with you complaining, they are the problem.

🤝🏿 Managing your peers

The first principle to manage your peer is to understand the three circles: Circle of Concern, Circle of Influence, and Circle of Control.

Circle of Concern is the aspect within the company that you need to understand because it will affect your organization, team, and project.

Circle of Influence is the aspect within the company you can direct through convincing several people. Most of the time, these are your peers’ Circle of Control.

Circle of Control is the aspect within the company where you’re the primary decision-maker. It can be the code you write, the team you lead, the project you lead, the infrastructure you’re in charge of.

To become a high-performer, you have to increase the Circle of Influence and Circle of Concern. This, in turn, will lead to an increase of Circle of Control (promotion). This act of high-agency-ness will take you places, regardless of whether you end up getting results or not. But this is also very stressful.

To become a 10% engineer, you have to be smart about adjusting these Circles. In my observation, increasing your Circle of Influence and reducing your Circle of Concern while keeping your Circle of Control will give you the highest impact with the lowest amount of effort.

Another building blocks to help you manage your peer is to know your One Job. The point is it doesn’t matter about extracurriculars that you do unless you do your primary job well. A software engineer should be writing code and building systems. DevOps should be maintaining and building infra. Data analyst should be generating actionable data-backed insights.

So yes, you have to understand how good the design is. Yes, you have to care about the direction of the product. But you’ll be better off focusing your time making sure you do your One Job properly rather than helping the design team with their sprint planning process.

This sounds contradictory to my previous statement to add as much leverage as possible by adding more variables to your goal. The secret is to balance and act accordingly depending on how good your team is and how good you are.

🏈 Managing your team

Even if you’re an individual contributor, there’ll be a time when you need to lead a team (a cue to start adding “tech lead” in your title). Big projects like major data migration, new product initiatives, cross-platform projects (iOS, Android, web) need to be built by multiple engineers.

On such projects, you have to collaborate with the stakeholders (other teams, leaders, product managers, designers) to figure out the right goal. You also have to figure out the shape of the project to finish the task faster. A lot of time, this means breaking down tasks to maximize parallelization. Other times you have to introduce overhead to move more quickly (for example: building a no-code tool to avoid writing repetitive frontend code for the internal dashboard).

Aside from transforming the project, you also have to figure out the right way to work with your team. You have to inspire them. You have to coach them. You have to guide them. You have to let them make mistakes. You have to celebrate their wins. And they most likely will not come naturally for you.

There are two books that are, in my opinion, quite polarizing about managing your team: High Output Management by Andrew Grove (focus on process) and First Break All The Rules by Marcus Buckingham (focus on people). Even if you are not a manager, I believe these two books will give you many insights into managing your team better for maximum outcome and satisfaction.

Other recommended reading:

1. The Effective Engineer by Edmond Lau

2. The Effective Executive

3. How to become a more effective engineer by Cindy Sridharan

1. Amount: how big is the total compensation in dollar number. A higher amount (read: more money) is better.

2. Liquidity: whether you can spend them right now for a cup of coffee (liquid) or do you have to go through some process (not liquid). Some examples of processes to liquidate your compensation: selling it through brokerage, selling it through a secondary market, wait for 3 months. More liquid is better.

3. Tax implication: whether you have a special tax implication by having them right now, or a year later where you might get more favorable tax implication. This depends on the country where you work in. Less tax implication is better.

Also, this is not tax advice. Please don’t sue me.

With that laid on the table, let’s get started!

🤝 Sign-on Bonus

The company will compensate you upfront for joining them and ask you to stay in the company for a while if you want to keep the money. This is called a sign-on bonus. Usually, the amount is not huge. But it’s a good way to attract talent who loves quick cash.

💵 Salary

Nuff said.

🤑 Performance Review Bonus

Performance review bonus is, as the name says, distributed after a performance review is done. This will be a merit-based cash bonus you’ll get either once per year or once every 6 months (depending on your performance review cycle). The amount depends on your performance, your company performance, and your seniority/title.

📈 Stock Grant aka Restricted Stock Unit (RSU)

Stock grant is where you’re granted some amount of equity of the company you work in. Usually, there will be a cliff and vesting period (typically monthly, 3 months, 1 year) until you own and can sell them.

The equity can be sold in brokerage if the company is public, allowing you to get your money in a day. If the company is private you’ll need to sell them in a secondary market which is less regulated and significantly less liquid.

Depending on your seniority and your market you’ll get most of your money in this form. This is in line with the company preference: delaying cash compensation as long as possible to allow more liquid capital for them.

📉 Stock Option

Stock option is a piece of paper that tells you “you have the option to buy this stock (or do nothing about it) for Y price.” The benefit of having a stock option is you can buy the actual stock (aka exercising the option) for a lower price compared to market value.

For example, you were given the option to buy 2,000 shares of Palantir for $10 per share when you join Palantir as part of your agreed compensation. Then you work there for a year and Palantir went into IPO. As of today (21 Sep 2021) Palantir stock is priced at $26 per share. This means if you exercise the option today you are getting:

$26-$10 * 2,000 = $32,000

Similar to stock grants, depending on your seniority and your market you’ll get most of your money in this form. The problem with the stock option is it is not liquid and usually can only be sold in the secondary market. Otherwise, the company would’ve compensated you with a stock grant instead.

Interestingly enough, there’s a significant amount of stock options not exercised due to the tax implication to liquidate them. You can read more in this article.

⛱️ Amenities and Benefits

Amenities and benefits are all the stuff you receive that doesn't really go directly to your bank account. The best way to explain what amenities and benefits are by listing their examples:

1. Health insurance

2. Time off policy

3. Maternity and paternity leave

4. Food at office

5. Company voucher or discount

6. Life insurance

7. “Life insurance”

There are way more amenities that I haven’t mentioned (gym membership, 401k/pension fund matching, getting IVF treatment paid by the company, relocation bonus). But I won’t discuss it exhaustively because there’s a saying that will drive us away from the 10% engineer principle:

Collecting airline miles is coupon-clipping for the middle class.

Tax avoidance is coupon-clipping for the upper class.

Comparing amenities and benefits is coupon-clipping for white collar.

10% Engineer Recommendation

This will depend on your risk profile (are you married, do you have kids, how much money do you have in the bank), your stage in life and career, and possibly many others. So this recommendation is coming from someone with a pretty high risk profile, married with a kid, has a considerable amount of money in the bank.

Amount trumps everything. This means take as much combined compensation as possible.

I have never been in a company where the company managed to exit while I was there during the exit. So stock options are worthless to me. I hope my opinion will change in the future and this is an experiment that I am conducting right now.

I don’t value amenities and benefits too highly. I have never been to the doctor for 7 years I was in the US no matter how sick I was. I took free lunch for granted. So I don’t count them into the equation. This increasingly shifts as I grew up and my family situation changes. For example, I am now looking more at paternity benefits and insurance for my family. Because while I am physically fit, my baby isn’t.

I’d also really consider the tax implication it has on my overall income. If I were to go back to the US I’d probably live just fine with $200,000. Thus I would rather have the remaining significant amount of compensation be in stocks (option or grant) so I can reduce the tax implication from 45% down to 15% if I hold them long-term.

Explicitly…

You ask your data analyst for an urgent 20 page report that should be submitted by Monday - on Friday evening.

“Heya, Mr. Shivambudi said this need to be done tomorrow. Can you quickly look at it?” at 11 pm.

… or implicitly…

You reply email at 10 pm.

You send code change and requesting code review on Saturday.

Asking your team to work off-hour is actually suboptimal both short-term and long-term. Here’s why:

1. You won’t get what you want

2. You’re not resting

3. It hinders creativity

4. It kills morale

5. You will lose team members

Let’s explore them one by one.

🙅‍♀️ You Won’t Get What You Want

Have you ever seen someone who opens emails from the oldest one rather than the latest one which appears at the top? Have you ever meet someone who replies to Slack messages from the oldest unread messages vs the most recent ones?

Yeah, me neither.

Email clients and communication channels are built to prioritize the latest information. Because often it’s the most relevant one.

Imagine emailing someone on Friday night at 8 pm. By Monday 9.30 am your email will be the last thing this person reads, piled under tenths of other (spammy/promotional) emails.

🛌🏾 You're Not Resting

You’re taking your time away from your family. And if your time is not important for you, then think about this: you are taking someone else’s time away from their family.

Asking people to work at night and weekends means you’re creating a pressure-cooker culture where everybody will eventually break down.

💡 It Hinders Creativity

Related to my previous post, to be creative someone need to have extra time and mental space. Just like Cassandra needs ± 30% of free space to compact its data, humans need to lead a life of leisure to be creative.

Software engineering and product development is a creative job. So you need to be very careful about losing creativity within the team.

😩 It Kills Morale

People don’t like to be asked to work on the weekend. It’s even considered illegal in most of Europe.

Do it once or twice, your team might understand and might even be happy due to the shared pain. Do it every week and you will kill the team’s morale.

🏃 You Will Lose Team Members

What happens after morale is killed? That’s right, people start leaving. When people are leaving, the remaining team member will start thinking as well:

“She left. Did she know something that I don’t?”

“I am happy here. But this is a reminder that maybe it’s the right time to consider other opportunities”

“Look at all these job left by Alice! I’ll quit if we don’t get any help by next Monday!”

People who’re unhappy in their role usually won’t recommend the job to their friends.

What You Should Do Instead

Schedule your communications. Schedule your emails. Schedule your Slack messages. Not practical, but you should schedule your commits and pull requests as well. Based on my previous post, 9.41 am is the best time to schedule your emails and messages.

Reduce dependency. People work on weekends because they need to catch deadlines. Usually, deadlines are created through dependencies with other parties. Minimizing dependency equals minimizing deadline.

Plan your 3rd party discussion. Working with 3rd party will generate dependency, thus generating deadlines. Sometimes it’s impossible as you grow in your career (or the company grows in size) to not work with 3rd party companies at all.

Prioritize 3rd party as non-movable deadlines. Expect 3rd party discussion to be slow. Better planning will give you better weekends.

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:

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

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

3. 80% of the error/crashes in the system can be fixed by fixing the top 20% of the most-reported bug.

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

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

6. 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:

1. Project management template (weekly meeting template, project updates, retrospective).

2. 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:

1. Building a shared networking library by decoupling it from your main application to be used in your internal tools.

2. Building a podcast API by decoupling it from your search engine. This is how Listen Notes built its API business.

3. 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:

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

2. At minutes 37, 41, 53 (or any non-round number) so it doesn’t look like an automated message.

3. 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!

I was entering this big room when I was asked to conduct a “Pirate (M)” interview, a design system interview for managers. I was welcomed by the previous interviewer, who conducted a coding interview question (apparent from the writing and pseudocodes on the whiteboard), and a middle-aged man with a buttoned-up shirt, chinos, and a pair of leather dress shoes. We introduced each other, confirmed that he’s the right candidate that I was supposed to be interviewing. I followed up with a question that was meant to confirm that I should be interviewing him for “Pirate (M)” interview and not “Pirate” interview (the bar for the two interviews were different. Facebook expected managers to be a bit rusty so they lowered the bar on some aspect of the interview).

Me: you are a manager, right?

Him: no, I am a director.

Me: oh, I meant you’re interviewing for a manager position, right?

Him: hmm, really? Might wanna check with the recruiter.

After the interview, I got curious and read the resume (for system design questions you don’t have to know the candidate's prior knowledge, so I didn’t read his resume before I did the interview).

Current: Director of Engineering at S**sf**ce. Responsible for X area with 14 recursive reports.

Then I checked the position he’s interviewing for:

Target level for candidate: M1

M1 at Facebook is an entry-level manager position who manages 5-10 engineers. Directors at Facebook usually manage 100+ recursive reports.

The point that I am trying to bring here is less about comparing company, their titles, and which one is better. I want to bring an instance where titles meant different things between one company and another. The big title (director) doesn’t always translate to higher compensation and scope compared to the smaller one (manager). You can crosscheck levels.fyi to see the factual data. Another example is me. Currently, I am supporting 60+ engineers as VP of Engineering in Indonesia and I got paid 1/10th of my total compensation when I was a software engineer at Facebook in Seattle, supporting 15+ engineers.

A high title can also be a massive nuisance. For example, if you put your title as CTO on LinkedIn you will be bombarded with random cold-caller trying to sell you their products/SaaS.

Pro-tip: unless your company need a CTO for branding purpose, set your title as Head of Engineering or VP of Engineering. Leave possibility for the cold-caller to think that you're not the one who make the final say in decision making.

So what matters?

There are several things that dictate your day-to-day at work:

• Job title

• Compensation

• Job scope and expected responsibility, influence, and impact

• Role and authority

• Public/external perception

These factors are not necessarily correlated to each other (e.g. higher scope doesn’t always mean higher compensation). These are factors you can choose when you’re finding/choosing your job (assuming you’re desirable enough to have choices).

After interviewing you often get a sense of not only your job title, but also your expected compensation, job scope, role, and public perception (or these usually are written in the job description). The key takeaway is to be aware of these factors and optimizing them based on what you want in your career vs just optimizing for the title.

Titles are not entirely useless though

It’s not that title is entirely useless. Titles boost your ego. People will look up to you as a VP of Engineering even though you only have 2 recursive reports: 1 frontend engineer, and 1 intern. Sometimes it feels good to not get asked to fix your uncle’s printer because even your uncle understands that fixing printers is not the VP of Engineering’s job.

Titles will still give you a pass to enter “the room” where you will be given more scope and opportunities. For example, the moment I was promoted to E5 at Facebook, I was immediately added to all strategy meetings by my manager even though theoretically at Facebook the promotions are lagging (means you already perform at the next level first before you get promoted). As an E6, I was suddenly added to performance review calibration meetings.

Titles also help you sell. For example, some companies will need to have a CTO (even though he/she is not performing as one) just because it’s the common language spoken by investors and venture capitalists to determine whether you got your tech team together. Some companies adopt a dual-title system, internal and external ones, so that we can use different titles during a sales pitch with clients. Because who wants to be served by a mere software engineer? Give me your VP or Head of Engineering at least!

So what’s my recommendation as a 10% engineer? Get the highest compensation possible, job scope depending on your stage in life and career (bigger if you are early in career and wanna learn, lower if you have other priorities in life, ready to be 10% engineer, with some risk to get fired due to underperforming), mid-level role and authority (not too high that you’re highly scrutinized, not too low that you don’t have influence), low public perception, and finally lowest title as possible to satisfy above requirements.

10% engineer is a 10x engineer who has high degree of efficiency thus only requiring to work 10% of the time to accomplish similar result expected out of them.

In this post I’ll outline from bird-eye view the ingredient to become a 10% engineer which I’ve mentioned briefly in the previous post:

1. Become a 10x engineer.

2. Crystal clear on what’s expected out of you (even if you’re the one who’s making expectations yourself).

3. Be insanely efficient.

Let’s get started!

Be a 10x Engineer

Become a 10x engineer is not easy, but it’s not impossible. It might take years or even decades until we are comfortable operating as a 10x engineer. Since we’ve discussed how to become a 10x engineer in another post, I am here to resume that knowledge with the easier 10x engineer archetype to be a 10% engineer.

The principle of which 10x engineer can easily become 10% engineer is about how many leverages you can push to create impacts and how good you’re at pushing those leverages collectively. The leverage here means a tool/media/activities to produce value per unit of time invested.

For example, if your only leverage in a project/product/organization is the coding skill and debugging, you only have 2 leverages. But if you’re capable of shaping the organization structure, career alignments, design sense, building culture, and making product/team strategy, then you have an extra 5 leverages you can play with.

The simple explanation why having more leverage help is there’s more way for you to influence the project in the right direction (and inversely, more ways for you to screw up as well). This means:

1. You can put your thoughts, knowledge, creativity, and skill into multiple places where it could’ve been a blocker/bottleneck to the project.

2. At 10x engineer level your contribution will generate multipliers. The 2 simplest examples of multipliers are building automation through coding (thus you don’t have to do repetitive tasks), and mentoring people (thus you have more hands who can help you).

3. It’s arguably easier and faster to become the top 80% percentile at 5 different things than to become the top 99% percentile at one thing (Pareto Principle).

4. There’s also a diminishing return on investing more time on single leverage (yet another Pareto Principle).

For the aforementioned reason, it’s implied that the easiest 10x engineer to become the 10% engineer is the PM Hybrid while the hardest 10x engineer to become the 10% engineer is Coding Machine.

The next thing you have to do is to make sure you set the right expectation with your manager/leader/yourself that you will be accountable for these extra directions you’re pushing the project to.

Setting Up Clear Expectation

Setting up expectations with your manager/leader/yourself is critical as a 10x engineer and even more so as a 10% engineer. The term 10x engineers came through the speed and quality of someone getting into the goal, 10x faster and better compared to normal engineers. Thus setting up expectation and goal become a critical part of getting to both 10x and 10% engineer.

There’s also a clear difference between setting up goals vs setting up expectations. A goal is a target you want to get into. An expectation is not only about the target, but also the mean and the velocity to get to that target.

How does knowing goal and expectation help us to become a 10% engineer? Knowing your expectations forces you to answers the why, what, when, where, and how questions of a product/project/organization. Why is the most important, and usually, the non-negotiable question you want to know. You want your how and when to be as flexible as possible. The more flexible these 2 variables are the more options open up for a more effective and efficient way to accomplish your goal compared to what’s expected. And finally, the more efficient you are to meet the goal vs expectation the less you have to work.

This is why having a good manager/leader is very important to your journey to becoming a 10% engineer. The rule of thumb to find such manager is they are managers who have managed managers (i.e. not a frontline manager). This is because the result of managers’ promotion (usually after proving their skill) is bigger roles and responsibilities, which means managing a bigger team, possibly multiple teams or organizations. One of my friends said: if you’ve ventured into management and stuck for being a frontline manager for > 4 years then maybe you’re just not cut out to become a manager.

The last thing about setting up expectations that you need to know is about setting up boundaries. In a product/project, engineers usually are not the only people working on it. There will be product managers, designers, marketing team, sales team, customer support, UX researcher, etc. As a senior engineer or above you usually will be accountable not only for the project deliverables but also the success metrics of the overall project (this also depends on the culture of the company). You need to acknowledge that engineering is only one part that will make a project successful. The project may fail because the marketing team doesn’t know the target customer. The project may be delayed because the UX researchers are still queueing on user feedback.

Sometimes you will feel the itch to help your cross-functional partner team - which generally is good behavior, but inefficient. This is the moment where you need to draw the right boundaries whether you will help (especially if you’re PM Hybrid), or just do nothing about it and possibly let the project fail. Realize that when you do nothing, you are not working (intentionally or not) - allowing you to factually work less. The art is how to accurately spot these “bottlenecks” so you can plan your downtime, but at the same time still making sure the project is successful (otherwise you’ll get fired for too many failed projects). There are a few ethical and A LOT of unethical ways to accomplish this which I am going to discuss in a separate post.

Be Super Efficient

To preface the discussion, I’d love to discuss the distinction between effective vs efficient. I like to compare effectiveness to accuracy and efficiency to precision for visualization purposes.

Being accurate means you can shoot closer to the target - being precise means your subsequent shots are close to each other. To win a game you want to be both accurate and precise. But if you have to chose which skill to practice first to get the best score, choosing to improve accuracy is better than improving precision.

Similarly, it’s more important to be effective first before you try to be efficient. Being effective means you are working toward the right goal - being efficient means you get there fast. The Effective Engineers by Edmond Lau is a great read to help us to become effective engineers. I’ll discuss my version on how to become an effective engineer in another post(s).

Now that you have considered yourself effective, what are all the different ideas you need to consider to be more efficient and turn you to a 10% engineer? I have the following non-exhaustive list:

Start with your life and make them efficient. You’ll be surprised at how many chores occupying our mind space and taking our time: washing dishes, laundry, vacuuming the carpet, remembering to pay insurance and mortgages. Your mind space and time are a very precious resource that is often neglected. Your mind space especially is very important to allow you to be creative, which allows you to be more effective and efficient. Find a way to get your daily life chores done by someone/something else.

Eliminate work using the 80:20 Pareto Principle. You don’t have to do everything. Depending on your goal, it’s ok to cut corners and accomplish 80% of the goal. This helps you to only work 20% of what’s expected. This doesn’t always work depending on what’s expected out of you, so always make sure you set up the correct expectation.

Knowledge is expensive. Gathering knowledge, be it technical knowledge, product knowledge, people’s pulse/happiness level, and domain knowledge, is a time-consuming process. You can dramatically short-circuit this learning process (I am talking about saving up to multiple years) by having 1-hour discussion with experts. You don’t want any expert though - you need someone whose communication style fits yours (so you can learn faster) and you trust (so you don’t have to double-check the information).

Find and develop your team. People are one of the oldest known multipliers to your time and effort. Put enough time to onboard, give context, motivate and course-correct them, then the right people will give you a massive return to your time investment. These people don’t necessarily have to be more junior than you. They can be the tech lead from another team. They can be the lead designer. They can be the rotational product manager. To do this need to lead by influence, not by authority.

Stay in one domain because knowledge, efficiency, and social capital compounds. In the tech industry, it’s very common to jump ship to other companies for various reasons (bored, better compensations). My advice is if you’re in the right team and company: don’t. You need the domain knowledge and social capital to become 10x engineers and 10% engineers which you only get by staying in one domain for a while. One of my skip managers at Facebook told me this:

I think it’s common for people to optimize for small money by jumping between companies, especially on E5 level below (E5 is senior level at Facebook). Then again, those are small money. The big money is in E6+ (E6 is staff level at Facebook). To get to E6+ you need to gather knowledge and expertise. You need to push the limit. Usually to get there you need to stay for a prolonged amount of time in a team or domain.

This might have been a trick to make me stay in his team for longer (spoiler: it worked). But check out Facebook E6+ compensation and compare it with other companies and other levels and you’ll know why I think he might be saying the truth.

To Sum It Up

TLDR of this post:

1. Maximize your leverage (value produced per unit of time spent) and the number of leverages to reduce the amount of work you have to do. Becoming a PM Hybrid is the best way to achieve this.

2. Set the right expectation. Not only the goal, but also the pace and the flexibility of execution you’re allowed to have. Not only with your manager, but also with your cross-functional partner (to set boundaries), your team, your skip manager, and yourself.

3. Be effective first, then be efficient.

4. Pareto Principle (80:20 rule). Apply it in all 3 points above.

When you do everything correctly, you should start hearing this conversation at work:

Your manager: “my manager (your skip) and I have been discussing a promo package for you for this half….”

Other team’s engineering manager: “thank you so much for giving opportunities to Brian to make a massive impact this year! That project shows sufficient technical complexity, cross-functional coordination, and impact for senior-level engineers. Do you mind championing him in his promotion discussion next month?”

Designer: “thank you for your insight during the design sprint! Your input saved us 3 weeks of possibly useless user research. And your idea will make the test have more statistically significant data that we can analyze compared to the user research.”

Your coworker: “please be honest and tell me - WHEN DO YOU WORK? I’ve only seen you looking at cat videos all the time at your desk!”

You’d see few points which I agree with…

1. 10x engineers can convert "thought" into "code" in their minds and write it in an iterative fashion.

…and I disagree with…

1. 10x engineers hate meetings.

2. 10x engineers know every line of the code that has gone into production.

3. Most of the 10x engineers are full-stack engineers.

4. 10x engineers rarely look at help documentation of classes or methods.

5. 10x engineers are poor mentors as they can't teach others what to do OR parcel the work.

6. 10x engineers don't hack things.

…which signifies how many permutations of 10x engineer qualities, activities, and characteristics according to different professionals in the industry. This blog is focused on 10% engineers, so I am only going to discuss the 10x engineer definition that’s related to being a 10% engineer (and the best kind of 10x engineer you should consider to be a 10% engineer).

Rather than explaining what constitutes a 10x engineer, let me give an example of what a team without a 10x engineer looks like, and what happens with one.

A Team Without 10x Engineer

A team of 3 engineers (2 frontend and 1 backend engineers), 1 product manager, and 1 designer working on a car rental marketplace. The business premise is for an individual to be able to list their car(s) for rent while other people can search, browse, discover, rent, and pay for the car.

The PM started the requirement by asking the engineering team to build a listing website with their own map and live location of the cars in 2 months. The engineers said making their own map is unreasonable and pushed back the requirement and asked for 6 months. The PM begrudgingly agreed to use Google Map instead-but pushed back that everything needs to be done in 4 months. The team then invested all the 3 engineers to build this.

Two months in and it seemed like the engineers thought we’d not get this done in time. The PM asked for more resources from leadership without asking the engineers. The original team somehow got another 1 backend and 1 frontend engineer to help but also wondered who will have the time to get these 2 new engineers on board. But at least now they had more people to drink with during happy hour.

Four months in and the project was “almost ready” according to the most outspoken engineer. After user acceptance testing, seems like the map integration was flaky, the UI had some flickering issue and the backend team insisted they want to add 100% test coverage to their code. The team agreed to add additional 2 months to get this project up and running.

Seven months in after a minor delay here and there, the project is finally ready to launch. The marketing team was ready to start sending promotions and the management team was super excited about the launch. “July 4th, that’s the best timing” everyone agreed.

July 4th. The website is public. Marketing was massive. The website was down for a while due to traffic. The team doesn’t know how many people come to the website, but it was massive. The backend engineer increased their EC2 instance from small to large to help with the load. The team ended up with 100 signups and 0 transactions closed.

July 7th. The website is not crashing anymore. But the PM kept wondering why there’s still 0 transactions. The PM asked the team to debug. Apparently, their payment integration was not working well which was never tested before because none of the engineers want to test against their credit card. The team quickly fix this with PM’s credit card and they receive 2 transactions (where 1 of them was a test transaction).

July 20th. Seems like now the website is working well. But there were only 10 transactions closed so far. It seemed like people are using the website and the demand was there, but they just can’t close the transaction. The hypothesis was the website was too complex to navigate (one of the frontend engineers mumbled “the customer is just too dumb”). Sadly, the team didn’t know where the customer got stuck. One of the engineers suggested that we put some tracking and logging into the website. He proposed the use of Firebase and Metabase to log and store the events (he heard that it’s the industry standard and it’s highly scalable). Since the team needed to research these new tools they would need another 2 months and scaled-down the team to just 1 backend and 1 frontend engineer (from 5 engineers).

September 1st. Somehow the team implemented the logging faster than expected (great job team!). Now the team understood that there was an issue with the checkout page due to the number of drop off based on the logging. It was a simple 3-liner fix. The team pushed the code and eagerly looking at the transaction number. Though right now the marketing team ran out of budget for this project so they didn’t have enough traffic to test the transaction. They had to wait for 1 month to see if their fix actually improved business metrics.

October 1st. The website started closing consistently 10 transactions/day. But the management team thought this product was not worth the investment due to the amount of time (10 months) and people (7 people) wasted on this and they want the company to focus on upcoming Thanksgiving and Christmas-related products. The PM begged the management team, promised that the team will include Thanksgiving-related work into the project. Finally, he’s given 2 months and 2 engineers to prove that this can grow to 30 transactions/day.

A Team With 10x Engineer

The 10x engineer got the same requirement as above. She wondered why the live location is important since the car would be parked in the same place for a long period of time, emphasizing that they were on different business than Uber/Lyft. She also got on the same page with the PM that they’re building a marketplace product - which means there’s a supply and demand problem that needed to be solved, possibly separately. The PM and the 10x engineer agreed that solving the demand-side was the more important problem to solve than the supply-side. They needed to design a website that’s as frictionless as possible and tested the demand.

The PM then went to ask all the team member for whoever wanted to rent their car since they agreed that they didn’t want to solve the supply-side of the marketplace yet and thus would need some inventory to break the chicken-and-egg problem (no car inventory means no customer. No customer means no one wants to rent their car). Meanwhile, the 10x engineer consulted with the legal team about whether they can use a 3rd party tool to build the website. Upon approval, she gathered a team of 1 engineer and started building the website using a no-code tool like Bubble.io. After designing the database, her team went on to spend 2 hours manually inserted the car-to-be-rented into the database

Ten days into the project, the website was done. The 10x engineered prep the website to be able to handle 1,000 traffic based on marketing team estimation by upgrading the subscription plan from $25/month into $100/month. She also integrated Google Analytics into the website even though she didn’t know what they would use the tracking for (she only had a hunch the team would need it based on her experience). While the management team was disappointed that the website only contains a listing of cars (and no way to systematically supply new cars through the website), they’re excited to launch this to the public.

On the first day of launch, everything was good. Marketing was successful and it was apparent that the website had more demand than the currently available supply. They received 80 signups and closed 40 transactions on the first day and 20 transactions on the 2nd day and 30 transactions on the 3rd day. The 10x engineer and the PM immediately planned for the next iteration: how to solve the supply-side by allowing people to upload and list their car for rent.

Software Engineers are NOT Coders/Programmers

Something critical for us to be on the same page before we discuss more about the 10x engineers: software engineers are not coders/programmers.

The closest analogy for software engineers vs programmers I can think of is comparing doctors vs nurses.

Can doctors measure blood pressure? Sure they can!

Can doctors do an infusion? Sure they can!

Can doctors do daily follow up to make sure the patients are drinking their medicines on time? Sure they can!

But why do you rarely see doctors do anything mentioned above? Because of the following reasons:

1. Some things can only be done by them and can’t be done by nurses. For example: attaching your thumb back together, LASIK operation.

2. There are more important/high-level things to do to make sure the patient is well. For example: figuring out which part of the brain artery needs to be unclogged, how to do it while preventing future side impacts, figuring out the right medication.

3. There is quite a bit of thing that needs to be done and the doctor has to delegate some of the work to someone else as efficiently as possible. Theoretically, a doctor can delegate the work to another doctor but it won’t be an efficient use of both of their time.

Similarly, not all software engineers need to code every day (or at all) to accomplish what’s expected out of them and to deliver value to the company. You might’ve heard that some engineers on the principal level just stop coding altogether and mainly contribute to software architecture and their tradeoffs.

Most software engineers started their career writing code. But sufficiently tenured engineers know that a successful project requires more than just code. To name a few you’ll need monitoring, project management, cross-functional alignment, a design that works, project momentum, and prioritization. And later in their careers software engineers are expected to deliver a good product, not just deliver a functional code that works according to the product manager’s specification.

Due to the non-trivial amount of things (and people involved) that need to happen for a (big) project to run smoothly, 10x engineers will fill a role within the project that fits their strength and help drive the project to be successful as effective and efficient as possible. These roles vary across 10x engineers thus it might be interesting to talk about the archetypes of 10x engineers.

The Archetypes of 10x Engineer

Describing a 10x engineer is tough because there are no one-fits-all activities they do day-to-day. And their qualities shine differently between individuals and teams they are in (or spotted in a team without them as illustrated above). Here’re the archetypes of 10x engineers per my observation over the years:

Generalist is a 10x engineer who breaks down complex and ambiguous problems into digestible ones by their coworkers. Then they usually will work either on the hardest or the riskiest one (but not always the most impactful one). They are well-versed in multiple technologies thus allowing them to apply themselves in the right place as needed.

Specialist is a 10x engineer who specializes in one platform or one technology that created an outsized impact. They are usually a renowned player in the industry be it a creator/big contributor of widely used open-source projects (e.g. React Native) or creator of a platform (e.g. Android, Git). People join a company just to be able to work with them.

Fixer is a 10x engineer with special power to spot a problem (not necessarily complex) and make a sizable impact. They usually know (or know how to quickly know) a domain (source code, business vertical, platform) really well thus knowing how things should work and what’s the delta between the current situation vs its most optimal version.

PM Hybrid is a 10x engineer who has great product sense and worked very closely with the product leader/PM to build a product strategy together. A PM Hybrid can often play a temporary product manager role in their absence. Their skillset is also wider (but more shallow) than Generalist, being savvier on data analysis and designs.

Coding Machine is a self-explanatory archetype. They output more code than any other engineers. A typical engineer would output 100 to 200 pull requests every 6 months (or an average of 1-2 PR/day). This person will output 1500-3000 pull requests every 6 months (or an average of 10-20 PR/day). Sadly, recurrently I’ve seen that they’re not the best teacher so the skill doesn’t seem to be replicable.

The Logistic to Become 10x Engineer

Then how to actually become a 10x engineer? Sure there are “keep coding”, “keep hustling”, “go beyond your comfort zone” tips that I can give you. But let me give you some practical ones:

Choose a company. Do NOT jump between too many jobs if you really want to become a 10x engineer. The goal is to learn then to earn (ideally both at the same time). Unless the company doesn’t have a good path to learn (performance review, mentorship, challenging projects, exposure) nor earn (promotion, credibility, bonuses), STAY.

Become a senior engineer. This is usually pretty straightforward. Most decent companies will have a path to become a senior engineer (if they don’t, see points above). If you’re the founder of the company then this is automatically achieved. The importance to become a senior engineer is not only about accumulating the skill, but also social capital within the company, reputation and opens you up to more staff level project opportunities (yes, title matters).

Spot and execute staff-level projects. According to staffeng.com, not all staff engineers need to execute staff-level projects. But to become a 10x engineer, you need to execute staff-level projects. There’s really no good way to spot a staff-level project (and a lot of time you might need to spot the potential, not just how the project is right now). But usually, it has the 3 ingredients: complex and ambiguous, multiple divided stakeholders, critical to company strategy/metrics.

Pick an archetype. It’s tempting to try every archetype. But usually, you’ll start out being good at one (due to there’s only a limited amount of time a person can work in a day). Not only it’s going to be more efficient, but you’ll also get good at “how do I get good” at another archetype as well. It’s totally possible to exercise multiple archetypes in your day-to-day work (in fact a 100x engineers will know what archetype he needs to play in a given project he’s in right now) so be flexible as well and spot the opportunities.

Recommended Reading

Here are several recommended reading if you want to learn more in-depth/case studies on how to become a better engineer/professional which will get you closer to become a 10x engineer:

1. The Effective Engineer

2. Problem Solving 101

3. How to Win Friends and Influence People

4. Staff Eng Blog

The concept of a 10X engineer is actually very simple: It's an engineer who's 10 times better at their job than their peers.

In practice you’ll wonder what 10x engineers would look like in real life (if they’re not a myth). Some folks will say that 10x engineers are engineers who output 10x as much code compared to their peers. Others will say that 10x engineers are engineers who debug and fix issues 10x faster than their peers. Some will even say that 10x engineers are engineers who drive alignment with 10x less drama than their peers. I personally think that there are archetypes of 10x engineer, in which one can be within one or more archetypes and I’d even add the more experienced 10x engineer (100x engineer?) would know which archetypes they should be playing right now.

Then, what is 10% engineer and how is it related to 10x engineer? This is my definition of 10% engineer

10% engineer is a 10x engineer who has high degree of efficiency thus only requiring to work 10% of the time to accomplish similar result expected out of them.

In short you require 3 ingredients to become 10% engineer:

1. Become a 10x engineer.

2. Crystal clear on what’s expected out of you (even if you’re the one who’s making expectation yourself).

3. Be insanely efficient.

So that seems like a lot of work, right? So why bother? Here’s an example of a week in life of 10% engineer named Vincent working at Facebook:

1. Monday: 1:1 with core team members (Vincent “manages” > 20 engineers but only do regular 1:1 with 3 of them), cross-team and cross-functional sync. Then walk his dog in the afternoon. Work hours: 3 hours.

2. Tuesday: Walk his dog. Work hours: 0 hours.

3. Wednesday: Play League of Legend. Then walk his dog. Work hours: 0 hours.

4. Thursday: weekly sync. Then walk his dog. Work hours: 1 hours.

5. Friday: Walk his dog. Then happy hour with team. Work hours: 0 hours.

6. Saturday and Sunday: not so obvious but Vincent doesn’t work on weekend. Work hours: 0 hours.

7. Total work hours: 4 hours/week.

I can personally say that I’ve seen multiple 7-figure-income engineers who’re working on the most interesting/challenging area in the company have accomplished this. And it’s not as mythical nor impossible as it sounds. Also becoming 10% engineer is not for everyone for multiple reasons. For example: not everyone know what to do with all the remaining free time they have and people can get depressed because of this.

If you’re interested to hear more on how to become 10% engineer, what are the different tools you have to leverage, or how to use the remaining time you have as 10% engineers please consider subscribing.

In each article, we usually will outline some topics and their approaches. And by the end of the article, we’ll draw an opinionated conclusion on what we should do against a specific topic.

Subscribe now

In the meantime, tell your friends!