Skip to content
All posts

How to debug your goals

Goal-setting is hard. It’s hard, but important. It feels like it should be easy, but it’s not. There’s a thriving ecosystem of consultants, books and advice around it all as a result. It has spawned a whole area of business jargon.

I’m betting most of the people reading this have experienced most of these at some point. Companies have missions, visions and goals, backed up with strategic objectives according to their operating principles. Maybe there's a BHAG (big hairy audacious goal). There are KPIs, OKRs, goals of various shapes and sizes (sprint goals, team goals, quarterly goals). Milestones are broken down into epics which are broken down into user stories. Maybe you have bets, plays or staging posts. At some point, someone’s questioned whether it’s an outcome or an output, or whether it’s a strategic or tactical goal. If the semantic arguments about the difference between an objective and a goal start, then you’re really in trouble.

Urgh, I’m exhausted already. And then you have status reports on your dashboards that feed into the score cards which are meant to influence the quarterly planning but the truth is all of this has only a passing reference to what’s actually on your backlog.

Introducing the why-what-how regression

Having good goals is important. A good goal can energise teams, create focus, keep people aligned and keep them collaborating effectively. Good goals are easy to understand and cascade through the entire organisational hierarchy. But all this complexity isn’t helping. A lot of the language and frameworks around goals really stand in the way of people creating that clarity and top-to-bottom link-up.

Here’s my tip. Throw away the labels and jargon and ask, does everyone have a “why, what and how” for their work?

Why: Why is this work important?

What: What is the work that needs to be done?

How: How are we going to get that work done?

Teams often work with goals like this:

“We’re building the ability to upgrade subscriptions online so that customers don’t have to call customer services. This should be added to the 'my account' section”

The Why, What and How are there, if you look for them:

  • Why: so customers don’t have to call customer services
  • What: The ability to upgrade subscriptions online
  • How: Add an upgrade page to the “my account” section.

At this point, a reasonable proportion of you (probably those of you with a bit more of a product management leaning) are going to respond with this:

"But that's not a very good goal"

And you're right! At some point someone or some group of people have probably gone through a chain of reasoning and come up with goal. Now they’re focused on the work and have forgotten how they got there. For the engineers working on implementation, “not having to call customer services” is a perfectly reasonable driver for the work. But it's not actually focusing on the value that initiated the work.

Actually, someone could try to make this more business-value-oriented:

  • Why: Reduce wait times for people trying to contact customer services
  • What: The ability to upgrade subscriptions online

Hang on, that doesn’t seem to hang together so smoothly any more. There’s an inferred leap from the why to the what that’s not made explicit. Instead, the why-what-how breakdown exists on multiple levels, and each “what” provides the “why” for the next level down.

Goals exist on multiple levels

A breakdown of how one level's why, what and how cascade to the next level

I call this the why-what-how recursion. Every layer has the same structure, taking in the previous layer as input. In theory… Rinse and repeat and you can go all the way from company vision to a single commit and back up again.

As a fairly contrived and simple example, consider my fantasy company that’s targeting cat owners:

Goals cascading down from company to department to team to sprint

Some goals have multiple "hows", each of which will become a separate goal for the next level down, but all of which will share the same "why"

I like doing this as a bottom-up exercise, as it’s really easy to find the spots at which your engineers lose sight of why they’re doing what they’re doing. This in turn makes it easy to spot where there’s communication issues or lack of clarity.

Watch out for engineering teams working on a “what” that has lots of “whys”. Having too many drivers easily leads to the “what” taking more importance than the “why” (because it’s simpler and therefore easier to understand and remember), which in turn leads to work which is larger and less impactful than it could otherwise be.

I’m not suggesting you use this as a framework! But it is helpful in debugging the framework you already have.