My framework for defining goals that actually help people grow

Defining good goals is hard. As managers, we care about our team’s growth, and goals should be a wonderful tool for making it happen. However, in most cases, they don’t.

From my experience, this is what often happens to goals:

• They are viewed once during a performance review and then lost forever (or for 6–12 months until the next performance review)
• They are not clear — too wide, too big, too subjective (“Improve tech skills”) and might be misinterpreted and not bring the value that was originally intended
• They are not measurable — the employees don’t really know if and when have they achieved the goal (“I feel I’ve improved”)
• They don’t reflect the actual expectations of the manager from the employee and, therefore, don’t help the employee grow as expected
• They aren’t personal and are generated by ChatGPT (a quiet recent phenomenon)

Let’s look at an example:

“Improve your technical skills”

The original purpose is great, the manager wants to level up her team member. However, this goal means nothing to the employee and isn’t actionable, or measurable. Is it related to the employee’s backend skills? Frontend? Both? Debugging maybe?

How can the employee determine if he has met the manager’s expectations after a span of 2 weeks? Obviously, the manager has some expectations and she might have talked about it during some meetings, but what’s not written is lost forever.

After years of defining bad and not useful goals, I went on a journey to improve the preparation process, the goals definition, and their tracking during the year.

The preparation

I met many managers who could easily tell that their employees should be better in many areas (tech skills, soft skills, communication skills, ownership, etc.), but rarely they could explain what type of behavior do they expect to change and how. Companies that have defined career ladders usually have explicit expectations for different levels, but in case there are none there’s a great blog post that outlined different expectations from many different experience levels. I took the liberty to copy them into an Excel file for your convenience. Copy it, add a column for every team member of yours, and then go over each line and mark if they meet the expectation or not (I use a scale of 1–2–3). It’s important to note that the goals should be personal and target the employee’s personal strengths and weaknesses regardless of the “level” they are at.

Feel free to add additional expectations

The goals definition

I bet you’ve heard about how goals should be SMART. It’s great but to be honest, I was never able to fully apply this to my goals.

Fun fact — There’s a great podcast by Manager Tools that argues that goals should be just MT — Measurable and Time-bound and the rest of the definitions are kind of redundant and they use this as an example:

Put a man on the Moon and return him safely to Earth by the end of the decade

Another framework that you might have heard about is OKR. I like this framework as it helps define a wide objective with clear, explicit, measurable goals.

So let’s return to our example — “Improve your technical skills”. Let’s apply the OKR framework.

Improving your technical skills is an objective, but in order to achieve it, we need to define the key results. For that, we need to break it down — what does “technical skills” mean? Is it the craftsmanship skills? The knowledge of a certain framework? Production engineering? Higher quality coding? Faster resolution? It can be all of the above but that would be too wide and really overwhelming. To nail it down, the manager should be explicit about what really needs to be improved. Using the expectations framework from the previous chapter should help. By explicit, I mean something easily measurable. If we are talking about a junior engineer (who obviously needs to level up), then most likely we would expect him to:

• Gain a deeper knowledge of the frameworks he’s working with
• Be more careful when deploying the code to production
• Contribute more to the team in different mediums like PRs, Design, knowledge-sharing sessions, etc.

Now let’s convert each one to a measurable key result:

Gain a deeper knowledge of the frameworks he’s working with

• Watch 2 courses about “Advanced Python” and “Python Internals”
• Apply Python 3.9 features like XYZ in 100% of the PRs
• Read the Clean Code book
• Refactor the module “XYZ” and apply SOLID principles

Be more careful when deploying the code to production

• 100% of the features have a written test plan prior to starting the development
• 100% of PR have the appropriate testing coverage (unit tests, E2E)
• 0 post-production bugs

Contribute more to the team in different mediums like PRs, Design, knowledge-sharing sessions, etc.

• You review 100% of the team’s PRs
• Give 2 talks to the team about “Python internals” and the latest features in Python 3.9
• Send an article that is relevant to the team’s technology every Sprint

