Goals: Learn a thing, Do a thing, Teach a thing

How do you make someone in technology laugh?  Ask them to write down goals that reflect what they’re going to get done in the coming year.  Or quarter.  Oh, heck, the next month.

This is a common enough request in most companies, the quarterly or yearly goals.  They’re often used (partially) to help determine how successful the employee was when it comes time to determine the amount of their bonus that reflects how successfully they met those goals.

What makes this a humorous (or, more likely, depressing) exercise is what any engineer will tell you: They have no clue what they’re going to do in the coming year.  Or quarter.  Or, often, the next month.  And tying their yearly bonus to this exercise is just setting them up for failure.  But, it persists.

This is even worse when engineers, as many do, work in shops that purport to be Agile or SCRUM organizations.  Without going into a great deal of detail, what this means is that instead of sitting down once or twice a year and planning out what we’re going to do (and then only doing about 25% of that because, surprise!, things change), organizations that are Agile or SCRUM will do what they are asked to do guided very generally by, perhaps, yearly, more often quarterly, goals or direction and then that breaks down in to more manageable increments, often called Sprints, of one to four weeks (give or take).  They work with the Scrum Master and with direction from the Product organization who helps set the direction and priorities for that iteration.

So, if you ask this engineer what they’ll be working on for the next four quarters, the savvy engineer will tell you, “Whatever I’m asked to do as part of planning”.  Which, obviously, makes predicting Goals an exercise in writing fiction, because goals will almost inherently be wrong shortly after the (virtual) ink is dry.

In my past roles, I would attempt to address this by going back with the engineer, say at the end of the quarter, and updating the goals to reflect what actually got worked on so the engineer is successful.  Assuming, of course, that the engineer was active and responsive to requests and what they worked on was reflective of what the organization asked them to do, which is almost always the case.

Engineers, as part of this exercise, would often ask for examples of reasonable goals and for years I would, at a minimum, talk about SMART Goals.  Basically this asserts that meaningful goals are (S)pecific, (M)easurable, (A)chievable, (R)elevant and (T)ime-bound.  Using this approach, you’re much less likely to create a goal that is full of unicorns and fairy dust.  You can do it, you have to mean to do that.

Now, a couple of caveats in all this: First, obviously this isn’t unique to engineers, software or otherwise.  It’s rife in high tech and, I’m sure, elsewhere.  But, that’s my world, so it’s the world that I know.  Second, I’ve had the privilege of working for some very savvy Directors and VPs who understand that this is often a process that is more for upper management than for the engineers, so applying a translation layer of rationality between the engineers and upper management is part of my job.

Over the last five or so years, I’ve settled on an approach to Goals that I’ve found to be effective, both up the chain and with the engineers.  It can be summarized as, “Learn a thing, Do a thing, Teach a thing”.

Learn a thing: Find an area that you’re interested in, almost certainly related to your career field and areas of interest (basket weaving won’t work, learning about a new Framework that we’re looking at is on point).  Learn about that thing/library/technology/framework.  Perhaps it builds on the engineers existing areas of expertise, perhaps it grows them in a related area to help them develop professionally.

Do a thing: Learning something that has no applicability is hard and often pointless.  Using that thing that was learned to do something concrete, even if only a Proof of Concept (POC) is targeted and SMART (specific, measurable, etc.).  Note how these pieces start to work together, using a SMART goal wrapped around learning a thing and doing a thing means it’s bounded by time, the goal is specific and relevant to the work we do.

Teach a thing: It’s critical as engineers grow and mature, that they start taking on responsibility to teach the engineers behind them.  Teaching is a critical skill, it helps mature and grow the organization and the engineer demonstrates mastery.  This could be as simple as passing the information along to another engineer, but my preference is a Group Lunch (provide lunch!) or a more general presentation to the Engineering organization.  Obviously, the audience will vary based on the material, the relevance and, often, the seniority of the engineer.

It’s worth noting that these work well in pairs.  (Twice the number of goals!) If you learn a thing, you should do a thing as part of that, else it’s just hypothetical.  Again, a POC is a great deliverable, though something directly relevant to what we’re building is even better.  If you learn a thing or do a thing, you should be able to teach that thing and share the knowledge.  This breaks down silos of information, grows the organization as a whole and avoids the problem of having only one person who knows critical information.  This is also the perfect opportunity to be sure that documentation is prepared to help share knowledge as well.

This is still not a perfect system.  There will still be times when the manager and the engineer will write some goals that don’t come to pass because priorities shift or a goal becomes obsolete due to changes in direction.  This should be okay!  In fact, goals should never be cast in concrete and if they are, that’s a problem and you will not be able to address that without becoming absurdly generic: “Build good things and deliver them on time and to specification” sounds ridiculous, but that’s an indication that someone feels unnecessarily constrained by rigid goals, so they turn to the generic.  This is a useful approach, but it does require that the organization has an ability to update and modify goals to fit the changes that will certainly happen over the course of a year or even a quarter.  This also, by the way, is a great reminder that goals should be reviewed and updated often, at least quarterly, but you probably didn’t need me to remind you of that, right?

Goals shouldn’t have to be a terrifying exercise.  Yes, they can often be easier in some other areas of business, but that doesn’t mean they have to simply be an exercise in fiction.  The manager and the engineer should work together to make them something that is meaningful to the engineer, professionally, as well as the manager, representing the company.  It’s a balance, but done well, it can be a useful exercise.