The art of assessing people and their suitability for a role is something that you can improve at over time, but will never fully perfect. It's functionally very similar to hiring, but over a far longer period and with many more data points.

First thing to establish is the criteria. Your company may have an established ladder in which case all well and good; if not, this section will go into the basic tech roles and offer quick crib notes for over/under-performance for each.

You want to split your assessment into functional, behavioural and growth potential. You don't need to score these - this isn't a test - but you should know enough about each person to say whether they're over, under or at the functional and behavioral bar for their level, and what their potential is to grow to the next level. From assessing strengths and weaknesses you can write a good summary and provide actionable feedback.

Note that "for their level" is critical. This isn't a single stack rank; if you're comparing people, make sure you're comparing fairly.

First thing to say is: these assessments will become second nature to you over time. You'll develop a strong sense of where people are over and under-performing, and what expectations per level are.

The reason for that is there's no magic to it: level guides represent a fairly standard career trajectory that isn't special or specific to engineering. It's just that people took time to define it better: in an industry of engineers you shouldn't be surprised there's a push to make deterministic system from something as inchoate, qualitative and bendy as "your career".

Let's dive in:

• Junior Engineer. Learning and developing. Start building expertise in one stack, expect development in code quality and organization, good response to feedback, learns quickly. The best junior engineers are extremely keen to learn, but also able to listen.
• Mid-level Engineer. Workhorses of engineering teams. Consistently deliver high quality output, and will start designing their own software of increasing size and complexity. Code standards are as good as they'll ever be but breadth of experience is still developing.
• Senior Engineer. Can deliver complex things across different parts of the stack. Comfortable with product and design ambiguity. Authors complex design documents and leads reviews with technical and non-technical folk; shows consistently good judgement.
• Principal Engineer. Can deliver the biggest and most complex things, and works across multiple teams. Actively looks for new, high-leverage things to work on: technical platform, fitting technologies to business problems. Has the influence necessary to get other engineers to adopt new things.

If the cause of low performance is not acute you can’t expect an acute change. Acute performance issues feel great to solve. Maybe the person is struggling with a personal issue and you just need to give them some time away, or there’s a misunderstanding to clear up, or something context was missing. Clean, straightforward, permanent solutions that take effect quite quickly.

But then there’s the vast majority of the rest of the cases that aren’t acute. Ones that require coaching, regular check-ins, behavioral changes, and gradual improvements over time. We all want to help these folks, we feel compelled to even, but we’re here to tell you, it’s usually not worth it. As a general rule all of your feedback, nudging, and guidance will get you a max 10% improvement over the long run. So you need to decide upfront if it’s worth it.

This may sound harsh but its one of the biggest traps of early managers fall into, believing they need to spend the bulk of their time on low performers to coach them up to be high ones. Not every person can be a high performer on every team, it’s natural. Look no further than your favorite sport, players move around to find the right team for them to play their best!

Uncover the core issues affecting the low performance and if they can’t be acutely addressed they’re unlikely to change more than 10% with any amount of effort by you.

When new folks join your team you of course want to be supportive and help them get up and running, you definitely should do that. But this is also a critical time in setting up what your and the team's expectations are, what normal is, for performance. It's easy to not pay attention, or to cut a lot of slack because they're new or they're still learning. But you should be doing the opposite, paying incredibly close attention and spending extra time with this person to ensure they're off to the right start.

There's also a few helpful tips we've found:

• Pay close attention to when the first PR is created. If it's in the first day or two, great. First week, okay but that's also a sign to look a little closer and understand why. Longer than the first week? An absolute sign to dig in closely and address any issues now before they become normal.
• If people are routinely taking around a week or longer to get their PR then it's more likely your problem than theirs. Fix your onboarding. (We repeatedly learn this the hard way. You think it's a one time cost but it's actually a signal of the complexity of your system and how hard it is to work in.)
• Set a calendar reminder for 6 weeks after someone starts. Do your own assessment of their performance. 6 weeks is long enough to get meaningful work done, but not so long that someone isn't open to adjusting to the new team still. If it's not going well, this is a good time to make some major changes, maybe a new project or even a new part of the team. Repeat again after 6 weeks, and if it's still not working out then maybe that person just isn't a good fit.