It's annual performance evaluation time at my employer, ZipRecruiter, and as
part of that I have to write a self-evaluation. I know many people
dread these, and I used to dread them, but these days I like doing it.
Instead of being a torture or even a chore, for the last couple of
years I have come out of it feeling much better about my job and my
performance than I went in.

I think that is about 20% because my company does it in a good way,
30% because it suits my personality, and 50% because I have learned
how to handle it well. The first half of that might not help you
much, but if you're an evaluation loather, you might be able to
transfer some of the second half and make it a little less horrible
for yourself.

How ZipRecruiter does self-evaluations

I will get this out of the way because it's quick. ZipRecruiter does these
evaluations in a way that works well for me. They do not pester me
with a million questions. They ask only four, which are roughly:

What were your main accomplishments this year?

Describe areas you feel require improvement.

What do you hope to accomplish in the coming year?

How can your manager help you?

I very much appreciate this minimalist approach. It gets right to the
point, covers all the important issues and nothing more. None of
these questions feels to me like a meaningless bureaucratism or a
waste of time.

Answering the questions thoroughly takes (only) two or three hours,
but would take less if I didn't write such detailed answers; I'm sure
I could write an acceptable report in an hour. I can see going in
that it will be a finite process.

Why this suits my personality well

If you have followed this blog for a while, you may have noticed that
I like writing essays, particularly essays about things I have been
working on or thinking about. ZipRecruiter's self-evaluation process invites me
to write a blog post about my year's work. This is not everyone's cup
of tea, but it is right up my alley. Tea alley. Hee hee.

My brain has problems

My big problems with writing a self-evaluation are first, that I have
a very poor memory, and second, that I think of myself as a lazy
slacker who spends a lot of time goofing off and who accomplishes very
little. These combine badly at evaluation time.

In the past, I would try to remember what work I did in the previous
year so I could write it up. My memory is poor, so I wouldn't
remember most of what I had done, and then it was easy to come to the
conclusion that I had not done very much, probably because I was a
lazy slacker whose spent a lot of time goofing off. I would go
through several iterations of this, until, tormented by guilt and
self-hatred, I would write that into the self-evaluation. This is not
a practice I would recommend.

If there were two projects, A and B, and I promptly finished A but B
dragged on and was running late, which one would I be more likely to
remember when the time came to write the self-evaluation report? B,
of course. It was still on my mind because I spent so long thinking
about it and because it was still in progress. But I had forgotten
about A immediately after putting it to rest. Since I could remember
only the unfinished projects, I would conclude that I was a lazy
slacker who never finished anything, and write that into the
self-evaluation. This is also a a practice I recommend you avoid.

The ticketing system is my bionic brain

