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

Profile picture
Forward Deployed Software Engineer at Palantira year ago

Some additional questions:

  1. Does it vary between big companies and small companies?
  2. Do you need to work a lot to be a high performer?
116 Likes
9.8K Views
5 Comments

Discussion

(5 comments)
  • Profile picture
    Robinhood, Meta, Course Hero, PayPal
    a year ago

    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 this: Alex's Guide To 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 my rapid Robinhood onboarding: [Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

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

    Related resources:

    98 Likes
  • Profile picture
    Staff Software Engineer @ DoorDash, ex-FB, ex-Klaviyo
    a year ago

    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.
    37 Likes
  • Profile picture
    Comstock Software, Inc
    9 months ago

    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.

    22 Likes
  • Profile picture
    Ex-Microsoft, Ex-Meta, Ex-CEO of tech nonprofit
    7 months ago

    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.

    49 Likes
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    6 months ago

    Taro has come a long way since I originally commented on this post, so I have a bunch of new thoughts. In particular, I didn't cover high-performers too much before, so I'll do it now.

    When it comes to high performers, there are 2 big core traits I have noticed:

    1. They are exceptional at learning from others from them, both directly and indirectly.
    2. They develop higher-level skills that are applicable everywhere across any team, any tech stack, and any given situation.

    Learning Through Osmosis

    By being able to quickly absorb good behaviors, expertise, and skills from their peers, this makes it so that once a high-performer finds a great team, they are going to grow like a rocket ship. Here are some excellent resources covering this:

    Developing Better Skills

    What would you rather have:

    • 1 skill that makes you tremendously useful in 1 type of situation?
    • 10 skills that make you at least moderately useful in 1,000+ different types of situations?

    The first is a common failure mode for struggling software engineers: They focus too much on the tech and only become good at 1 specific tech stack (i.e. the one used by their team). Sure, they're the most useful person in the world when there's a tricky task in Python 2.7 and they have written Python 2.7 for the past 10 years. However, this also means that when they're put in a non-coding situation or a different team, their usefulness plummets to near 0.

    The second is what rockstar high-performer engineers do. Of course, they'll develop the technical proficiency to accomplish the tactical parts of their job, but they're also getting good at skills like communication, building relationships, and time management. This means that no matter the situation, they have this solid bedrock of fundamentally useful skills to fall back on. This allows them to always add value, whether it's through effective project management or asking insightful questions.

    To learn what more about those fundamental skills, check out these awesome resources:

    27 Likes