What Is a Driver?

In this guide, you will discover the relationship between your assumptions and your achievements, and how being aware of your motivation for action – which we call a driver – can significantly improve your chance of success both at work and in your personal life. You will learn how to easily identify, understand and agree on drivers, and see how to develop projects and organize collaboration around drivers.

The Power of Assumptions

We’re used to planning and developing ventures and collaboration – products, projects, jobs, careers, teams, departments and even entire organizations around our assumptions or predictions about what constitutes a desirable and achievable future: goals, objectives, aims, strategies, purposes and visions.

Even if they often started out as a wild guess we only rationalized afterwards, the more we weave our predictions into a coherent and convincing narrative, the more they tend to take a life of their own and obscure our initial motive. But as soon as we begin confusing our assumptions with reality, the outcome is inevitably hit and miss: even if we reach our goals or realize our vision we often discover that the future we ended up with is not where we want to be.

There’s nothing wrong with operating on assumptions per se, as long as we treat them as such, and acknowledge the uncertainty contained within. Only then can we attempt to successfully convert assumptions and predictions into knowledge¹ that helps us create a present (and a future) that resonates with us.

If this is the outcome we strive for, and if we also want to minimize the investment of time and effort we require to verify or falsify assumptions², we need to base our assumptions on what is already known to us, and, in the case of an organization (or a team), what we can agree on (usually after we developed a shared understanding of the matter at hand): this is what we call the driver.

Everything Starts With A Driver

A driver is what motivates us to act ³ or collaborate⁴: a specific situation and the needs we associate with it.

Becoming aware of our motivation is essential for doing the right thing, and for doing things right.

Drivers exist naturally, both for individuals and for groups (or organizations), but the specific format we give to the description of a driver in S3 is designed to make agreeing on, learning about and evolving our understanding of a driver as simple as possible.

Drivers continuously evolve as the situation (i.e. the system) changes, so it’s not enough to identify them once, we need to continuously invest into renewing the (shared) understanding of the driver.

Both in organizations and in private life we’re almost exclusively dealing with complexity, so there’s often no simple observable relationship between cause and effect: Any group of people is already a complex adaptive system in itself⁵. A driver (whose aspects can be falsified, as we will see below) provides an anchor for experiments that help us develop and evolve knowledge about ourselves within the complex adaptive system surrounding us.

Drivers are everywhere, some examples:

• the driver for this text on drivers: since we started telling people about S3, there’s an increasing number of people interested in working with drivers, and they need some help to get them started, our time is limited, and we need an effective method to reach as many people as possible (we could also have created a video of one of our trainings, or webinars etc.)
• drivers for workshops: we often have a specific recurring problem which we were unable to fix through individual action, so we need to work together on a sustainable solution
• drivers for products: in a specific context, we can create value for our users
• drivers for features: a user in a specific context has need they want the application to fulfil
• drivers for organizations: we have an idea for a product or service, but it’s too big for one person to build it alone
• drivers for a group (or family) event: we have some free time which we want to spend it together, probably also a need for relaxing
• drivers for personal change: often habitual responses to specific situations cause negative experiences in ourselves and others, and I we a need to exist in harmony with ourselves and others⁶.

Elements of a Driver

Since a driver describes a specific situation, we can break it down into distinct elements. Each element is either descriptive, i.e. an aspect of a situation, or a need which originated from one or several of these aspects.

This structure implies there’s always different options of addressing a driver: either we cater to the needs, or we work to change specific aspects of a situation, so the need will cease to exist.

Aspects – Facts and Observations

Aspects are either facts or observations, the things we can agree upon, because ultimately we can verify, test or falsify them. Facts and observations need to be argued (i.e. we can explain them to others), and relevant (i.e. they need to bear a certain significance to the driver).

When identifying a driver, we usually compile a list of facts and observations as statements, e.g. as bullet points on a flip chart, as sticky notes, as individual paragraphs in a document. In a logbook, the logbook keeper might add a bit more background to each statement if necessary. In that case, everyone needs to review the driver to identify potential misunderstandings or tensions.

Needs

A need is simply something that is required in a specific situation, and as such needs are always related to one or more aspects. Needs exist for many different subjects, and on many different levels, there’s needs for individuals (e.g. sustenance, fairness, respect, autonomy, mastery, purpose), for groups (e.g. collaboration, shared understanding, agreement), for organizations (alignment, shared values, diversity, revenue), and also for animals (e.g. food, shelter, mating), plants (e.g. water, light), or inanimate objects (e.g. a car might require gas, or maintenance).

When identifying a driver, we usually look at the needs after collecting facts and observations. Some needs are easy to spot (and to agree on), others take a bit longer to surface. We always indicate the relationships between needs and facts or observations.

Sometimes discussing a need leads to the discovery of a new aspect. Describing the driver is finished when we have eliminated any orphan needs and aspects.

Action? Experiment!

Now that we developed sufficient understanding of our driver, we can begin to think about how to respond to it. Always assuming our knowledge about the complex system we’re dealing with is tentative, it’s best to design every response to a driver as an experiment, so we can significantly improve our odds for success: either we create an effective response to the driver, or we learn something that helps us improve our next shot.

Acknowledging all our decisions and agreements are mere experiments free us from the need to make perfect decisions, what we come up with only needs to be good enough for now, safe enough to try, and we will inspect and adapt as we go.

Experiments usually take the form of strategies, plans, decisions or actions. In S3, a strategy is our high level approach how to address the driver, and usually, there’s several different strategies we can choose from. We execute on the strategy through a number of smaller experiments which will incrementally support and ultimately prove that strategy, or we can collect enough information to be sure that we need to pick another strategy (readers familiar with the Lean Startup Method would call this a pivot).

In order to provide validated learning⁷, all experiments need to contain some form of expectation which can be falsified, so before starting an experiment, we need to think about metrics and evaluation criteria: how do we know our experiment was a success? There’s a quick sanity check: Intended outcome, metrics and evaluation criteria need to be relevant to the driver itself, or to organizing, aligning and coordinating collaboration in service of the driver.

Complexity and Organization(s)

Addressing drivers (especially those of entire organizations) is always a complex endeavor (otherwise we would not have the need for collaboration in the first place), so we need strategies for dealing with this complexity. As an organization, we need to develop a system to help us effectively orchestrate our collaboration, as individuals we need a way to focus our efforts without being overwhelmed or losing sight of the whole.

For an organization, driver constitutes a domain of accountability, autonomy and influence. In order to reduce complexity of strategies and experiments, we can create organizational structure through nested and (semi-)autonomous subdomains, e.g. by creating projects, services, roles or circles.

With our model of aspects and needs, we can easily break down a driver into a system of nested drivers (so-called subdrivers): Each subdriver is composed of a subset of the elements of the original driver (which, when viewed from the perspective of the subdriver, becomes a metadriver). Subdrivers may overlap, and they need to be complete in relation to at least one need, i.e. a subdriver contains all related aspects for at least one need. The minimal form of a subdriver contains one aspect and one need related to that aspect.

When splitting a driver, we’re often inevitably adding complexity: If we’re used to perceiving order as hierarchies, we might identify a need for alignment of our responses to the individual subdrivers. If we see organizations as networks, and, especially when individual aspects or needs of the meta-driver are present on multiple subdrivers, we might sense a need for coordination between these subdrivers.

Either way, it’s easy to express in our format for describing drivers: as soon as we discover tensions related to the structure of our driver (and thus the structure of our organization) we add new aspects and needs expressing these tensions within our drivers. For example, we might agree on creating two roles for autonomously dealing with two subdrivers, and as we experience or anticipate the need for coordination between those roles, we simply add aspects describing the existence of the other role and the related needs for coordination to each subdriver. Note that these elements are not part of the meta-driver, as they exist only through the existence of the subdrivers. This way, we can reap the benefits of reducing complexity by focusing on subdrivers, and still contain the “negative” effects ⁸ for increasing “organizational” complexity.

Navigation via Tensions

As all our strategies, decisions, plans and actions are based on drivers, our daily work experience provides many chances to learn something new about these drivers. Learning enables us to evolve better strategies, agreements, decisions, plans and actions, which will result in even more learning, or, ultimately, in a driver ceasing to exist.

The potential for learning manifests in the form of tensions: we perceive something which is not the way we think it should be.

Whenever we process a tension, we need to be aware that we can to look beyond the immediate experiment and strategy the tension is related to, and figure out if the tension might reveal insights into an existing (sub-)driver, or even the discovery of a new one.

Again, our format facilitates review and adaptation of drivers:

• we can learn about facts or observations, clearing up misunderstanding, eliminating aspects which ceased to exist, add new aspects we discovered are relevant to the driver
• we can also learn about existing needs, identify new ones, or agree to remove those needs which are now fulfilled to an extent we now consider them irrelevant

It is also a good idea to schedule regular reviews of drivers, to make sure each and every aspect and need is up-to-date and relevant, even if we missed a tension or two in the heat of our daily work. These reviews often reveal aspects which have become obsolete, or needs that have ceased to exist.

What’s next?

When viewed through the lens of drivers, will give you a fresh perspective on organizations, and life in general. I encourage you to give it a try: when you’re facing your next decision, alone, with your partner or family, with your friends, or in your organization, ask two simple questions:

• What’s happening?
• What’s needed?

Write the answers down so all participants can see them, visually connect aspects and needs, and observe how awareness of the driver affects your decisions and agreements.

Once you get started, you may soon you will begin to see drivers popping up everywhere.