Performance evaluations

Reading Time: 3 mins

New managers are left in the lurch with no formal training in how to manage their reportees and evaluate them.

This post discusses about the evaluation aspect. I created a set of rules picking partially from my prior evaluations by Anand, Sundeep, Kathir in the last two years and partially from project experiences.

Guidelines during the review

1) Ask how the past year went. Delve on what they think went right and wrong.

2) Ask about good and bad experiences they might remember currently. Look if anything sticks out, acknowledge the good ones and promise to fix the bad ones.

3) Ask if they think their skills are being used to full extent. If so great and ask them to continue doing that and add new skills. If not understand why, make notes to course correct as long as the skills are relevant to our workflow.

4) Ask what two things they think that they or the organization should be doing to make good impact in dealing with people or improving workflow.

5) Review their smart goals. Add/delete as necessary. Set at least 4 goals. Setup periodic reminders to review progress.

6) Review their self-review ratings, comments. Ask why they rated themselves so (if anything less than 5). If you’ve evaluated them by now agree or counter the score by evidence (and not by hunches or anecdotes).

7) Ask feedback on your managerial style. To improve personally managers should know their blindspots. Insisting on this will reveal quite a bit.

8) Chances are people will invoke their project work in (1) and (2). If not mention their contributions explicitly.

Preparation before the review

1) Email everyone and request them to come prepared for the discussion by reviewing their current smart goals and how they’d like to update/add them/more for next year.

2) Review their self-evaluation and prepare your feedback.

3) If you’ve not worked with them take as much feedback as possible from the folks they worked with for discussion points.

During and after the meeting

1) Listen. Take notes. Ask questions. Pass on feedback.

2) Look for action items that’ll help their workflow at Gramener.

3) Tell everyone to setup monthly catch-up discussions, 1-on-1 with you.

Feedback for me

After reviewing seven people and co-reviewing three more, I’m accumulating feedback here:

1) Ability to resolve inter-people issues. People feel comfortable with sharing issues. Positive.

2) Ability to assist with project management. Positive.

3) Should be available for the team more. As I keep contributing to projects the suggestion was to reduce coding. Negative.

4) Training for freshers should be improved. More exposure on Gramex utilities (FunctionHandler, FormHandler). QuickStart Guide isn’t sufficient. Negative.

5) There’s good transparency in how we (projects I’m part of) operate: regular meetings to resolve blockers, project related (deployments, business logic, Bugs meet) documentation. Positive.

6) Great support to grow the career. This was missing in previous organization. Positive.

7) Periodic meetings with UI team to know their challenges, project experiences. While I was relatively aware of other negative aspects from earlier this one caught me off guard. Negative.

Looking out for Development Process improvement

Multiple people have confirmed this new trend: developers completely rely on UI team for anything layout/CSS related issues and on charts team for anything Vega related issues. While this highlights the importance and skill of speciality teams it also reveals the excessive dependency.

Current training seems to work well for people with advanced degrees perhaps due to better exposure to web technologies. It doesn’t seem to be otherwise. We need to address this.

Lack of communication between consultants and UI team is leading consultants to notify issues to QA team instead of checking with UI team first. This may happen due to tight deadline or an immediate client meeting. A related request is to have design review after scaffolding in addition to after data integration and development.

Developers who are allotted for maintenance projects (they inherit a codebase) alone feel deserted. Bandwidth should be created to contribute on new projects. Project managers perhaps can help in allocation here.

Each person’s evaluation meeting of 1 hour involves at least an hour more of preparation work. And I didn’t even get to looking at individual contributions (coding standards, time estimates, feature contributions, quality of builds etc.) in different projects.

There’s a lot to chew on here. If you’re in a position to make a decision please do it if not raise it to the concerned person.

Note – This content is intended only for Gramener colleagues, thoughts are time and space bound. Posts cannot be reproduced anywhere.