Culture, Docker, Microservices

Proximate Goals

Ironic Goals
We often meet customers, and partners, who have amazingly lofty ambitions. They would, for example, like to become the ‘Google of the Finance Sector’ or the ‘Netflix of the Netherlands’. We love these goals, and their ambition, but what we see is that they often become ‘ironic’. A goal that is way beyond the capabilities of an organisation induces such terror that it actually causes them to move away from the goal. There’s a lot of dieters out there who know what I mean. You may want to be happy and think, well, if I lose 5kgs I will be a bit happier. I know I would be. However, diets often fail and then you end up being unhappier; you used to be 5kgs overweight but now you are 5kgs overweight and a failed dieter. The shame!

We see this in organisations, too. Someone or some group, for example, decides to containerise their applications. This leads to some sort of mutiny and before you know it a memo goes out saying that Docker is now banned and that the ops team are now working on properly integrating virtual machines into the deployment pipeline.

They say what you try to save, you lose. Ironic goals are really about obsession, about holding too tightly. The things we obsess about - happiness, business success, harmonious relationships - are often the things we chase away. When I hear companies obsessing about becoming the Netflix of the Netherlands, I know they are chasing away the things they really need.

Proximate Goals
The book, Good Strategy/Bad Strategy is really quite brilliant. In it, the author, Richard Rumelt, talks about choosing options that are ‘pregnant with possibility’. The closest option to you is called a ‘proximate goal’. A proximate goal may not be related to your ultimate ambition, however, if achieving it releases a load of new proximate goals, then it’s worth pursuing.

There is a legendary story about a group of soldiers who were trapped in the alps during WW2. They had given up. They had no way of getting out. When all hope seemed lost, a soldier found a map. The group successfully navigated themselves down the mountain and back to safety. Only later, back in the barracks, did they realise that the map was of the Pyrenees. The moral of the story - any step is better than no step… unless you are about to step off a cliff. Then probably no step is better. But you know what I mean.

The problem for many organisations is that they see many proximate goals. Instead of choosing one they choose them all. Why they do this is because humans are either cowardly or stupid and are often both. We have FOMO - fear of missing out - wired into our brains. The result is that we spread our energies too thinly and - here it comes - end up moving away from the thing we really wanted, whether it’s lower costs, increased productivity or better communications.

Proximate goals don’t help you, then, unless you have the brains and guts to pick one. The one you should pick, and this is what you need brains for, is the one that is most pregnant with possibilities. What this means is that you end up zig-zagging your way to your ultimate goal, without knowing exactly which path you will take:

Proximate Goals

 

Now, for some people, this is terrifying. An emerging plan - AAAAH! For others, however, it’s liberating. As the people who help run CS, all Pini and I have to do is choose the next option. That’s it. Based on an understanding of the market place, our capabilities, the cumulative balance sheet and how much energy we have, we pick one thing and then we do it. Once we’ve done that, we pick another. Over time, a coherent path emerges from this process:

Proximate Goals

Please note, the path is only coherent in retrospect. We could not have predicted that we’d end up working with Cisco, teaming up with Mesosphere to work on frameworks or that we’d end up hosting our own conference. And yet, here we are.

The process of weighing up, choosing and aggressively pursuing proximate goals are what we think of as strategy.

Proximate Goals are the Key to Success with the DCOS, Mesos and Docker
I want to be very clear now, proximate goals are often not things like ‘use Docker as part of the deployment process’. That’s way too effing big. A proximate goal is something like, ‘send Fred’s team to DockerCon’ or ‘get Frank and Lukasz to spend one day building and deploying a service’. These proximate goals are pregnant with possibilities. I.e. they will open up the path ahead by triggering the imagination.

I was part of a project that used this idea to devastating effect. At HolidayCheck, in Germany, we focussed on small things, such as deploying one service or moving off site for a day so different team members could share their experiences. Each step opened up new ideas. The managers at HolidayCheck consistently, and systematically, worked through a number proximate goals. After a few months, without much fuss or obsession, Mesos and Docker were working in production and all the teams were comfortable with the tools.

Once a company gets to a place where HolidayCheck currently is, I always say they are ready for the DCOS. The reason is simple and twofold:

  • If you are at a state where you are regularly deploying to Mesos with Docker containers, then your communications must be firing. Many proximate goals on transformations, like the one at HolidayCheck, are about improving communications.
  • Since Mesos forms the core of the DCOS, the step to it is simple. Actually, it’s the next proximate goal and it will be easy to achieve.

 

Conclusion
We think that the strategist is someone who has a grasp on reality, including the capabilities of their team, has imagination and vision. Because of this, the strategist draws people into coalitions.

Proximate Goals - The Strategist diagram

Surrounded by people who at least for the moment ‘click’, the strategist can direct the group to their next proximate goal. The systematic pursuit of proximate goals leads to larger goals being achieved without necessarily obsessing about them. It is this process that allows companies to ready themselves for things like Docker, Mesos and the DCOS.

Comments
Leave your Comment