Writing has helped me clarify my thinking and it's a great way to reflect. I've never shared much of it, but now it just feels like I'm sending an email, so I'm trying it out. I mostly write on building software, and engineering management if you're interested. This first one is about personal goals in the context of a software team
Different categories of personal goals
Different categories of personal goals
I love setting myself goals, it's a great way to focus on learning. There are different frameworks out there that help writing up great goals (like SMART, GSM, etc.). The idea is not to come up with a different approach but instead add to them.
Over the past ~2 years, I've had the chance to collaborate on a lot of different goals with my team. Categorizing them under buckets has helped me to understand the focus of the members of my team.
Execution: Goals that relate to executing your primary craft
This is the most frequent type of goal I see, this usually takes the form of shipping code, e.g. I want to ship X project by Y date. Those are very relatable to the company's objectives and are quite easy to come up with.
Another example in this category is time management. We usually receive more information that we can process on a given day. It's easy to get sidetracked and work on the latest piece of information we've received. An example of a day where we could get sidetracked:
- Start of day: I want to work on my project and ship this Pull Request by the end of the day
- 10 AM: Someone from another team asked a technical question in slack and I want to support them. I end up spending 30 minutes to give an accurate answer
- 11 AM: Standup time, my teammates are looking for code reviews, so I'll spend the rest of the morning reviewing PRs
- 1 PM: I've got focus time and can make good progress on my PR
- 2 PM: I get pinged on Slack, there's an exception in production. I'll spend the next hour debugging what's going on
- 3 PM: While I'm on Slack, I realize my lead and my product manager are both asking me questions, I'll take time to answer.
- End of day: My Pull Request is not quite ready, what happened?
If you're optimizing to unblock the rest of the team, this is a solid day. If you were hoping to finish your personal work, it didn't happen. Then again, this might not be a big deal if this PR can wait until tomorrow. How will this impact the other things you're trying to do for the rest of the week?
A skill I often work with my team here is the ability to zoom out of a daily perspective into a weekly perspective. This usually improves productivity and reduces the feeling of being overwhelmed
Learning & Growth: Goals focused on learning to improve your skills & abilities
A common example I saw here is around learning a new technology such as Ruby, Rails, and more. This comes up more often for interns, new hires, or someone changing roles.
By default, you're getting a lot of free learning by working with other smart people. You learn via mentoring, code reviews, and practicing your craft on a daily basis. When you reach a certain comfort level with your craft, it's important to not forget this area. I like to keep setting focused learning objectives at all levels of seniority
People: 1:1 - Goals that impact individual peers
This category is around goals that impact a direct peer. This often takes the form of a mentoring opportunity for an intern, a new hire, or someone else in the team. I often see these goals first come up when senior developers mentor their first intern.
Engineering managers also focus a lot of time on this category. Leading performance reviews, 1:1s, and offering feedback are responsibilities in this category.
It's been trickier to measure success in this category as it's difficult to put numbers to this. My main tool has been through feedback surveys. One observation here is that you don't hold full responsibility for the other person's growth. You can mentor and sponsor, but at the end of the day, personal growth is also our own responsibility.
Team: 1:Many - Goals that impact many folks in the team
Here I focus on goals that focus on impacting a larger set of folks. For example, building a healthy team environment is a common goal for a lead. I'm currently focusing time on team goals, especially with the change to remote work. For example, I'm trying to push for a stronger culture of documentation. This is a shift from the previous model of tribal knowledge. This should result in a more resilient team where no one owns all the information. Hopefully, this facilitates the onboarding of new members as well.
Like the people category, measuring through feedback is one of the tools to measure results. Depending on the objectives, it might be possible to get more specific measures. For example, in the documentation goal, I can find how much documentation we are writing. I can also ask for onboarding feedback.
Recap
This model has helped me understand where the team's energy is focused. Some folks might want to spend more time on learning in the next 3 months, while others are heads down in execution mode. Giving those categories to developers also seem to help them value things outside coding. For example, it puts emphasis on making mentoring and helping the team being of the same importance as execution. It also makes it explicit that learning is something we should be doing.
That's all for now!
Philibert
Recap
This model has helped me understand where the team's energy is focused. Some folks might want to spend more time on learning in the next 3 months, while others are heads down in execution mode. Giving those categories to developers also seem to help them value things outside coding. For example, it puts emphasis on making mentoring and helping the team being of the same importance as execution. It also makes it explicit that learning is something we should be doing.
That's all for now!
Philibert