I know, “0 post-production bugs” and general “100%” of something seem unrealistic. However, I believe that the goal should be inspiring and hard to get. Saying something like “3 post-production” bugs leaves room for mediocracy. If 3 is applicable, then maybe 5 as well? By saying a hard ZERO you make the employee work harder on getting there. We shouldn’t feel proud when we have 3 post-production bugs, or 2. Yes. bugs most likely still happen, but the goal is to level up the quality mindset — by pushing to 100% (or zero), in my opinion, what pushes towards growth.

Another important subject that’s often overlooked is time — by when do you expect the employee to achieve these goals? Since we have a clear list with different deliverables we can set different dates for each KR. Usually, the latest will be up to 6 months from now (i.e. Jan 1st, 2024) but some might be as soon as next month (i.e. July 1st, 2023)

The goal would look like this:

Improve your technical skills

• Watch 2 courses about “Advanced Python” and “Python Internals” by Aug 1st
• Apply Python 3.9 features like XYZ in 100% of the PRs by Aug 1st
• Read the Clean Code book by Sep 1st
• Refactor the module XYZ and apply SOLID principles by Nov 1st
• 100% of the features have a written test plan prior to starting the development by Sep 1st
• 100% of PRs have the appropriate testing coverage (unit tests, E2E) by Sep 1st
• 0 post-production bugs — Jan 1st
• 100% of the team’s PRs will be reviewed by you by Jan 1st
• Give 2 talks to the team about “Python internals” and the latest features in Python 3.9 by Oct 1st
• Send an article that is relevant to the team’s technology every Sprint starting Jul 1st

Might be a bit overwhelming at first sight, but actually every bullet is very clear and explicit. A performance review might have no more than 2–3 objectives broken down into measurable and time-bound key results. Another important area to keep in mind is to align the goals with the team’s domains and business focus. Improving Python skills make perfect sense, however, if the team will focus mostly on the front-end (React) for the next 6 months, then it will be extremely difficult for the employee to accomplish the goal.

Tracking progress

All of us are familiar with the goals that were discussed once and then lost forever. It’s a pity as the goals were intended to help our employees to level up, however, not tracking them means that there’s a high chance they won’t be worked on and hence, not help grow as intended.

I found that there’s a very simple solution that most of us don’t use — set a reminder to review the goals. Our routine and the busy day-2-day work sometimes diverge our focus from the strategic areas, that’s why most often a calendar reminder is the simplest solution. Once I define the goals, I immediately add a recurring monthly calendar reminder for me and my employee to review their goals as part of our 1:1.

Having the reminder on the calendar forces us to discuss the goals. In such meetings, we will review progress, discuss why a certain goal isn’t progressing, and perhaps even change or define new goals that better meet the current expectation.

Final words

For goals to be effective, they need to be properly defined and properly tracked. Using the expectations mapping allows one to pick specific and explicit expectations. As mentioned in the “Zen of Phyton”:

Explicit is better than implicit.

Using the OKR framework makes the goals both measurable and time-bound. It also helps break high-level objectives into actionable and clear goals.

By adding a recurring calendar reminder you don’t lose track and are able to constantly review the goals and adjust when needed.

I hope that this framework will help you as it helps me. In order for you to be able to use it, I’m happy to share some additional examples of goals for different levels and roles to help you in defining yours.

Improve the team’s quality

• Decrease production bugs by 20%
• Increase test coverage by 30%
• 100% of production incidents were discovered by alerts or automation
• Make 100% of the squad’s bugs are solved while adding additional tests or safety nets

Incorporate additional management and leadership technics (a goal for a manager)

• Read 3 leadership/management books or take 2 online courses
• Join external management forums and communities (Facebook, Twitter, Reddit) and participate in discussions. Consult on at least 5 topics
• Share leadership insights from your team with the management forum on a monthly basis

Increase “Buy-In” success rate (a bit more complicated goal)

• Articulate yourself better in meetings using written summaries/decks/emails sent before 100% of the meetings led by you
• Increase the time you spend on active listening
• Ask at least 3 guiding questions instead of promptly pointing to solutions

Special thanks to Uri Fridland, Tom Sender, and Shanihollander🙏

If you enjoyed it, please help me spread the word by:

• 🌐 Sharing this post with a friend
• 👁 Following me on Medium
• 👏 Oh! And don’t forget to👏👏👏