What's the difference between a low performer software engineer and a high performer?

This is going to vary a lot across teams/orgs/companies, so I'm going to start with a couple commonalities I've noticed across low performers in general:

• Didn't take feedback well - This led to them being unable to course correct, which was just asking for trouble.
• Uncollaborative - I don't think I have ever seen an engineer who was very active socializing and working well with other members of the team (asking great questions, helping them out) also be a low performer. When I saw engineers get cut for performance, they were either toxic and actively didn't get along with teammates or were more lone wolves that stayed in their own corner and did their own thing.

Both of the above failure modes are heavily tied to communication skill. For anybody worried about struggling with the above 2, I heavily recommend watching my series on effective communication.

Big Companies vs. Small

• When it comes to big companies, I've seen low performance from poor communication and code quality (on top of the above 2 things). Expanding on the poor code quality portion, they often had bad attention to detail in general.
• In small companies, I feel like it's more about code velocity, since that's a much higher leverage thing to do there, especially in startups. However, smaller companies have a ton of variance, so this won't be true a lot of the time - I know small companies that actually do value code quality over speed.

Do you need to work hard to be a high performer?

• Generally yes, but it's not required. I am assuming the more "traditional" definition of working hard meaning a decent amount of hours.
• Some companies equate many hours of work to quality of work, which is rough.
• In the end, software skill is largely a matter of doing, which requires time. This means that it's inherently hard to become a software engineer without spending a lot of time. I've rarely seen software engineers who just "got it" and were able to have tons of impact and growth while only working 2-4 hours per day or something.

In terms of what makes a high-performer software engineer, there is simply too much to cover: There are so many creative, deep ways software engineers can add a ton of value to an organization. If I were to pick one resource in all of Taro that covers a good amount of these skills, it's my in-depth breakdown of how I became an acting tech lead at Robinhood just ~1 month after joining.

There's a ton of nuance in this topic, so I recommend going through the related resources below as well.

Related resources:

• "Is it possible to do well at a SWE job working less than 40 hours a week?"
• "How does work-life balance shift across levels?"
• "Advice for someone joining big tech from a non big tech background?"

This is a good question but also very generic. It really depends on the level, the context and the priorities of team. The expectations & areas of focus are very different for different levels.

If I must generalize, a "high performer" are able to do two things compared to a "low performer"

• be self sufficient and able to drive large changes on her/his own.
• be able to share their learnings with others and increase the team efficiency as a whole.

In both cases, it comes down to business impact. Write and rank your list of priorities by business and economic impact. Identify the highest-ranked priorities. Talk about your assessment of business impact with your manager. Work on them all the time. Do not let the tyranny of the urgent keep you focused on low-value work.

To riff on Anna Karenina, great performers are all like; every poor performer is poor in their own way.

Somewhat tongue-in-cheek, but these things are all true of high performers:

• Higher impact than others of the same level. (Remember, all performance is relative. Any high performer would be a complete dog if you promoted them to the right level.)
• Responsible / reliable. You don't doubt they'll get done what they say they will.
• Great collaborator. Increasingly fewer companies continue to value high-impact jerks.
• Great at self-improvement. Alex's comment about taking feedback is spot-on here. The best performers are self-aware, accept others' feedback, and implement feedback effectively.

But poor performance comes in all sorts of shades:

• Icarus. People who ask to be promoted too aggressively will likely land at a level they can barely compete in. Since all performance is relative, getting promoted too quickly is one of the fastest ways to become a poor performer.
• Self-unaware. There's a t-shirt that says, "The only common thing in all your failed relationships is you." Setting the joke aside, there's some real wisdom in there. If you could instantly accept and implement any piece of feedback given to you, you'd be an amazing superstar. The fact is that people don't accept feedback half the times, and the other half, they struggle with implementing said feedback.
• Motivationally challenged. "There are no boring things. Only boring people." Anybody who thinks it's their manager's job to make their job interesting is going to struggle long-term. Smart people are curious and they find the interest in nearly everything. You need to have your own goals and a strong drive to succeed.
• Lackadaisical. If you're just as smart as everyone else, and you work just as hard as everyone else, you're average. By definition — not being cheeky. When I started at Microsoft, I had a sleeping bag in my office and worked ridiculous hours. While I now view that period of my life as foolish, you can bet I outperformed everyone else my level, and by a significant margin. Anyone telling you that you can Have It All™ — work only 40 hours a week, marry a supermodel husband/wife, have IPO after IPO fall on your head — is selling something. You will outperform others only through three means: 1. luck, 2. talent, and 3. hard work. You can't control 1 or 2.

There are way too many other ways to be a poor performer to continue listing them. But I hope this is a helpful start.