Following up on the post A Manager’s Secret for Engineers to Advancement and Promotion I would like to share some of my experiences in helping Engineers to set personal goals that are relevant, fun, concrete and achievable! After having worked with multiple Engineers though several years I’ve been able to iterate with them on how to develop personal goals that makes sense. I will share my experience in this post.

What is a Good Personal Goal?

Let us start with talking about what is a good personal goal? We can do the flip-technique and look at what a bad one is! This could for example be (I’ve seen them all)

• Not relevant for the current career path and personal development
• Ill-defined and unclear what is to be done and when it is achieved
• No time given to work on it
• No engagement from the Engineer to make time for them (which could be for a lot of reasons)
• Over ambitious
• Turning in to just regular day-to-day work meaning that no actual improvement/learning/progress is done

With this as a start, it’s easier to list some properties of a good personal goal. Coming from an Agile background, I often think as well on the INVEST mnemonic for good User Stories: Independent - Negotiable - Valuable - Estimatable - Small - Testable. Some good properties would in my opinion be:

• Must be defined by the Engineer her/him selves. The manager should come up with ideas/drafts as needed and help with formulation. But it’s essential that the final formulations are written by the person who will execute and own them. If the goal is written by the manager, it will all in to the psychology that it’s “the manager’s goal and not mine” and the ownership and outcome will not be the same.
• Must be relevant to the individual contributors career path
• Ideally aligned with current Engineering themes in the organization. While not necessary, we’re looking for the synergy between work that can make both better. Having a personal goal about learning tech X will probably give more for the Engineer and the project if it will be done in the quarter where we plan to work extra much with this technology. There’s simply going to be more opportunities and motivation!
• Clearly defined and measurable outcome.
• Well understood and though-through so that both the Engineer and Manager believed it is achievable. This will imply that it should be clear on how to start working on it.
• Clearly relates to the company’s career development. Progress on the personal goal should map to something on the career development in the company.
• Within the current budget, if monetary resources are needed.

Additionally the manager needs to watch out for:

• that everyone in the team is given equal opportunities to the extent that it’s possible. It will be very demotivating if some team members gets to take fancy courses or go to developer conferences but others not.
• additionally “manager agendas”. There could be issues that needs to be addressed like employee happiness or long-term thinking (that can not yet be shared) with personal goals being an opportunity. It could be for example that an Engineer has, unfortunately, come in a situation where she/he is drained after several tough quarters. Then injecting a bit more fun personal goal on another topic can be a nice “recovery” or mind-shift.

Using Personal Goals

Like many companies, the quarter serves as the business iteration cycle which include making quarterly OKRs. In my company the formal feedback to Engineers follows this cycle as well. The result of the formal (2-way) feedback session is excellent input for the start of the personal development discussion. Many times it will be immediately obvious after the feedback session what goals to set, as the career ladder and career path was discussed.

During the quarter, I made sure that a check-in on the personal goals always was a standing topic during the 1:1 meetings. The Engineer talks about progress and next steps while I look out for opportunities to support e.g. to reduce sprint scope to make more time for working on the goal (the most common action).

At the end of the quarter, the Engineer will review her/his personal goals in terms of what was achieved and also if the goal it self was well formulated or could have been improved.

Setting Good Personal Goals

As we’ve been iterating on using OKRs for business and engineering goals for several years, the idea came at some point to see if we can re-apply the learning and benefits of this on goal setting on an individual career path as well. Did it work? Yes! The next section shows some examples of type of personal goals that I’ve set with Engineers though the years. As often as possible, direct references to the company’s career levels framework is used to make it clear what is addressed and to make sure that progress will be attributed in levels and promotion discussion later.

At the end of the quarter, the Engineer will grade each Key Result on a scale of [0.0, 1.0].

Note that it’s an art to create good OKRs. The focus here was rather using OKR-style goals to improve the outcome, rather than being perfectly formulated proper OKRs.

Personal OKRs Examples

• Objective: Improve communication & language skills to improve team work, (or pitch ideas better, or to understand my colleagues better).
  • KR: Go though own written relevant resources like our User Stories and wiki pages and correct with a grammar tool, to identify the areas that I could improve on. This will build a natural follow-up KR.
  • KR: Consume English language e.g. by reading books, listening to podcasts, …
  • KR: Present at least 2 times at a sprint/company demo this quarter, something I’ve worked on recently or some other topic for information sharing.
