The Engineering Rating Bell Curve
Don't be on the left. Get to the right.
As a software engineer (and I assume most jobs) your relationship with your manager is incredibly important. You almost always need positive feedback from your manager in order to get promoted. So it is important that your manager view you as a valued contributor on your team.
As with all things where people are involved, engineering performance tends to land on a bell curve. This post will generally be directed toward people who are currently in the middle of the curve, and are looking for tips getting further to the right. My guidance is also biased towards engineers working in a corporate type of environment as opposed to a startup environment (though the tips should be helpful regardless).
On the left, you have the lowest performers in your organization. In my experience, people on the left of the curve tend to think they should be somewhere in the middle and are often clueless about their poor performance. In one situation, an engineer on my team came from a company where little to nothing was expected of him. He carried that mindset into my team. In the worst situations, I’ve seen engineers with 0 accomplishments during their entire tenure with a company. Engineers far to the left generally don’t receive raises and are often subject to performance improve plans and terminations. My observation is that people tend to be on the left due to laziness instead of incompetence. In other words, incredibly smart and knowledgable people can end up there. Don’t be on the left!
On the right, you have the highest performers on your team or in your organization. These engineers are highly reliable, deliver independently, and have a long list of accomplishments. These are the people your management hopes to promote quickly.
And of course, most people fall in the middle of the curve. But even the middle has a left side and a right side. At high performing companies, these distinctions are important. Being in the middle-left might be similar to being in the far left if your company is looking to reduce headcount. Being in the middle-right might be equivalent to being on the far right if you’re on a high-performing team.
Getting further to the right
Your first step is figuring out where you are on the curve. Your company might have an official mechanism or tool for this. If so, you can use that to determine approximately where you are. Otherwise, you should speak with your manager and potentially your skip level manager to find out where you land. If your manager for some reason won’t tell or you think they might not be as forthcoming as you’d like, try to estimate where you compared to the rest of your team. (note: managers tend to be more forthcoming with their highest performers). Do you ship more or fewer features than the rest of your team? Does your manager go to you or others when they have important work to be done? Are you able to help others on the team more than you require help from others?
Remember, it’s OK if others on the team are stronger in some or many ways than you. You generally want to be on a team where you can learn from and be inspired by others.
Ask your manager what you need to do differently to get a higher performance rating. If you’re in the middle of the curve, and you ask this of your manger then you might be surprised at their response. At my first full-time job as an engineer, I thought “writing a lot of code” was the most important metric. It turned out that anyone on the team could write a lot of code, but only a couple of people on the team were trusted to release the code.
At another job, I was on a team with an engineer who was a pull request machine. He would find the easiest tasks in the sprint and quickly pump out high quality pull requests until there were no more tasks. However, another engineer on the team was promoted before him because they were better at supporting engineers from other teams. In other words, their non-coding skills like “feature design”, “prioritization”, and “building rapport” were weighted higher than coding ability. Additionally, positive feedback for an engineer from outside of your immediate team is often more strongly weighted than positive feedback from engineers within your team. The incredible coder on my team lacked positive feedback from outside of the team.
Do what your manager told you to do. Once you’ve identified what it is you need to do to improve your performance, make a habit of doing it!
Getting to the far right of the curve
Depending on where you work, your company likely has at least some extraordinary engineers. If that is the case, then simply following your manager’s guidance might not be enough to get you to the far right of the curve.
Here are some qualities of top engineers I’ve observed:
Their leadership goes to them for help. Every manager or director in software has engineers that they trust for help and advice. These people tend to be the top performing engineers on the team or organization.
They quickly recognize bad decisions based on past experience. For example, I presented a design to an incredible engineer who I worked with at the time. The design included a short-term solution that was a bit of a workaround until a long-term solution could be identified. The incredible engineer immediately told me that I should assume the short-term solution would be around forever. He was right! This totally changed the way I approached the problem and sent me back the drawing board.
They are incredibly detail oriented. If you present them with a big idea that you’ve thought through already, they’ll recognize quickly that the idea is fine and dive into areas of the implementation or execution where you might run into trouble. For example, an engineer I was working with put together a design and asked 1me to review it. In the design, the engineer assumed they could access some data via an API. They were correct, but the API was more of a control plane API (pretty low traffic) whereas the API he was designing was clearly a data plane API (high traffic). Thus, his design needed to include ensuring the existing control plane API could be made ready to handle the additional volume.
They think in terms of trade-offs, including business trade-offs. Even well-accepted best practices in software engineering should not always be followed in certain circumstances. Top performing engineers understand this and can articulate to leadership and engineers when conventionally good ideas should not be implemented. A good example of this is understanding when a process should be automated vs. having the manual steps documented. As someone who used to manage a DevOps teams, I believed for a while that everything should be automated, but this isn’t actually the case. For instance, if a process is only performed once a year and can be reliably performed by reading some instructions, then it likely isn’t worth the time spent automating it. How many times does the automation need to be run to cover the cost of the automation development effort? Additionally, you want to think about the opportunity cost of having an engineer write the automation. If you’re automating something that rarely runs when there’s innovation work needed, then maybe you’re doing the wrong thing.
Closing thoughts
One thing I think about is the situation where almost everyone on a team is pretty equally high performing (toward the right). This can actually happen and does happen. I have actually seen teams formed by taking top engineers from other teams and placing them all on the same team. If you put these people on the curve, they might all end up in the middle. If they are then compared with lower performing team, then the comparison will not be accurate or fair. In these cases, the manager of the high performing team should put the engineers toward the right and justify that placement with their management. The team may need to have many accomplishments to justify this sort of placement, but it’s the correct thing to do.
As an engineer, if you have a choice to be on a team with many other high performing engineers or a more “curve fitting team”, then you should try to be on the high performing team. You might not standout on your team as much, but you’ll improve faster than you would on the more normal team. Additionally, if your company is good, they will recognize your team as exemplary and place engineers (hopefully) according to how I described in the preceding paragraph.
Yes, I’m using myself as an example of a “good engineer” here. I don’t think I’m a “far to the right on the curve extraordinary engineer”, but I’m working on it!