Now that I’ve transitioned to management, I’ve found myself becoming a person I never thought I would be. I like fitted blazers. I wear trousers instead of skinny jeans (sometimes). I go to the gym. I like goals. Ugh. Who even am I?
I’m a firm believer in setting good professional goals. They have to be measurable (duh), but most importantly, they have to be a living document that you maintain with your direct report.
Once you set up good goals, it becomes extremely easy to track a person’s growth, surface issues before they become a big problem, and make performance reviews easier. However, most people hate doing them. This is my current process for making and updating goals.
Setting initial goals
Treat goal-setting as a pairing exercise. I ask my direct reports to open a markdown file in their GitHub repository (or Google doc) for one quarter. This is to gauge what kind of things the person initially is interested in, without my input.
We set up time at the beginning of the quarter (or end of the quarter) to walk through these goals. I bring up the engineering levels of the person and we go through them to see what kinds of things they excel in and what areas could use some work.
Then we work together to create measurable, time-limited goals (with checkboxes!) for the quarter based on their original goals and the engineering goals. (i.e. “Fix 6 bugs off the bug board this quarter to help with technical debt”) When putting together estimates, I make it clear that these can always change based on changing circumstances.
Monthly follow ups
The most important part of this process is the monthly follow up. I set a reminder on my calendar (I use OmniFocus) to review goals once a month to make sure they are still relevant. For example, if a person stated “Fix 6 bugs off the bug board this quarter to help with technical debt” but has spent most of the first month working on a very complex feature, then we might reduce the goal to “Fix 4 bugs off the bug board this quarter to help with technical debt and ship 1 major feature”.
It’s also a good way to surface problem areas. If a person commits to fixing 6 bugs in a quarter, but they haven’t gotten any started, what is the cause of that problem? Was the onboarding not thorough enough? Are they having problems with their local development machine? Are the bugs too hard than their current level? Interpersonal issues?
I also use this time to add any additional projects the person has been working on (i.e. committees, Employee Resource Groups, any kind of invisible or emotional labor) to make sure that it’s documented, or any interpersonal concerns I’ve noticed over the last few weeks. It’s ok to write them pre-checked. The most important thing is documenting changes as they happen!
Annual reviews rollups
With all of these past notes, it makes writing reviews much easier, makes it clear if too much time is spent in any one particular area, and helps guide the person to work on areas they may not naturally want to work on.
It also makes it much easier to spot if they’re available for a promotion, since it clearly shows where they are in the engineering levels.
I hope this helps you out!
Image source: https://flic.kr/p/8jvw78