Goal trees and goal wording

I set different goals, sometimes as small as a todo list item, such as “reschedule meeting” and sometimes as large as “Expand human settlement to at least 3 new star systems”.

Some goals are tracked diligently, while other are simply ticked off a list when they are achieved. Some are incredibly short term (do before lunch) while others are longer term (multiple years). Some are completely independent of each other while others are heavily dependent, or even contradictory.

So I thought I would explore how goals relate to each other, rather than just trying to define individual goals.

Actions as goals

Let’s start by admitting that I often use the term “Goal” loosely to mean a combination of:

• An ambition or outcome that I want to see happen (a real goal); or
• An action I want to take that will help accomplish a goal (which is really an action and not a goal).

“Reschedule a meeting” is not an outcome, it is an action I want to take, probably because I want to avoid a calendar clash or adjust for a change in circumstances.

But what about “Deliver the requested features before Christmas”? Technically I would say that this is a series of actions that are needed in order to achieve the goal of something like “Customers can use these features before Christmas” or something like that. But I will sometimes say “Our goal is to deliver these features on time, so we need to (perform these actions).

The beginning of a goal tree

This is where a goal tree might start to come in handy. Rather than trying to clarify our goals by trying to clarify a single statement (Turning it into a SMART goal, wording it from the customers perspective etc) we try to work out where the goal/action/aspiration fits into a bigger picture.

Once we understand the context of our goal, then it is likely to become clearer to us and we can refine it better after that.

Let’s assume that we want to build a set of features to meet a compliance deadline of 24 December. To do this we want to run a workshop to break the work down and then we want to do some estimates, some building and testing of stuff and so forth.

Define a goal

Rather than start at the beginning and come up with lot’s of tasks, I might start at the end, with the goal I think I am aiming for.

Work out what has to happen in order to achieve that goal

Next, I ask myself “what will have to happen for me to achieve that goal?”.

In order to achieve my goal I might:

• Define the gap I have
• Bring the team together to come up with a plan
• Fill the gap
• Say thanks to the team

Now I can create a simple goal tree:

That’s it really – that is a goal tree. But it can be useful:

• I can iterate and validate it by asking “If I do these things … Will this be the outcome?”;
• I can innovate a little by asking “If I did NOT do these things, how else could I achieve the outcome?” or
• If I am asked to have measurable outcomes then I can look at my tree and work out where to measure something.
• I can validate that is makes sense by going from the bottom to the top and asking “If we do this … will that happen?” or “If I do these things, what else has to happen for us to achieve the outcome?”

If I am happy that this will be my plan then I can refine my actions (white cards) to be actual goals by asking myself “If I did this action, what would the result look like?” and then I can break each of these goal into actions. Why don’t we make it fancy by calling the white cards milestones and making them blue.

I think you get the picture.

But the words “team motivation is good” is not really an action, it is an outcome. This can be a bit vague and as a result this is where goal trees really come into themselves.

Outcome or improvement goals

I want to turn “team motivation is good” into a SMART goal because SMART goals are all the rage. But if I try to wordsmith something abstract, like motivation, then I might get something lame like:

• Team motivation increases by 10% compared to last quarter.

This sucks as a goal because:

• My original plan was to say thankyou to the team and now it appears that I am increasing my scope to say that the team will rush through some compliance changes before Christmas and then feel more motivated at the end of it. I suspect that the team might feel relieve, rather than motivated, or they might even just switch off and go on holidays; and
• If I see a 10% increase in motivation then I need to baseline it. To do that I can roll out a surprise engagement survey, but that might not actually help the team increase their motivation in the 12 days before Christmas; and
• Even philosophers are still debating what motivation is and how you know a developer or designer is motivated. Indeed who can truly understand the motivations of another.

So let’s just skip thanking the team and let them be miserable, unmotivated wretches as they head out of the office the day before Christmas.

Come to think of it, “no compliance failures in production” is a bit scary too. What if our clients breach IS90210 with their weak story plots, 2-dimensional characters and lame acting when using our product? What if there is an existing (minor) compliance breach that we already have a workaround for, will it be fixed by Christmas?

Let’s skip thanking the team and also setting any goals around compliance in production. As long as we deliver some features we can have clients with compliance problems and a miserable team. Merry Christmas indeed.

Or – let’s try a goal setting approach from GQM, an approach that I mentioned in my last article (https://kingsinsight.com/2022/12/04/setting-goals-if-you-are-using-gqm/ ).

Measuring is not the problem – it is knowing what you mean that matters

According to GQM (Goal-Question-Measure), we should start by understanding our goal, before we worry about how to measure it. So the problem is not that we cannot measure motivation, it is that we may not have defined it.

Similarly, we can do a little better than “no compliance failures” or “less than 3 times being fined for compliance breaches”.

Add a perspective to the goal

When I learned GQM, as a process improvement tool, we got told to always measure value from someone specific’s perspective. Not “no compliance issues” or “team is motivated” but:

• Team motivation is good, according to the team members; or
• No compliance breaches from the perspective of our audit team.

Now we are getting a little more concrete than before. We have not fully unpacked things but we have a statement that people can argue with.

Clearly we do not want to evaluate team motivation from the perspective of the manager, or the HR consultant. We want to ask the team. Which means that we can come up with questions to assess the motivation, such as “are you guys motivated?”. We can also break this down into specific areas as smaller goals:

Now we can argue about what we are really trying to achieve. Even the questions we might ask are going to potentially help us refine what it is we have as a real goal.

When we go to measure something we can now come up with something a lot simpler – we can just ask people a couple of questions in the retro, or do a quick survey or whatever.

That might be sufficient, but lets use the tree structure and a bit more structure to break down our compliance goal. Firstly we can see if we are happy that we want no compliance breaches “from the perspective of the audit team.”

This is a different goal to “no items from our initial gap analysis are left out” or “Clients perceive the product as compliant and sign off on it” or even “The team feels that their compliance mojo is strong.”

But maybe it is not just that the audit team is happy. They might have the old checklist or they might just review the risk before we go live. It is possible that something is not apparent when assessing the product, that becomes apparent when we are in production. It is good to have happy auditors on 24 December, but what we really want is a fit for purpose product.

So the full wording I learned with GQM goals is:

• We want to ??? (verb)
• The ??? (adjective)
• Of the ??? (noun)
• From the Perspective of ???

So we want to ??? the ??? of the ??? from the perspective of the auditors. This could be

• We want to understand the number of compliance gaps from the perspective or our auditor; or
• We want to eliminate all compliance breaches from the checklist from the perspective of the auditor.

That is a lot more concrete and easier to argue about.

Again though, we could use a tree to help us flesh this out:

We still need to complete the rest of the tree, but we are no longer agreeing on something vague. We can see where we disagree and where things don’t seem to connect properly.

So the goal tree and the extra discussions about what, specifically, we want to achieve, make it easier to:

• Create shared expectations;
• Define what we really want to achieve and how we think we will achieve it; and
• Create metrics that do not suck badly.

For each goals like re-scheduling a meeting this is probably overkill, of change and improvement goals I would say that this will almost always save time and support better collaboration toward shared outcomes that can be measured and celebrated.