Guaranteed Success in 5 Simple Steps

Contrary to popular belief, achieving your goals is simple.

Simple — I said — not easy.

Here’s the universal recipe:

1. Decide where you want to go, and how you will know when you get there.
2. Establish where you are right now.
3. Decide what you’re not willing to sacrifice to achieve your goals.
4. Iterate: (1) Decide on an initiative that you hypothesize will make an impact on getting closer to your goal. (2) Implement the initiative. (3) Evaluate if you got closer to your destination and at what cost (sacrificing the right thing?), learn from this experience. (4) There yet? GOTO 5, else: GOTO 4.1
5. Done.

Whether you’re doing food shopping, or running a large corporation; doing something highly technical (e.g. TDD), or something with people (performance reviews) — the above framework will apply. Nevertheless, it’s most valuable in scenarios where the destination is known while route to get there is not — so where some along-the-way course correction is required.

Don’t believe me?

Scrum sprint cycle:

1. Decide where you want to go, and how you will know when you get there: sprint goal, user stories with acceptance criteria.
2. Establish where you are right now: at the beginning of the sprint, with 0 story points delivered.
3. Decide what you’re not willing to sacrifice to achieve your goals: often not a huge focus in Scrum, but could be definition of done (tests written, code reviewed etc.), not adding to technical debt.
4. Iterate: (1) Decide on an initiative that you hypothesize will make an impact on getting closer to your goals: pick the top user story from “To do.” (2) Implement the initiative: Write the code that implements the user story. (3) Evaluate if you got closer to your destination and at what cost, learn from this experience: code review, code tested, ticket signed off, whatever else your definition of done says. Take notes on things that went wrong for separate retrospective cycle. (4) There yet? GOTO 5, else: GOTO 4.1: Only there when all user stories are done.
5. Done: sprint fully delivered.

Food shopping for the week:

1. Decide where you want to go, and how you will know when you get there: Determine your food needs for the upcoming week, prepare a shopping list.
2. Establish where you are right now: check your fridge for food you already have and cross out those items from the shopping list.
3. Decide what you’re not willing to sacrifice to achieve your goals: Money in wallet > 0.
4. Iterate: (1) Decide on an initiative that you hypothesize will make an impact on getting closer to your goals: pick the top item from your shopping list. (2) Implement the initiative: find it in your store, put it in your cart. (3) Evaluate if you got closer to your destination and at what cost, learn from this experience: you got closer, keep going. Perhaps consider reordering shopping list based on store lay-out next time? (4) There yet? GOTO 5, else: GOTO 4.1: There yet when shopping list is empty.
5. Done: Pay, leave store.

OKRs:

1. Decide where you want to go, and how you will know when you get there: Formulate objectives (general direction) and key results (metrics that will determine if you achieved your objectives as well as target values for the quarter).
2. Establish where you are right now: determine the current values for your key results so you know how far you have to push.
3. Decide what you’re not willing to sacrifice to achieve your goals: formulate health metrics and their acceptable ranges.
4. Iterate: (1) Decide on an initiative that you hypothesize will make an impact on getting closer to your goals: Brainstorm ideas with your team on how to move your metrics closer to the target values for the quarter. (2) Implement the initiative: Test or implement your idea. (3) Evaluate if you got closer to your destination and at what cost, learn from this experience: Did the initiative have the desired effect? If not, what else to try? If yes, how do we push further? (4) There yet? GOTO 5, else: GOTO 4.1: There when you hit your target values.
5. Done: Ready for the next quarter, GOTO 1.

Running Microsoft in the ‘80-‘90s:

1. Decide where you want to go, and how you will know when you get there: Put a computer on every desk.
2. Establish where you are right now: Early ’80s: no computers on desks.
3. Decide what you’re not willing to sacrifice to achieve your goals: nothing.
4. Iterate: (1) Decide on an initiative that you hypothesize will make an impact on getting closer to your goals: Build out a software ecosystem, starting with an operating system, following essential applications to run on top of it, ensure there’s hardware to run it on. (2) Implement the initiative: Buy an operating system, build on top of it. Next iteration: expand functionality, add more products. (3) Evaluate if you got closer to your destination and at what cost, learn from this experience: Evaluate strategy, adjust where required. (4) There yet? GOTO 5, else: GOTO 4.1: Mission was more or less accomplished around the ‘00s, so time define a new mission.
5. Done

I’ll stop here, but you could map things like test-driven development (TDD), code reviews, performance improvements plans, lean-startup aspects (validated learning) in this model as well.

This is an interesting academic exercise. I could now argue you no longer have to read many of the business books written on these topics, because they can be summarized with what I just described — which wouldn’t be really true, but still make for a good laugh (hah! business books right, nothing you cannot summarize in a 5 item bullet list!).

However, this abstraction allows us to look at some of the interesting aspects, I’d like to briefly cover two:

1. Nesting
2. Cycle time

Nesting

To run your organization, you will likely be nesting many of these goal setting processes, for instance: you start a company with a particular vision in mind, an ultimate goal to attain (ideally one you will never quite reach, but can make progress towards). Inside that framework, you may set annual goals, based on those various part of the organization may set quarterly OKRs, in product parts of the organization, those OKRs may be translated into Scrum sprints, which in terms will be translated into tickets with a loop for e.g. code reviews. That’s cool, we are engineers, we like to nest our loops.

Cycle time

A core aspect of this goal achievement recipe is the Iterate cycle. In most contexts there’s a lot of value in attempting to tighten those loops so you get feedback early and can adjust early.

When you do TDD, there’s a lot of value in the ability to be able to run all your tests in just a few seconds. The moment that becomes minutes, or longer, the value decreases or you have to be more smart about the tests your run, so you can bring down the time again to get feedback.

The same is true in e.g. validated learning (lean startup style): you come up with some idea or feature and you want to invest the least possible effort to validate if it has the desired effect. Initially, it may take you a month to run one experiment, but by investing in your testing infrastructure and process, you can cut this down significantly. Companies like Facebook and Google are famous for running thousands of experiments simultaneously. This is partially a function of the number of engineers they have working on the product, but they also have the infrastructure in place to validate many assumptions in mere hours.

Shorter cycles are usually better.

There’s an exception to this. Steps 4.1 (planning), 4.3 (evaluation and retrospection) may add significant overhead, making 4.2 (where the “real work” happens) too insignificant.

For instance, consider Scrum sprints. Common practice is to have two or one week cycles, so why not one-day cycles, or cycles of an hour? This is the point where the process is too heavy and gets in the way. If you want to do a mini-scrum sprint every day, you’d likely spend more time planning, reprioritizing, discussing, estimating, retrospecting than if you’d do this once every two weeks, and the benefit is likely not there.

In cases like this either you experiment with what cycle time is optimal, or you invest significantly in reducing the time you need to spend in steps 4.1 and 4.3.

Green Cars

How many green cars have you seen looking through the window today? Likely, you won’t know. However, now that I’ve asked the question, likely you will start noticing green cars.

Similarly, now that you have this ultimate goal setting recipe in mind, you will start to recognize it everywhere. In fact, likely you will recognize elements of it, but bits and pieces will be missing.

Now comes the interesting question: why are they missing? Is it really clear what success look like? Have we consciously thought about what sacrifices we’re willing to make to get there? Do we take the time to reflect and retrospect on how things have been going before we jump into the next thing?

And if not, is that ok?