Achieve the why by doing the how

With the start of 2019 there’s been a glut of resolutions going by my social media feeds, so it’s been the posts about explicitly not making resolutions that grab my attention. On YouTube, for example, John Green talked about making specific goals instead of resolutions, which made me think about my own resolutions in those terms, which then got me thinking about something John Cutler posted a while back that I’ll get to in a moment.

I like the idea of goals instead of resolutions, but it doesn’t really work for me. In one of these many posts about resolutions, someone—I’ve lost where I saw this now—made the point that resolutions often fail because they’re not specific or measureable. “Eat healthier” doesn’t work as a resolution because it’s too vague. But it is a goal. Or at least “be healthy” is the goal. Eating healthier might actually be the resolution (the thing you promise to do) that you need to make in order to reach that goal. A specific number of vegetables per day, say.

What this reminded me of is outcomes versus outputs. I’ve seen it a lot around my office as we talk about orienting OKRs around outcomes instead of outputs, and often struggling to hit that mark. The “output” for a software development team is the features developed, but the “outcome” is an improved product by some measure important to the business. The “output” is number of vegetables you eat, the “outcome” is being healthier. On the surface the difference makes a lot of sense. One is what we actually want, the other is just one of many possible ways to get there. I try to make the same distinction around automated testing. It doesn’t make sense to me that my title is “QA automation developer” because “automation” isn’t the goal, it’s just one kind of output towards our goal of building better products.

That said, a month ago John Cutler commented:

This is why it’s so hard, especially at first, to articulate a difference between them. If we do want to convert from output to outcomes, we can ask “why” repeatedly, to go from “eat vegetables” to “be healthy”, but we risk going so far from where we actually operate that we lose sight of how we’re actually going to achieve that. Given an outcome, you need to start asking “how”. The reason people don’t want to start with the output, the how, is because we want to avoid being prescriptive about methods when any method would do just as well. If there’s another way to improve how we test, then I should be just as free to work on that as on test automation. Further tweets by John in that thread talk about “bets” instead, which makes sense to me. Given a desired outcome, we make bets on how to achieve it.

All of that is to say that I’m not entirely convinced that there’s a useful distinction to be made between resolutions and goals. It’s very easy to weasel a statement of one into the other. That said, which are these?

• Blog once a week… to hold myself accountable to thinking about testing ideas more deeply.
• Catch up on one webinar or training video per week… to keep expanding my range of knowledge and stay up to date in my field.
• Read one non-fiction book per quarter… to learn more about established ideas in the field.
• Pursue more active involvement in local tester meetups… to give back to the testing community and build my own local network.
• Make a short video about testing based on a popular demo of mine… to learn a new medium for teaching a new concept.
• Apply to speak at 3 conferences… to share my experience with testing in a new light (being deliberately vague here).
• Take one hour after work for productive time around the house… to make space to achieve the other things.

For a guy who doesn’t make resolutions, that’s sure a lot of stuff to do.

Do <the how> in order to <the why>.

Achieve <the why> by doing <the how>.

Same thing.