The way I have been able to escape this horrible trap is by
tracking every piece of work I do, every piece, as a ticket in our
ticketing system. People often come to me and ask me to do
stuff for them, and I either write up a ticket or I say “sure, write
me a ticket”. If they ask why I insist on the ticket (they usually
don't), I say it's because when self-evaluation time comes around I
want to be able to take credit for working on their problem. Everyone
seems to find this reasonable.

Then, when it's time to write the self-evaluation, the first thing I
do is visit the ticket website, select all my tickets from the past
year, and sort them into chronological order. I look over the list of
ticket titles and make a list of stuff that might be worth mentioning
on the evaluation. I will have forgotten about three-fourths of it.
If I didn't have the list in the ticketing system, I would only
remember the most recent one-fourth and conclude that I spent
three-fourths of my time goofing off because I am a lazy slacker.
Instead, there is this long list of the year's accomplishments, too
many to actually include in the report.

Well, this is not rocket science. One is called upon to describe the
year's accomplishments. Even people with better memory than me surely
cannot remember all this without keeping records, can they? Anyway I
surely cannot, so I must keep records and then consult them when the
time comes. Put that way, it seems obvious. Why did it take so long
to figure out? But there are a lot of happy little details that were
not so obvious.

Instead of thinking “Why didn't I finish big project X? I must have
been goofing off. What a lazy slacker I am” I think “holy cow, I
resolved 67 tickets related to big project X! That is great
progress! No wonder I got hardly anything else done last fall” and
also “holy cow, X has 78 resolved tickets and 23 still open. It is
huge! No wonder it is not finished yet.”

Writing “I completed 67 tickets related to X” is a lot more concrete
than “I worked hard on X”. If you are neurotic in the way I am, and
concerned that you might be a lazy slacker, it feels much more
persuasive. I have an idea that it sounds better to my boss also,
particularly if he were to be called upon to discuss it with his
manager. (“Under my leadership, Mark completed 67 tickets related
to X!”) Andy Lester says that your job is to make your boss happy,
and that means making it easy for him to do his job, which is to
make his boss happy. So this is no small thing.

Instead of thinking “Gee, the CTO declared top priority initiative
Y, and while everyone else was working hard on it I mostly ignored
it because I am a lazy slacker” I might see that I have tagged 9
tickets “top priority initiative Y”. Then on the report, I proudly
boast “I completed 9 tickets in support of the CTO's mandate,
including (most important one) and (most impressive one).” This
also comes under the heading of “make it easy for your boss to do
his job”.

Instead of completely forgetting that I did project Z, I see the
tickets and can put it in my report.

Instead of remembering awful project W, which dragged on for months,
and thinking what a lazy slacker I was because I couldn't get it
done, I have a progress record in the ticket and the details might
suggest a different interpretation: Project W sucked, but I
nevertheless pursued it doggedly to completion, even though it took
months.

I might remember that I once helped Jones, but what did I help him
with? Did I really spend much time on him? Without looking at the
ticket list, I might not realize that I helped Jones every few weeks
all year long. This sort of pattern is often apparent only in the
retrospective summary. With the ticket system, instead of “oh,
Jones sometimes asks me questions, I guess” I can see that
supporting Jones was an ongoing thing and he kept coming back. This
goes into the report: “I provided ongoing support to Jones,
including (some cherry-picked example that makes me look especially
good).”

One question (#2) on the report form is “Describe areas you feel
require improvement”. If I wrote in last year's report that I would
like to improve at doing X, I can look in the ticket system for
specific evidence that I might have improved, even if I wasn't
consciously trying to improve X at the time. Probably there is
something somewhere that can at least be spun as an attempt to
improve at X. And if it didn't actually improve X, I can still ask
myself why it didn't and what might work instead, and put that in
the report as something to try next time, which is question #3.

Hey, look at that, I am evaluating my prior performance and making
informed corrections. That might be a useful practice. Wouldn't it
be great if I took time every so often to do that? Some sort of
periodic self-evaluation perhaps?

Another question (#3) is “What would you like to do in the coming
year?” If I wrote in last year's report said “I would like to do
more of X” I can look for evidence that I did do that, and then
write it into this year's report: “Last year I said I would try to
do more of X, and I did.”

Even if I were having a bad year and got very little done—and this
has happened—having a list of the stuff I did get
done leaves me in a much better position to write the report than
not having such a list.

None of this good stuff would be possible without an actual record of
what I did. If there weren't a ticketing system, I would have to
invent one or maybe tattoo it on my chest like the guy in Memento.
Even aside from its use in writing annual self-evaluations, keeping a
work diary is crucial for me, because without it I can't remember
day-to-day what I am working on and what needs to happen next. And
even for people with better memory than me, are they really going to
remember all 317 things they did for work this year, or that 67 of
them pertained to big project X? If they can that's great but I doubt
it.

Keeping a work record is part of my job

I think it is important to maintain the correct attitude to this. It
would be easy to imagine ticket management as unproductive time
that I wasted instead of accomplishing something useful. This
is wrong. The correct attitude is to consider ticket updates to be part of my work product: I
produce code. I produce bug fixes. I produce documentation, reports,
and support interactions. And I also produce ticket updates. This is
part of my job and while I am doing it I am not goofing off, I am not
procrastinating, I am doing my job and earning my salary. If I spent
the whole day doing nothing but updating tickets, that would be a day
well-spent.

Compare “I produce ticket updates” with “I produce unit tests”. The
attitude for ticket updates is the same as for testing. When
something happens in a project, I update the ticket, because keeping
the tickets updated is part of the project, just like writing tests
is.
An organization that fails to support ticket updates is broken in the
same way as one that fails to support test development.

My boss gets email every time I update a ticket. I don't know if he
reads these, but he has the option to, and I don't need to worry as
much that maybe he thinks I am a lazy slacker who is goofing off,
because he is getting a stream of automatic notifications about what I
am up to. I'm not my boss but if I were I would appreciate this very
much.

Maybe some of this can help you?

There might be some use in this even for people who aren't already in
the habit of writing self-absorbed blog posts.

If doing the annual self-evaluation makes you suffer, maybe it would
help to practice writing some blog posts. You don't have to publish
them or show anyone. Next time you finish a project, set aside thirty
or sixty minutes to try to write up a little project report: What
worked, what didn't, what are you pleased about, what was surprising,
what was fun, what was annoying? I'm not certain this will help but
it seems like this is a skill that might get easier with practice, and
then when you have to write your annual self-evaluation it might be
easier because you have more practice doing it. Also, you would have
a little file of material to draw on and would not have to start from
zero.

If your employer's process requires you to fill in some giant
questionnaire, it might be easier to do if you go into it with answers
to the four basic questions prepared ahead of time. (I imagine that
it's even possible that if you address the four big questions and
ignore everything on the giant questionnaire that doesn't pertain to
them, everyone will be perfectly satisfied and nobody will notice the
omissions.)

And keep a work diary! Tattoo it on your chest if you have to. If it
seems daunting, realize that you don't have to do it all at once.
Keeping a work diary of some sort is forgiving in the same way as
writing unit tests:

It's not all-or-nothing, you don't have to test every piece of
code to get any benefit from testing. If you write tests for 1%
of the code, you get about 1% of the benefit, and you can ramp up.

If you break your test-writing streak you don't have to start over
from zero. If you didn't write any tests for the code you wrote
last week, that's a shame, but it doesn't affect the benefit you
can get from writing a unit test for whatever you're working on
today.

The work diary is similar. When time comes to write your evaluation,
a small and incomplete record is better than no record at all. If you
forget to write in the diary for a month, that's a shame, but it
doesn't affect the benefit you can get from writing down today what
you did today.

Our ticketing system

This isn't important, but I expect someone will want to know: At work
we use FogBugz. Some of my co-workers dislike it but I have no major
complaints. If you want to try it on your own, they have a seven-day
free trial offer, after which
you can sign up for a permanent free account that supports up to two
users. I am experimenting with using a free tier account to manage my
personal to-do list.

Coming soon

I wrote another 2,000 words about my specific practices for managing
tickets. I hope it'll be along in a few days.