One of the hardest tasks as a leader, manager of developers is to perform performance evaluations and assessments. How do you really assess technical performance taking in consideration their experience and seniority? After all, it's important to provide feedback to your team and to receive feedback in turn. Many managers really hate this part of the job. It can be stressful when you aren't looking forward to delivering feedback that is less than completely positive. Even when the feedback is positive, you might still have anxieties that your feedback will not hit the mark with your developer team members. Either way, we want to avoid conflict, right?
It's part of your job description to do performance reviews, to improve the health and performance of your team or teams. It should be your goal to go into a review meeting with sound reasoning to back up the feedback you are going to provide, good or bad. For this article, we are going to discuss ways to setup your review pre-work and provide observation points to support your assessments prior to your reviews. Brace yourself. This is going to be crash course of high level ideas that merely touch the surface but that outline a plan of action.
The Initial Meeting - Goal Setting
The first step in the process is to meet with each member of your team. In these meetings, you want to determine what motivates and fuels their desires about this role, this company, and their future. I know it feels like a lofty task but you need the information. Clearly outline that you want this to be a give and take situation. If you understand their expectations and aspirations, it will be easier for you to help set them up for future success. In return, you are asking for their best effort to help the team achieve the company's goals.
Here are a couple of things for you to chew on:
Turnover in tech is high. For lots of reasons, people move on from one gig to the next. Some estimates show this could be as low as 12-18 months before a team member jumps ship.
You are more likely to accomplish team goals when there are shared interests between you and each member of your team.
Understanding that a team member's future goal doesn't always include working for you or your company long term is not a bad thing.
You are facing the facts of high turnover in tech and your company is not immune. You have a team that is performing but maybe not as well as it could be. You have ridiculously high goals set by the company and passed to you as development outcomes. To meet expectations and deliver, you need complete buy-in to, which you are unsure you have or that you know you are missing.
Here's what I would do in this first one-on-one meeting.
Set the expectation that the meeting's purpose is for you to understand their motivations and goals for their short and longterm career progress.
Outline the team goals and importance of each developer to play their role in helping the team reach these goals.
And finally, the big one. You promise and stand by your word, to help them obtain their future goals. You will find ways to get them experiences that will help them earn resume points to build the qualifications needed for their next role. But in return, you need their 100% effort for as long as they are here on your team.
Outcomes Expected
Next you need set actionable and measurable goals. This is joint process where you both agree on success criteria for short and long term goals.
Short term goals - are what you want to have completed by the next checkin or quarterly if on a yearly review cycle.
Long term goals - are main objectives for the review cycle or end of year
Your developer needs to agree and commit.
I want to add a couple of things for clarity here. You only need to set the checkin/quarterly goals for the upcoming quarter or check-in. These are near term goals and it would be nearly impossible to set for each quarter ahead of time and have them align with the year end goals.
One last thing about the goals. This is a back and forth and you have the final word on setting goals. If you disagree or believe you need more in terms of an accomplishment, then stretch or change the goal while providing your reasoning. You need to challenge your team in goal setting otherwise you will be disappointed and have doubts about the effort your team gives you. Take the time now to ensure future happiness all around.
Check-ins
You need check-ins to assess progress and and course correct with your developer. Schedule these to be quarterly at the minimum if you have a yearly review cycle.
As we all know, company goal and priorities shift, which impacts you team's goals. You need to use your check-ins to modify or change the short term goals to align with company priorities.
Remember that you and your team are on the same side. Changing goals to align with new company priorities is the right thing do as soon as possible. No one wants surprises with last minute bombs that could have been handled sooner.
Gathering Observation Data
You need to observe and provide developer feedback throughout the review cycle. There are a few movings parts to discuss here.
Share the observation responsibility - You are going to have the developer maintain a "brag sheet". This is where the developer records how they were able to meet each goal outlined and when. Your job is to validate them. In some cases, you may learn about things you didn't know had occurred for your team's benefit.
Observe Engagement and Skill - You need to figure out how engaged the developer is. How does the developer rank up against the rest of the dev team. If you aren't doing sprints and task estimations, this is going to be way harder for you so I advise adopting sprints or at least task estimations and durations. Make this easy on yourself and have 3 levels: hard, med and low effort. You don't need more level than that.
Have your developer voluntarily do the hard work for you - Put the power in your developers hands to show you what they can and are willing to do for the team and themselves. Allow your developers to pick the tasks they will do each sprint. Obviously, if you disagree on who should do a certain task, have the discussion and make sure the right person is doing this task. Outside of that, you let them choose. You will learn a lot from this process.
Observations you can expect
[King/Queen bee] The one or ones who believes it's their right and obligation to choose first and the hardest/most observable tasks each sprint.
[All-a-rounder - "Jack of all trades"] The one or ones that can work on all parts of your stack, project, application and never complain about comfort zones.
[ I Just Do What I'm told - drones] These members are reluctant to take tasks but instead wait to be gifted tasks by the team.
[Under the radar "Minimum Bar is My Standard"] These members are only willing or able to work on the easy low effort tasks, every sprint.
Important: All tasks must be completed and satisfy "done" critieria. You are not running a "best-efforts" task policy. Your team is the "we get the job done" crew when it comes to task completion. One you take a task, you finish the task, on time and by the end of the sprint. This must be stressed. Your official stance should be "Don't surprise me". You don't want to get to the end of a sprint and hear for the first time that tasks are not completed due to dependencies, or other tasks that hijack your sprint.
Making Sense Of Observations
With the tasks divvied up, the next part is seeing how this plays out over several sprints. Warning, you are going to witness a range of "the good, the bad, and the ugly".
The good - You want the the boring stuff as the baseline. This means everyone is completing tasks and overcoming obstacles for the most part. You will also have developers complete tasks that you thought were underestimated in sprint planning. You also might see a junior developer grow during a sprint to a more confident team member because of their ability to complete tasks. It's great to developers become bigger contributors to the team.
The bad - You are going have tasks missed. Some of which are viewed as important baselines for subsequent sprints to build on. If there are any positives here, it would be that in some of these cases, you were alerted early and had time to modify or adopt the task to something that could be completed during the sprint. Still not ideal, but you can't always predict what might cause a task to suddenly become unachievable in a sprint. Knowing before a sprint ends is probably the best you can hope for.
The Ugly - The biggest offense will occur when the task expected to be done is not done and you discover it is nowhere near completion. Your developer didn't even mention the possibility the task would not be completed during the sprint. You feel partly at fault because you didn't follow up enough to see the train go off the tracks. It becomes even uglier to realize it was the dependency for other tasks which will now be delayed. As you might imagine, all of your surprise in the ugly category have big, observable, and will get attention from stakeholders upset at the delays and impact on overall delivery timeframes. Big problem. Dropped on your plate. Implied message. You need to fix this asap! No one above cares what happened or who was at fault. The buck stops with you and it's on you to fix it and regain stakeholder confidence. You really don't want to be in this situation.
At this point, you should be able to chart these observations. Tasks completion rates, average effort levels and even average efforts per developer and seniority. You now have a blueprint to use. If you are consistent, you should begin to see patterns. You can use these observations to improve and coach your team and individual team members over successive sprints. Your observations are an important part individual check-ins. You want each team member to see this data and how it is affecting progress toward meeting their goals. You want them to be accountable and aim to improve.
Conclusion
This is your blueprint to use, modify, or drop. Please realize that I didn't cover these steps in the detail each one deserves. It would have made this post into a handbook. The purpose was just scratches surface on a framework you can adapt to your team. If you want more thoughts and a deeper implementation plan, reach out to me. I would be happy to discuss how to make it personal to your team.
One of the realities of running a team is that not every team member will make your team better with them on it. It's up to you to see this and get more from this team member or decide if you need to make a change. The flip of this is that your observations are the key to seeing and adding more concrete data points as to why these are the most productive members of your team. Finally, you will gain insights on why your team is "killing it" or struggling to hit objectives. It is also important to state any observations can have many factors that affect how you might judge its true success or failure but you have the data to now investigate. I hope you found this useful and I am happy to discuss how to can shift the levers to get more performance from your team if you have questions.
Comentários