Setting goals with your engineers that don’t completely suck
Now that I’ve transitioned from being an IC to being an engineering manager, I’ve found myself becoming a person I never thought I would be. I like fitted blazers. I go to the gym and eat kale. I like goals. Ugh. Who even am I?
Now that I’m somewhat more of an adult, I’ve discovered 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, version-controlled document that you maintain with your direct report.
Once you set up good goals, it becomes extremely easy to track a person’s growth, document emotional labor, surface issues before they become a big problem, and make performance reviews easier. However, most people hate doing them (I certainly did). 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. It doesn’t matter where, just make sure it’s got some kind of version control. Version control is important to maintain a log of what you and your engineer have discussed. Accountability helps both of you in the long run in case anything goes wrong.
This initial goal draft is to gauge what kind of things the person is interested in, without my input. They don’t have to be complete goals, just as long as there’s something.
We set up time at the beginning of the quarter to walk through the first draft they wrote. I open 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. Make sure you include both technical goals and interpersonal goals! Being a successful engineer means being both technically competent and a good team player.
Then we work together to create measurable, time-limited goals (with checkboxes!) for the quarter based on their original goals, company 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 and ship 1 major feature”.
I also use this time to document any additional projects or emotional labor the person has been working on (i.e. strike teams, committees, Employee Resource Groups). Sometimes projects come up during the quarter that weren’t anticipated at the beginning of the quarter. Sometimes a person will undertake (or be asked to take on) extra emotional labor that takes up time and resources they would otherwise spend on engineering tasks.
It is particularly important if you manage underrepresented engineers to make sure they aren’t being asked to do excessive emotional labor. Is your sole female or POC engineer being asked to be on *every* interview loop? Now is a good time to intervene and spread the emotional labor around. Make sure to take note of emotional labor in goals so you don’t accidentally penalize your direct report for doing something good for others.
Regular goal check-ins are 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? Is someone being tasked with too much emotional labor and they don’t have enough time to work on their technical tasks? Are the bugs too hard for their current level? Interpersonal issues? This is a good time to work together to uncover the source of why these goals aren’t being accomplished and work together to find solutions, spread out emotional labor, or suggest workshops that could help.
It’s also a good time to note any interpersonal concerns I’ve noticed over the last few weeks (covered already in 1:1s) and improvements I would like them to work on. It’s ok to write them after they’ve occurred. The most important thing is documenting changes as they happen and giving credit when it’s due!
Annual review rollup
With all of these past notes, it makes writing reviews much easier, for both individual contributors and managers. Need a new conference bio? Check out your goals and see what amazing things you’ve done over the past few months. Struggling to write a performance review that’s more than “A++ would hire again”? A good goal process will help with that.
Regular goal check-ins also make it clear if too much time is spent in any one particular area. Is someone struggling with a technical challenge, checking in on a person will surface these areas and make it easy to adjust expectations sooner rather than later.
Frequent check-ins also help guide people to work on areas they may not naturally want to work on. Personally, I am not motivated to keep my own goals, but if I have someone holding me accountable, I’m much more likely to succeed.
It also ensures I don’t dismiss the invisible or emotional labor of my team. It’s easy to forget little things that a person has done throughout the year that aren’t strictly technical. Did someone spearhead a program that increased comradeship with other teams? Does another person jump into a pairing session any time someone has technical issues and then follow up and document what kinds of lessons were learned? Make sure you thank your team appropriately for things like this (by giving them more money at review time)!
It also makes it much easier to spot if they’re eligible for a promotion, since it clearly shows where they are in the engineering levels. As a manager, it’s your job to fight for your team and promote them accordingly. Having a timestamped list of accomplishments will make fighting for promotions easier.
Conclusion
Goal-setting needs to be a collaborative exercise between a manager and a direct report. By keeping a version-controlled document of a person’s past accomplishments and areas of improvement, it becomes much easier to identify problem areas, document emotional labor, and help people grow their skills with accountability.
Hope this helps, and happy goal-setting!
P.S. I’m hiring! Check out the job posting if you’re interested in making the internet a safer place.
Many thanks to Helen, the first of many great managers who have inspired me to get into this very weird field, whose goal-making process is second to none.
