<sarcasm>It’s that time of year for a lot of companies – annual goal setting! Hurray! Everyone rejoice in the fun!</sarcasm>

Does this have to be an exercise in pain, or can it actually be useful to both the individual contributor and the management? I don’t think I can ever make this process fun but I do think it can be made useful.

About twice a month, I’ll get someone coming to me to ask for career advice. I’m starting to collect the more common questions and my thoughts on them. I’m putting these together as a series of blog posts under the tag CareerPlusPlus.

So, what’s the point?

This is one question I frequently ask in meetings that can be extremely popular and extremely unpopular. No matter what we’re doing at the company, I always want to know, “Why are we doing this?”

I’m a firm advocate that everything we do should have a purpose. Sometimes the purpose is super obvious. Sometimes it isn’t. But if we can’t see a reason for doing something, I feel we have to ask ourselves if we should keep doing it or not.

A lot of people look at goal setting as a requirement and that’s why they do it.

Doing it just because it’s a requirement is, to pardon my former-sailor language, bullshit.

If you’re only doing it because you are company mandated, then just copy in some lorem ipsum text and move on. You don’t need to read the rest of this blog post. I’m not even saying that to be cute. If you will never use the goals for anything in your company and your management team won’t ever review them, then copy some text in there to fill out the blank and move on. You have better things to do with your time.

If you’re still reading, then I’m guessing you want to find some value in this exercise.

In my mind goal setting is about intentionality. Every year I’m going to do an annual review with my employees and my manager. During that we’re going to discuss progress over the past year and the direction we want to see our careers grow. So I should have a high level idea of the areas for growth. Goal setting is the way to connect the what to the how.

This is where most people screw it up, in my opinion. They write the “what” as their goal. I see things like “be a better communicator” and “write better unit tests”. We can do better.

In my opinion, the purpose of writing down goals is to make it clear to the employee how they can go about getting to their desired next stage of their career. When done well they can be extremely helpful. When done poorly they are of zero value.

Tim’s Rule of 3

Ok, so if we want to lay out a how of getting from where we are now to where we want to be by our mid-cycle review I recommend making three goals.

• Goal 1: Short term goal. This should be something that is in the next 1-3 months. We should be able to define this quite narrowly since your work should be pretty well laid out over this time period.
• Goal 2: Longer term goal, typically 6 months. You’ll probably need to be a little vague about this one since if you’re doing agile development there is no guarantee that you know what you’ll be working on in that time frame.
  • Who are we kidding? Almost nobody really does agile development. They do waterfall with agile lipstick.
• Goal 3: Personal development. This is one about how you can improve, not about your work accomplishments.

Why do we do 3 goals? I don’t know. 2 is not enough and 4 is too many? I don’t have a deep analysis into why 3 is the right number, but it is.

Ok, so look at the work you have planned out. Pick an objective criteria that is attainable in that short time frame and has a good definition of done. Write it down. It’s okay to copy part of it straight out of your tracking system. You’re not getting paid extra to make these written different from what is in other places. It’s also less confusing three months from now when you’ve forgotten why you’ve written something that is very similar but different than the tasks you were tracking.

Now you want to do the same about the longer term work. It’s okay to be a little more vague on this goal.

For the personal development goal, look at your annual review. What was the one area that it showed you needed the most growth? Was it in technical expertise? Working across the company? Communication? Take whatever area you had for growth and write that down as your goal. The next section gets into how to write those.

Let’s get smart about it

I generally hate when new sexy management techniques come out, but there is one that I’ve found to be extremely helpful. It’s the SMART acronym for writing down goals. Make all of your goals

• Specific
• Measurable
• Achievable
• Relevant
• Time-based

Okay, they cheated on that last one, but SMARTB sounds dumb-b.

Take each of the generic three things you wrote above for your three goals, in whatever form they were. Add each of the smart bullets above. You can trim it down if these are getting too long. You’re not writing a paragraph for your goals.

Make each goal a single sentence fragment. Cut out the “I will…” from it. Be pithy.

Concrete examples

Here are some real life examples. I’ll start with things someone had originally put down as their goals and then show how we can rewrite them with the above criteria.

Be a better communicator.

I cannot tell you how many times I’ve seen this one, almost exactly verbatim. How exactly will you be a better communicator? What steps will you take on a daily basis to achieve that? How do you know you’ve done it?

Don’t get me wrong – a ton of people need to work on their communication skills. So let’s help this person work on those skills with a solid plan of action. First off, what types of communication are they bad at? Is it in how they share information out across teams? Is it how they document the work they’ve done? Is it how frequently they give updates to coworkers or management? Specifically find the areas of weakness.

Suppose the area for weakness for this person was that they gave technical updates in meetings without any context and immediately spoke over the heads of everyone in the room. For this person I might write the goal as “During each weekly team meeting provide a two sentence background statement of where the work fits in and how it impacts the development.” Now that is something person can act on and it provides value.

Write cleaner code.

Again, we need to ask ourselves what this means. How is their code not clean? There is probably something in the peer reviews that led to this as a goal.

If the issue is code complexity, you could do something like, “Rewrite module X to meet 95% of the Google code guidelines by the end of Q1.” Hopefully you get the idea. Or maybe it’s about code complexity. Aside: I highly recommend A Philosophy of Software Design by John Ousterhout. Then you could have a goal of “Reduce module Y complexity by organizing into design pattern Z by the end of Q2”.

Deliver feature X.

This one is actually not terrible. You could improve it by saying when you need to deliver it. You could also put in acceptance criteria.

I’d also ask yourself if it’s truly a binary. Is this a zero sum game? Or do you have a possibility of partial delivery? Can you write something along the lines of “Implement all 12 required elements in feature X by end of Q3 with QA approval.”

The nice thing about thinking of things that you can measure as more than yes/no is that you can have partial delivery. Suppose something doesn’t go well and you cannot deliver all 12 of those elements but you can get 10 in. Wouldn’t you rather get 10/12 credit rather than 0/1?

Closing Thoughts

I really recommend you think about “what value does this bring?” when writing your goals. For the person who is working on the goal, it should give you a clear idea of what it means to succeed in the role over the next <some number> of months. For the manager, it should give you a clear idea of what they will be working towards.

Then you can use these at your 1:1s. Does the work they are doing this week line up with those goals you set out? If not, does the work or the goals need tweaking? Or is this a short side quest for a week to take care of something before we get back to our main goals.

If you need tips on running 1:1s I have a post about that.

Good luck!