I think he mentioned all the information in six points. A very good blog this week🙌. It’s good to have simplicity, positive mindset, helping nature and time management skills.
Hard to say. It's definitely important, but without the others, it would not have the same effect. Plenty of people are fast and then just go home early or stay doing their assigned tasks.
I left after five years, figuring it was time to try another challenge with startups.
Thanks for sharing this insightful article with six actionable takeaways. A few points particularly resonated with me. Rather than focusing on replicating Evan’s timeline, the real value lies in adopting the mindset behind his growth—a mindset that generates compounding benefits over time.
1. Speed as a Multiplier: Prioritizing efficiency in core responsibilities creates extra bandwidth for higher-value contributions, driving exponential growth.
2. No One Has All the Answers: Embracing uncertainty allows you to take initiative and propose solutions. Even imperfect ideas demonstrate ownership and can open doors to new opportunities.
3. Building Goodwill: Actively supporting others and creating win-win situations fosters trust, strong relationships, and long-term collaboration.
Evan’s journey highlights that true career growth stems not just from technical expertise but from a combination of strategic thinking, relationship-building, and a proactive mindset.
I usually hate posts like these, this is probably the first one I actually resonate with, especially #3. don't really agree with #1 though as it's basically "do your job but 30% faster than everyone else", which if everyone could do, you'd be operating at baseline speed.
This is probably the best Suggested post I've seen on LinkedIn for eng though, its totally true 👍
Yah, i hate it to as it's the "hardest one to replicate."
But it was crucial to my path, so it would be dishonest and misleading not to include it. Like I said, this isn't a playbook; just a reflection on my journey.
"Sometimes, my posts got no reaction. Sometimes, that reaction was even negative. For example, I remember one post where a veteran employee publicly stated all the reasons why my proposal was idiotic. But here's what mattered: nobody remembered or cared the next day, including me."
This excerpt stood out to me because this comes off to me as distinctly (positively) abnormal behavior. I think we underestimate how a few bad experiences can turn 99% of any population off very, very easily.
I would like to explore how you were back in college, in high school, how you were raised, etc. A personality like this is not formed overnight.
Probably the best career growth article I’ve read in a long time! Mirrors a lot of what helped me grow to senior, tech lead and beyond.
The three points that really resonated were:
1. Operate about your level - both in thinking and actions.
So key to getting to that next level. It’s about thinking at a different level and impacting at a new level - not just more coding or more of what you do now.
2. No one has all the answers.
Such a good reminder!! Took me way too long to learn this from another staff engineer. They always said “I don’t know, but let’s dive in and figure it out.” That normalized it for me and showed me a path to rocket growth. Now I focus on asking the dumb question earlier so I don’t have to remain dumb for longer.
3. Simple solutions to complex problems. 100%. It’s so easy to want to build for tomorrow or 2-3 yrs from now. Sometimes the best thing to do is the next right thing.
Sometimes a cron job might be all you need. Sometimes just picking an SLO based on past traffic and iterating on it as you hear from customers is better than spending days trying to figure out a perfect way to monitor.
The important thing is to take a step back, get more context and focus on the goal, not on the most technically advanced thing you could build.
Really appreciate you sharing your story Evan! We can all learn a lot from it.
This was indeed a good read. I recently got an offer from FAANG, and everywhere I looked, I could only see firing posts and how FAANG fires within the first few months. This kind of changed my motivation to work into spiraling into the fact that whatever I do, I will be fired.
This blog changed my perspective and mindset altogether.
Yea the internet can be a bit gloom and doom out there. I'll say from my experience the firing case is unlikely. The vast majority of engineers that join FAANG companies meet expectations or exceed them
And many of the unlikely firing cases come from people with extenuating circumstances
If you're giving it everything you've got, you're very likely to succeed. Good luck Aditya!
Thanks for the post, it was great and with good insights!
One of the points of the first (point? topic?) is also about that you had a timeframe (say that 1month+). Did you estimate that or senior staff?
I'm asking because we estimate only through story points (always had actually) so once we finish a task, we finish it, and we're not even thinking that Oh I have some more time to make it better :D I think it would seem like a waste of time on smaller companies/teams.
Do you see some suggestions in case we don't have really an ending task estimation - team-wide agreed?
Also in that case, if it's just a developer who decides by himself, how much time one can give him/herself, say 20,30% more?
Question for Evan: Can you elaborate on your process for generating, sharing, and vetting ideas? I love the example about a veteran engineer criticizing you in public and how you didn't let that stop you from pitching other ideas. Setting roadmaps and direction is part of being a staff engineer, so I'm curious about how you turn ideas into reality. Developing ideas is relatively easy, but executing can be much trickier. Any specific examples you can charge would be great, especially if they led to staff-level projects or your staff-level promo!
PS: How does Workplace work at Meta to share ideas?
Hey Evan, did learning things outside of work help you achieve the first principle of speed?
Did you regularly read up on/watch/listen to material while you were at meta or perhaps while you were still in college, or did you spend a lot of your free time tinkering on side projects?
Just wondering how you got to be a “code machine”, maybe some insight into the college years could help put it into perspective.
Hey Evan, your first principle is to finish your core work faster (70%) of your time.
"If you're not yet blazing through your core responsibilities, stop reading this article. Put all your energy into mastering your fundamental skills first."
What specifically do you do faster than others and/or what are some of the common bottlenecks you see others run into?
There's so much to learn, it would be great to get an idea of what allowed you to go so fast.
It's a good question. The reality is I'm not totally sure. It just came naturally. But I know that's not very helpful, so digging deeper:
- I was a "code machine." I wrote many multiples more code than anyone else on the team or even in the organization. So I did not spend too much time thinking about the "how," but more on the "what." I see others get caught up here in overthinking the right design pattern, etc. Of course, this is a double-edged sword, and I'm guilty of not writing the highest quality code at times. But the key is knowing when you can trade accuracy for speed and when you need to slow down and get it perfectly right. I was also on a team that was well-suited for rapid experimentation.
- I see many junior and mid-level engineers waiting for permission or doubting themselves. This is often the largest bottleneck. Just do it! Assume you know as much as anyone else and go. Then, when you get feedback, as you inevitably will, be a sponge and be humble enough to grow.
- While not something I understand or can even qualify well, I observed many engineers get in their own way. They got distracted or stuck for one reason or another, and were even discouraged at times. I'm not sure why, but it did not happen to me. I found a way to reach a "lock-in" mode where I could just crank, and I enjoyed doing it. I'm not sure how to coach someone else to find that mode, but we've all been there. So dig deep, identify what it takes for you to reach that place, and create an environment that allows it to come more naturally.
I've been pondering this a bit more, what would you consider "fundamental skills" to master. In other words, what technical skills helped you the most?
E.g. I just got two books Designing Data-Intensive Applications and The Pragmatic Programmer. But another option is to review Data Structures and Algorithms and/or intro. courses from top universities (UCB, Stanford, Harvard, etc)
Hot takes but I think books are the wrong thing to learn from. Skim them and get the key points, but the value per minute is low.
Build stuff. See how others build stuff. Contribute to open source software. Read articles. That seems much higher value than reading 200 page books front to back.
Instead of saying "books are the wrong thing to learn from", I'd say "books are one way to learn but couple it with practical application".
I think for myself, I sort of learned "system design" esque concepts from writing technical design docs for projects at work which involved talking to teams that maintain the important infra at the company to figure out a path forward. That way you can see how a system is designed end to end.
You have to fail several times to do the skill better and good orgs and managers should reward failure instead of blaming
I think he mentioned all the information in six points. A very good blog this week🙌. It’s good to have simplicity, positive mindset, helping nature and time management skills.
Is speed the trait you think is most important out of the ones you've listed? Since it allowed you to make "extra time".
Why did you quit after 3 years? You had no signs of slowing down.
Are you the mythical 10x engineer?
Great insights, thanks for sharing.
Hard to say. It's definitely important, but without the others, it would not have the same effect. Plenty of people are fast and then just go home early or stay doing their assigned tasks.
I left after five years, figuring it was time to try another challenge with startups.
Thanks for sharing this insightful article with six actionable takeaways. A few points particularly resonated with me. Rather than focusing on replicating Evan’s timeline, the real value lies in adopting the mindset behind his growth—a mindset that generates compounding benefits over time.
1. Speed as a Multiplier: Prioritizing efficiency in core responsibilities creates extra bandwidth for higher-value contributions, driving exponential growth.
2. No One Has All the Answers: Embracing uncertainty allows you to take initiative and propose solutions. Even imperfect ideas demonstrate ownership and can open doors to new opportunities.
3. Building Goodwill: Actively supporting others and creating win-win situations fosters trust, strong relationships, and long-term collaboration.
Evan’s journey highlights that true career growth stems not just from technical expertise but from a combination of strategic thinking, relationship-building, and a proactive mindset.
Very impressive and thanks for sharing!
I usually hate posts like these, this is probably the first one I actually resonate with, especially #3. don't really agree with #1 though as it's basically "do your job but 30% faster than everyone else", which if everyone could do, you'd be operating at baseline speed.
This is probably the best Suggested post I've seen on LinkedIn for eng though, its totally true 👍
Yah, i hate it to as it's the "hardest one to replicate."
But it was crucial to my path, so it would be dishonest and misleading not to include it. Like I said, this isn't a playbook; just a reflection on my journey.
"Sometimes, my posts got no reaction. Sometimes, that reaction was even negative. For example, I remember one post where a veteran employee publicly stated all the reasons why my proposal was idiotic. But here's what mattered: nobody remembered or cared the next day, including me."
This excerpt stood out to me because this comes off to me as distinctly (positively) abnormal behavior. I think we underestimate how a few bad experiences can turn 99% of any population off very, very easily.
I would like to explore how you were back in college, in high school, how you were raised, etc. A personality like this is not formed overnight.
Probably the best career growth article I’ve read in a long time! Mirrors a lot of what helped me grow to senior, tech lead and beyond.
The three points that really resonated were:
1. Operate about your level - both in thinking and actions.
So key to getting to that next level. It’s about thinking at a different level and impacting at a new level - not just more coding or more of what you do now.
2. No one has all the answers.
Such a good reminder!! Took me way too long to learn this from another staff engineer. They always said “I don’t know, but let’s dive in and figure it out.” That normalized it for me and showed me a path to rocket growth. Now I focus on asking the dumb question earlier so I don’t have to remain dumb for longer.
3. Simple solutions to complex problems. 100%. It’s so easy to want to build for tomorrow or 2-3 yrs from now. Sometimes the best thing to do is the next right thing.
Sometimes a cron job might be all you need. Sometimes just picking an SLO based on past traffic and iterating on it as you hear from customers is better than spending days trying to figure out a perfect way to monitor.
The important thing is to take a step back, get more context and focus on the goal, not on the most technically advanced thing you could build.
Really appreciate you sharing your story Evan! We can all learn a lot from it.
This was indeed a good read. I recently got an offer from FAANG, and everywhere I looked, I could only see firing posts and how FAANG fires within the first few months. This kind of changed my motivation to work into spiraling into the fact that whatever I do, I will be fired.
This blog changed my perspective and mindset altogether.
Thank you.
Yea the internet can be a bit gloom and doom out there. I'll say from my experience the firing case is unlikely. The vast majority of engineers that join FAANG companies meet expectations or exceed them
And many of the unlikely firing cases come from people with extenuating circumstances
If you're giving it everything you've got, you're very likely to succeed. Good luck Aditya!
Thanks for the post, it was great and with good insights!
One of the points of the first (point? topic?) is also about that you had a timeframe (say that 1month+). Did you estimate that or senior staff?
I'm asking because we estimate only through story points (always had actually) so once we finish a task, we finish it, and we're not even thinking that Oh I have some more time to make it better :D I think it would seem like a waste of time on smaller companies/teams.
Do you see some suggestions in case we don't have really an ending task estimation - team-wide agreed?
Also in that case, if it's just a developer who decides by himself, how much time one can give him/herself, say 20,30% more?
So much focus on titles is scary but your point are totally valid in every career path
Thank you for sharing your experience ♥️😄
Question for Evan: Can you elaborate on your process for generating, sharing, and vetting ideas? I love the example about a veteran engineer criticizing you in public and how you didn't let that stop you from pitching other ideas. Setting roadmaps and direction is part of being a staff engineer, so I'm curious about how you turn ideas into reality. Developing ideas is relatively easy, but executing can be much trickier. Any specific examples you can charge would be great, especially if they led to staff-level projects or your staff-level promo!
PS: How does Workplace work at Meta to share ideas?
1. How much did you practice or learn about programming outside your job?
2. How many hours did you work a week on average?
Hey Evan, did learning things outside of work help you achieve the first principle of speed?
Did you regularly read up on/watch/listen to material while you were at meta or perhaps while you were still in college, or did you spend a lot of your free time tinkering on side projects?
Just wondering how you got to be a “code machine”, maybe some insight into the college years could help put it into perspective.
Hey Evan, your first principle is to finish your core work faster (70%) of your time.
"If you're not yet blazing through your core responsibilities, stop reading this article. Put all your energy into mastering your fundamental skills first."
What specifically do you do faster than others and/or what are some of the common bottlenecks you see others run into?
There's so much to learn, it would be great to get an idea of what allowed you to go so fast.
It's a good question. The reality is I'm not totally sure. It just came naturally. But I know that's not very helpful, so digging deeper:
- I was a "code machine." I wrote many multiples more code than anyone else on the team or even in the organization. So I did not spend too much time thinking about the "how," but more on the "what." I see others get caught up here in overthinking the right design pattern, etc. Of course, this is a double-edged sword, and I'm guilty of not writing the highest quality code at times. But the key is knowing when you can trade accuracy for speed and when you need to slow down and get it perfectly right. I was also on a team that was well-suited for rapid experimentation.
- I see many junior and mid-level engineers waiting for permission or doubting themselves. This is often the largest bottleneck. Just do it! Assume you know as much as anyone else and go. Then, when you get feedback, as you inevitably will, be a sponge and be humble enough to grow.
- While not something I understand or can even qualify well, I observed many engineers get in their own way. They got distracted or stuck for one reason or another, and were even discouraged at times. I'm not sure why, but it did not happen to me. I found a way to reach a "lock-in" mode where I could just crank, and I enjoyed doing it. I'm not sure how to coach someone else to find that mode, but we've all been there. So dig deep, identify what it takes for you to reach that place, and create an environment that allows it to come more naturally.
Wish I could be more help here :(
I appreciate the response and article!
I've been pondering this a bit more, what would you consider "fundamental skills" to master. In other words, what technical skills helped you the most?
E.g. I just got two books Designing Data-Intensive Applications and The Pragmatic Programmer. But another option is to review Data Structures and Algorithms and/or intro. courses from top universities (UCB, Stanford, Harvard, etc)
Hot takes but I think books are the wrong thing to learn from. Skim them and get the key points, but the value per minute is low.
Build stuff. See how others build stuff. Contribute to open source software. Read articles. That seems much higher value than reading 200 page books front to back.
Instead of saying "books are the wrong thing to learn from", I'd say "books are one way to learn but couple it with practical application".
I think for myself, I sort of learned "system design" esque concepts from writing technical design docs for projects at work which involved talking to teams that maintain the important infra at the company to figure out a path forward. That way you can see how a system is designed end to end.
You have to fail several times to do the skill better and good orgs and managers should reward failure instead of blaming
Agreed. You are lucky to get that kind of work experience, can't get any more practical than that!