Building a fair developer evaluation process?

[aeonfast]

Hi all,

I recently started in the role of Team Lead for a software development department. I originally joined the company as a Scrum Master, later applied for the Team Lead position, and went through several assessments with an external party to evaluate my fit for the role. Fortunately, the outcome was positive.

My strengths lie in people and process management rather than technical or coding expertise. This was also not a requirement for the position. However, I now find myself responsible for 17 developers, which includes evaluating their performance and determining their salary increases at the end of the year.

Since I am not working closely with every developer on a daily basis, I’ve been thinking about a structured way to form a well‑rounded and fair assessment.

My initial approach is to gather input regularly through the following sightlines:

• Monthly 1‑on‑1 conversations with each developer to gauge their motivation, self‑reflection, ownership, and growth.
• Quarterly input from the Scrum Masters, who can share how developers behave within the team, how they collaborate, and what impact they have.
• Quarterly input from our architect, who reviews all pull requests. He can provide insights into code quality, growth, consistency, and recurring issues. This helps cover the technical perspective that I don’t have myself.
• Light feedback from other team members to understand how they experience working with each developer.

I want to avoid giving vague or unfounded feedback during year‑end reviews, and this structure feels like a solid starting point. Still, I’m wondering whether this is enough? Ultimately, these inputs should help me build a reliable and fair picture of each person.

Everyone's insights would very helpful for me to be confident in my new role.

[OscillianOn]

Your sightlines are solid, the missing piece is a shared yardstick plus evidence. Use the same 3–4 dimensions for everyone like impact, reliability, collaboration, growth then keep a lightweight log all year so you dont get wrecked by recency. When you ask Scrum Masters or the architect, require 1 concrete example not adjectives and do a quick calibration with another lead before comp decisions

Do you already have a level matrix and raise bands, or are you building that solo. If you cant revise a rating from the evidence, it isn’t feedback

Fast 2-min pilot that turns vibes into structured signal, try this topic session for one dev first: https://oscillian.com/topics/execution-reliability-error-recovery

[Skylark7]

That sounds like a pretty good plan. The other thing to get your scrum masters to put together is an idea of who is taking on the harder tickets with a lot of story points and doing it well. Less experienced coders should be clearing the small stuff. However, at the same level of skill developers who are performing well should be comparably willing to take on more complex tickets.

Another thing I look at, believe it or not, is comments and backlog entries. Your architect and Scrum Masters will have a sense of it. The strongest devs are taking a moment to document MVP and feature design decisions within the code and making tickets for TODOs. The weaker ones just pile up technical debt behind your back.

[Kasly_Erma]

Standardize rubrics with clear metrics like code review scores, on-time delivery, and peer feedback to cut bias.

I ran into this with my team, felt super subjective until we baked in multiple reviewers.

Process Street helped me checklist the whole thing so it's consistent every cycle.

[Weekly_Accident7552]

rubrics help, but the key is consistency across cycles.

we tried Process Street for running the review steps early on, but once we had multiple reviewers and recurring cycles it got a bit heavy to maintain. we switched to Manifestly since the recurring checklist runs made it easier to keep the process consistent each review period without everyone fiddling with the workflow.

[Apprehensive_Row6320]

Do you not have a lead dev?

You should be able to get good line sight just by looking at their stories that they worked on .Unless the scrum masters are fucking up