10% Engineering Ingredient: Set The Right Expectation
Not too much, not too little. Just right
The final ingredient (and probably the most controversial) out of all the steps to become a 10% engineer is setting the right expectation. To correctly set the right expectation, there are two things you need to do: have the correct setup and manage them.
If you want to become a 10% engineer, there are three setups in your control that you need to have:
Stay in the right company
Work with the right boss (manager, investor, or yourself).
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):
Set expectations for your work
Provide the proper material support (laptop, licenses, devices) for you to get the job done
Play favorite and have “heroes” for each role
Utilize people strengths and weaknesses (vs. assuming everyone should perform and act the same way)
Build a culture of recognition and appreciation
Give timely feedback in a manner that you can accept
Care about your life beyond work
Encourage skill development and allow (or even encourage) failures
Listen
Build a culture of quality and high-performing team (which also means firing low-performer)
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:
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.
Work with a product manager comparable to IC5 (senior level).
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.
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: