Reasoning about vision, solutions and culture

And how to align them in a relatively big and young organisation.

Jumbo has a relatively big, and a relatively young technology landscape when it comes to E-Commerce. With the high demand of functional improvement and the strong move towards a Service Oriented Architecture we have to make sure that we align on our vision of the current and the future landscape.

But how do you align on a ‘vision’? What is a vision, and does such a thing actually exist as a general line to work towards. Can it be wrapped in a single or maybe a couple of sentences and then bring enough value so everybody knows where to go to?

The answer is usually complex and full of nuances tailored to a specific subject. You hope that the majority feels the same and understands the baseline and rationale around which future is most bright. But the reality is usually that many people are either confused, think they go the right way but actually move into a different direction or feel paralysed to move to begin with.

Coming to a consensus

We work with many people, and solutions, visions, cultural values and decisions can be approached from many angles. But they are all interconnected. Every movement within the machine that we call an organisation contributes to the bigger movement that has something to do with our customers or employees. It’s just super hard to reason about it if there’s no structured format to do that in.

You need to understand how this piece fits in the machine.

Since everything is interconnected, it makes a lot of sense to treat all these points of discussion as a node in a graph. Think of it as a map. One village has a road to another village which brings us to a city that leads us to our jobs. Or; one reason leads to another reason, which leads to a solution that addresses multiple other reasons that benefit our customers and puts the bread on the table.

An example with Vue

I started to pick a random thing we do or value. Let’s pick the topic “Vue”. You might or might not already know that we use Vue to do our frontend rendering.

Using Vue, leads to isolation, since components contain all their behaviour and style in an isolated fashion, and Vue stimulates you to do so.

Vue is a JavaScript library, and in order to successfully use it in production, you require something that renders it on the client. It’s a requirement.

In order to mitigate that, we apply Nuxt as a solution for Vue server sided rendering.

Why Vue and not some obscure other framework? Because it’s one of the dominant frameworks adopted by the market.

But WHY

It’s nice that Vue leads to isolation, but why would we need that? And cool that you say server sided rendering, but why is that? Might seem trivial to you, but not to everyone else! So explain that to me. Ask why, until it becomes obnoxiously clear that you don’t want to differentiate any deeper. E.g. You can lead everything back to money or the right of existence in the end, but we really really value the customer experience over maximising financial gain. So that’s where you can draw a line. That’s where you don’t go any deeper.

So let’s do that for a few of them.

There are evidently A LOT more factors that are in play and this graph is a strongly reduced in the complexity it deserves, but these are something we can fairly quickly reason about.

Each of these reasons and reasons behind reasons should be validated by the people that are specialised in them. The more people you talk to, the better your understanding of the reality you have in place will become.

So what does this do for me?

It allows you to reason about one particular piece of your landscape.

Let’s say you want to interchange Vue for React. You’ll still have to address the reasons you chose Vue to begin with, in this case, server sided rendering and isolation. Perhaps somewhere else you also have a decision made that you want to have the least amount of frameworks possible for whatever other reasons attached. You will have to adhere to that as well, and how does introducing a new framework go with that definition? It’s a live documentation

You can segment the topics you talk about and zoom in.

And you can steer the dimensions in which you want to talk about it.

For nodes, I took:

• reason
• solution
• culture
• decision
• warning

For edges, I took:

• leads to
• enables
• because
• requires
• contradicts

Our diagram is becoming pretty huge, pretty fast. And you don’t want to be bothered with all the choices, all the time. So each node has an attribute ‘domain’ that we can use to focus on a particular domain. Attributes can be added at any moment in time to increase granularity on which you want to run a query. For example, it’s not unimaginable that we’ll add a ‘weight’ attribute to the edges, to know how much of the reason this edge was to justify the node.

You can query stuff

One of the things we query is in example which reasons don’t lead to other reasons and thus might be the sole reason we do things.

You can start asking all kinds of things; like

• we say we value a safe work environment, but what do we actually do to get that in to place and where does that lead to?
• how does a functional domain adhere to the business goals, and to which it doesn’t
• who should I go to as a domain expert on this subject (could be an attribute)
• which department addresses which responsibilities, how are they accountable

The possibilities are endless. By having all this information in a structured way you can easily apply a variety of angles that give you insight in your behaviour as an organisation.

You can reverse your reasoning

Once you understand why you do things on a deeper level, you can also reason backwards. e.g. if you need isolation in order to get ownership, what do you actually do to stimulate isolation. Perhaps there are more ways to get to this goal than you are doing now.

Or when you say you want to make money, but you only apply cost saving measures, you might think again which things you can do as well that might lead to that same goal.

This is a great tool to help you to reason about your blind spots.

Autonomy because of boundaries

By putting all reasons, decisions, solutions, warnings and cultural goals in one graph, you create a transparent vision carried and discussed on by many in a structured way.

Because new effort has to fit in the diagram and battle with all the rationale in there, you create hard boundaries. And whenever someone thinks these boundaries don’t apply to them, or don’t give them enough room to do the right thing, there should be room to discuss and see if we should change them so that all can benefit. But you should at least be able to reason about it from a common base.

Teams can now attain true autonomy while still fitting in the structure of the organisation.

When we fail to set boundaries and hold people accountable, we feel used and mistreated. This is why we sometimes attack who they are, which is far more hurtful than addressing a behavior or a choice.

Brené Brown, The Gifts of Imperfection

We need boundaries to bring out the best out of ourselves and others.

When you ask 22 people to play a game on a huge slab of grass, they’ll all do their own quirky thing they like. It might be fun for themselves but they will never attain greatness on that field. There’s just no coherency. Only a few will buy tickets to watch them and probably because of personal relationships.

But when you instead create clear boundaries.

• one guards the goal, no ball should go in
• a couple prevent the ball from going in the goal
• some run towards the other goal when they get the ball and shoot it in that square
• no touching with hands, only feet
• … you get it

you start to play an actual game, in which you can excel. People take sides, cheer and root for you and you can stress the limits of what’s possible.

Disclaimer: The information that is shown in these images is created as an example, and do not represent the actual rationale within Jumbo.