Note on mid-year reviews

Around July, it is time to realize (non-mandatory) mid-year reviews for our team members. Here are a few thoughts on this matter, a quick article that might apply to many organizations.

Our routine is divided into quarters, each three months in length. No big surprise here. Q1 throughout Q4 every year. Projects are usually bound to a quarter, and even if they can vary in length and size, it still represents quite a bit of work for every team member.

The global idea here is for the developers and their leaders (EMs) to keep track of their work every quarter between the official projects as well as their direct/indirect impact on the team or the organization to be able to build a comprehensive performance review at the end of the year. As an EM I keep a global track of this work and let them fill the more indirect tasks.

To do so, I encourage each developer to keep a work log of their daily deliveries and impacts. It can be a feature, a fix, a pair programming, and so on. It usually gets more complex with every level of seniority (doing a PR review vs delivering the complex design of the next authentication project for the app). You get the idea.

From this work log, at the end of the quarter, we do quarterly checks. Also called self-assessments, it is a review of the quarter, within a page, with the main deliveries in production and impacts.

And once you have two self-assessments, it is time for a mid-year review.

In this doc, I gather the main deliveries and impacts of one collaborator as well as realize a global (6 months) feedback. I usually focus on the past, not on future action points.

Once this review is done, I book a specific schedule (or use an incoming 1:1) to pass the feedback and align with the developer if a thing is missing or not aligned.

It is a very good exercise, in my opinion, to show the value of the work log and self-assessment to each team member and remind them that over the next six months, we will do two more quarterly checks (yup, self-assessments, I'm just switching over and over) as well as one end-of-the-year review (another mid-year if you like) to compile the final annual performance review based on existing documents and not memory.

It also helps a lot if one developer or even EM switches teams during the year. With all documented, you and the developer do not lose information along the way.