Goal Setting for Engineers
One of the first things new team members learn about me is my outspoken detest for the word "manager". I am not a manager. My job is not to manage people. My job is to hire and nurture engineers who do not need to be managed.
Such engineers share a few traits. For one, they are all passionate, capable self-starters. This means they care about their growth. Not just in the context of our team, but in their careers moving forward. If our environment doesn't overtly foster that growth, we should expect to have a lot of resignations.
One of the ways we foster the growth of our engineers is to regularly set and review goals for each of them.
Goal Setting
Individual goal setting can take three possible forms at companies. The first method is to never do it. The second is the set-it-and-forget-it methodology. If there is evidence that the latter works any better than the former, i've not seen it. The third is to made goals an active focus of an engineers time with a company.
Our team tries to handle goals as an active focus. The first step of that is setting in a more routine fashion. Every member of the team sets 3, 6, and 12 months goals in December. This allows us to do an end-of-year retro and a coming year kickoff on expected growth and goals.
The categories of these goals vary a lot between individuals. Some are strictly personal goals. Some are about growth in their current role. Others instead focus on what they want to do in service of changing or increasing their role. All of these are valid goals to track in my eyes. Remember that the intent of this exercise is to foster and engineer's overall growth, even if that growth is not directly aligned with the company intentions (which itself is a useful learning).
Goal Checking
So when do you check in on such long terms goals? In our case, it is in our biweekly 1-1's. Since our goal docs are a collection of 1-liners that detail the list of the engineers goals for the year, broken into 3, 6, and 12 month targets. Each of these lines is given a color to correspond to that engineers progress against each goal.
- Green = shared confidence in the level of achievement of the goal
- Yellow = obvious progress toward the goal
- Red = no real progress has been made toward the goal
It should be noted that there are no operational expectations attached to these goals. This is an exercise designed for growth. While i cannot speak for others, i don't grow when i am stressed about my targets. I rush and jump corners. I would much rather an engineer feel completely safe sharing their progress than feeling like they need to position that progress a certain way to avoid condemnation.
Year in Review
This entire goal setting and checking cadence is based around having the chance to perform a sort of year in review in December. This exercise has 3 distinct goals:
- Retro on well an engineer did on their goals through the year
- Retro on the goal setting itself. Were they the correct mix of challenging and achievable?
- Look forward and set their goals for the coming year
One of the biggest benefits to this format, i've found, is that starting with a retro on the previous year's accomplishments tends to leave engineers very energized and optimistic. Turns out we grow a ton in a year. Reflecting on those accomplishments while removed from the context of operational expectations and salary negotiations truly brings this to the forefront.
Such energy is also a valuable asset to leverage when settings goals for the coming year. Long term goals, set ambitiously, are a powerful driver for personal and professional growth. Having an engineer do so on the heels of celebrating their accomplishments tends to bring out the best of each of them. This can go a long way toward paving the path of their success in the coming year.
A litmus test for process
I should call out some important context for this post that has gone unnamed about my handling of engineering goals. My goal is to build an engineering team that i would have loved to work in all through my career. I do this by trying to cherry-pick my favorite things from my past while finding solutions for my least favorite things on previous teams. Of course sourcing feedback from the current team, using a similar process, is also of utmost importance.
In the case of goal setting, my history was full of conflict. Every company that hired me loved the depth of experience i had earned through personal projects before them, but expected those projects to end the moment i was hired. This left them feeling secretive and my growth stuttering as a result. Others just expected productivity above all else, including regular checkins or goal setting.
it is my belief that you get the most long-term productivity out of happy, encouraged developers. Ones that need no management, just encouragement and mentorship.
tl;dr: Regular goal setting and check-ins foster individual growth and indirectly improve your team's velocity as a result.