• Objective: Take over a new technical component to the team.
  • KR: Make a roadmap for the component that includes current known problems and anticipation of future needs.
  • KR: Create X stories for known problems including a refreshment of the existing README and component pages and pitch them at the sprint plannings.
  • KR: Analyze the current monitoring setup for the component and make some improvement (e.g. adding new metrics and setting up the relevant alerts checks and visualizations).
• Objective: Improve the quality of my work.
  • KR: Suggest improvements / create user story template/guidelines for the team.
  • KR: Every story that I create follows this template, with focus on task break-down.
  • KR: At the end of each sprint, review the stories I’ve worked on and grade them. Was it the story written in a good way, tasked-up and estimated reasonably? Write down learnings and take with me to the next sprint planning.
  • KR: Reach X% code coverage in my Pull Requests.
  • KR: For each Pull Request this quarter, explain in the description how I reasoned about testing this feature. Was/is additional testing planned outside of the committed test code? How was the tests currently implemented selected?
• Objective: I proactively spread my knowledge to our organization.
  • KR: Write one engineering blog post about something I or my team have achieved or are specialists in.
  • KR: I present X times at a team/company demo something that is useful for people outside of my team to learn about.
• Objective: Learn new tech X / improve skills in X.
  • KR: Complete & pass the online course Y in topic X.
  • KR: Read the book Z in the topic of X and write down the top learnings to share with my team on a team demo session.
  • KR: Identify with the support of my manager opportunities in X that are relevant and add X stories to his quarter’s sprints.
• Objective: Develop management and planning skills.
  • KR: Deliver bi-weekly updates to my team / manager on the progress of the initiatives that I own.
  • KR: Proactively argue for resources for initiatives I own in the right format.
  • KR: Set up a regular status-update for my initiative e.g. as a weekly standup or as an Slack/email update.
  • KR: Gather my senior colleague’s experience in project planning by short informal interviews. Pick the top 3 tips and implement on my next larger initiative that I will own or be a part of planning.
• Objective: I actively mentor at least one engineer in the organization.
  • KR: I will mentor person P so she/he becomes fully productive working with components X, Y. I will do Z story points as pair-programming with P.
  • KR: Establish and exercise my own technique and plan for technical on-boarding of new-hires to set them up for success in the company.
    • The intention is that this onboarding recipes can be reused for future on-boardings.
• Objective: I enable others to solve problems on their own, rather than solving them myself.
  • KR: In the team OKR(s) that I’m are responsible for, delegate X stories to my peers and take the back-seat.
• Objective: Give direction & drive business values for the company.
  • KR: Establish a technical roadmap for component X.
  • KR: Identify (together with the right people) one new initiative that contributes to the company’s current business strategy.
  • KR: Prepare an OKR proposal for one identified impactful idea (new or from the team’s roadmap) in time for the next OKR cycle planning session.
• Objective: Get visibility in the company to build my network within the organization to strengthen my career in the company.
  • KR: Present X times at a company demo something that I’ve achieved in the last sprints.
• Objective: Contribute to and shape the growth of the organization with the technical interview process.
  • KR: Participate in 3 technical recruiting interviews (given that there’s a chance).
  • KR: After this, suggest at least X improvements to our current recruiting process.
• Objective: Increase engagement and outcomes of the my working group X.
  • KR: Research and try out different meeting formats e.g. topical, Q&A, rotate meeting leader roles.
  • KR: Survey the working group members on their ideas for improvements and implement the top Y of these.
  • KR: Reach out to Y other working group leaders and interview for their experience in getting engagement and better outcome.
  • KR: Increase the participation numbers with Y% for next 3 meetings based on the current baseline average Y members per meeting.

Closing

Those are just some ideas. Try out yourself what works out in your organization and team!

Just as I finished this blog post, I just remembered that I’ve also tried out early on in my career as Engineer to manage my own personal goals as User Stories in my own personal Scrum board. While I did not keep this up in the end, the idea of having a backlog of my own development still stuck with me! This is maybe for another blog post on its own.