Scheme E: “Crushable Work Goals”
Published (gregorian) (ornellember)
Tags: scheme
career seriesRight off the bat, two things.
First, I am writing this on 3E. Meaning I did not wait until the very last day of the month to do this task (please clap.)
Second, this one is definitely a scheme, and it is one that gets pretty close to career advice. I want to clarify that again, like with every post in this series, I’m talking about a strategy I’ve used. I’m not advising you to do the same, or saying I invented it (and I’ll give credit when/where I know it’s due). This is my personal experience.
Anyway, let’s talk about how I set and cRu$H g0alz at work!
# Definition
Write goals about structure, not result.
# The Story
At my very first software engineering job, my wonderful manager asked me to come up with 4-week, 3-month, and 1-year goals. She mentioned SMART goals, and advised against setting goals like “get good at Javascript” that are basically impossible to measure.
I used her method and set 4-week, specific, measurable goals. They looked a bit like:
-
speak to all my coworkers 1-1 at least once (this was a startup)
-
build at least one new React component
-
pick up at least one CSS-focused ticket
I think these were pretty good goals. But looking back, there was already an issue with the second one.
Let’s look at it again: “build at least one new React component.” With this goal, I meant to prove to myself and others that I could write a complex React component and understand its structure. However, I don’t really think I did that in that job. Maybe I wrote a small sub-component, but what I did instead was refactor a large component in a significant way. This had fulfilled my motivation for the goal, but didn’t accomplish actual goal itself. It was too specific.
Shortly after, I got a new job at Disney. With the benefit of hindsight, I went about setting my 3-month, 6-month, and yearly goals goals a little bit differently. For one, I was a junior engineer in a huge codebase, there were talks of moving me to a different team, and really didn’t want to pigeonhole myself into a specialty.
I had a few constraints:
-
Specificity. What I wanted were goals that were both specific enough to be looked back on as “oh yeah, you did accomplish this, no question!”, so no goals like “get comfortable with CSS.”
-
Fuzziness: I needed goals that could be accomplished regardless of the product roadmap, so no goals like “work on React components” (what if the company decides to migrate to Vue mid-year?)
-
Control. I also am a big fan of the principle “you control the input, not the outcome” — so I wanted my goals to be focused on what was within my control, meaning what I could do, not be.
-
Progress. I wanted to accomplish goals that proved I was ready to be promoted.
The last point was fairly easy — we didn’t have an official level ladder yet, but I set 1-1s with multiple managers and peers who’d gotten promoted, and sussed out what the bar was for a mid-level engineer.
My goals ended up looking like this:
-
Pick up 5-10 tickets that are above a 5-point estimate.
-
Give at least one talk to the rest of the org.
-
Lead an initiative that has me interfacing with other teams.
-
Write at least 1 RFC/design document.
-
Pick up at least 3 non-trivial tickets outside my technical comfort zone.
-
Mentor at least one engineer.
-
Set 1-3 coding standards or practices at the scale of the team.
You’ll notice a few things about these goals:
-
they are binary: we are talking in with specific numbers, so each goal is either done or not done.
-
they are product-agnostic: they do not contain one specific name or technology.
-
they are tasks: all these goals are things I want to do. They are all within my control. My assumption is that if I do those things, I will become what I want to be.
-
they are mid-level: I think I’d get in trouble if I shared Disney’s this particular career ladder docs, but all of these were directly related to criteria that make an engineer considered a P2 there.
Throughout the year, I had one-on-ones with my manager, peer mentor, and skip-level, and specifically referenced those goals, talking myself up re: the ones that I’ve done, and confirming I was on track for the ones I hadn’t.
It was decided I’d be promoted shortly after.
# My plan
My plan was to crush every single goal I’d set out to do, and let those goals prove that I was due for a promotion. The roadmap that year was actually full of surprises, and I couldn’t have predicted what I concretely ended up working on; yet, I was able to neatly achieve everything I said I would.
# PS
No PS?!?
JK. Here’s one. If you stalk my website, you may notice this was only put up in late May. I, however, did write this in early April, but then I was feeling anxious and took it down.