How does NASA organize a company party?

They planet ...

We fear uncertainty

We fear uncertainty. We don't start walking until we find an approach that's guaranteed to work. How can you know what you are doing when no one has done it before? 

The secret is to start walking before you see a clear path. If you stick to the familiar, you won't find the unexpected.

First-principles

Reason from first-principles. Doubt everything you can possibly doubt until you are left with unquestionable truths. That's where you start. With each commitment, each presumption, each budget item, ask yourself, what if this were not true? Why am I doing it this way? Can I get rid of this this or replace it with something better?

Compare oranges and apples

Approach life not with the assumption that we know (or should know) the answers, but with the desire to learn, experiment and absorb. Compare oranges and apples, look for connections between seemingly unrelated things.

Tackle the hardest part first

If your goal is one percent improvement, you can work within the status quo. But if your goal is to improve tenfold, the status quo has to go. You must then start with a blank slate and question all assumptions. Picture the perfect and ask what it takes to build it. Move backwards. Tackle the hardest part first.

Problem reframing

In schools we are taught to answer problems, not to reframe them. Problems may have multiple causes, don't stick with the first that pops to mind. Don't fell in love with your favorite solution and define the problem as the absence of it.

Opinions are sticky, hypotheses not

We undervalue evidence that contradicts our beliefs and overvalue evidence that confirms them. Opinions are sticky. Instead, generate several working hypotheses. Opinions are defended, but working hypotheses are tested. Your goal should be to find what's right, not to be right.

Failure is success if we learn from it

Celebrate lessons from failure, not failure itself. Good decisions can lead to bad outcomes. In uncertainty, outcomes are not completely within your control. Focus on the variables you can control – the inputs – instead of the outputs. Even if the project fails, you can take the input that worked and use them elsewhere.

Surviving your own success

When we succeed, we believe everything went according to the plan. When we succeed we stop pushing boundaries. Surviving your own success can be more difficult than surviving your own failure. Instead of risking something new, we maintain the same "proven" formula that led to our success.

Remain in Day 1

The rocket-science mindset requires remaining in Day 1. We must keep devising thought experiments, taking moonshots, proving ourselves wrong, dancing with uncertainty, reframing problems, testing as we fly, and return to first principles.

That's the mindset of a rocket scientist!

"Think Like a Rocket Scientst" by Ozan Varol

How do you deal with complexity?

When we are going to do something we have done before, we know what we don't know. 

We know where and why delays are likely to occur and we usually know what to do if something goes wrong. We can plan the steps ahead. In this world, clarity and process optimization is good.

Wicked or complex problems on the other hand are different. There is no one right answer. There are no agreement on what the problem really is. 

You face many stakeholders with conflicting objectives. No solutions are right or wrong. You can make the outcome better or worse, but you are never done. Forcing clarity in this world will inevitably hinder innovation.

Getting married is not complex, but having a happy marriage is. There is a manual for getting married. But there is no "best practice" for a happy marriage. It's the sum of many small parts which makes it difficult to make a detailed plan. You cannot copy someone else's work and expect the same results because no two complex problems are alike.

All the analysis, plans and methodologies used to build a car are useless if your problem is car traffic. A car slowing down will cause ripple effects in the traffic difficult to predict. The issue with traffic is not the cars, the buses, the bicycles, or the pedestrians. It is in the relationship between them.

Building the Titanic out of LEGO bricks is not complex. You can simply follow the instructions. The whole equals the sum of the parts.

What about development of digital products that you haven't built before, either at all or in your context?

Market conditions change. Technology is changing. People's behavior change. We don't quite know how we are going to do it. We don't know what people want. You don't know what you don't know until you do something and get feedback. That's when the actual development starts.

Leading in complexity calls for something other than plans and best practices. Sense what's happening. Get some data. Take small actions based on the data and see what happens. Learn from it. Do more of what works, and less of what don't. Find the small changes that have a large positive effect.

Easier said then done. We are humans and we fear uncertainty. When we face uncertainty, we often manufacture excuses for not getting started. We don't start walking until we find an approach that's guaranteed to work.

It's hard to say to your stakeholders that you don't know exactly if it will be a success, when it will be finished and what it will cost.

What we can do is to deliver something early and often and let people try it and give feedback. 

We can also share what we believe (our hypothesis), what we will do to verify it, how we will measure it, what we observed, what we learned from it and what we will do next based on that.

In complexity, how do you measure success? You get what you measure you know ...


Beyond Budgeting

Believing that Beyond Budgeting is just about budgets is as wrong as believing that agile is just about software.

How do we define performance and how can we best enable the organization to deliver that performance? That's what Beyond Budgeting boils down to.

It addresses both leadership principles and management processes, and the importance of the coherence between the two.

Beyond Budgeting separates the budgeting purposes and solve them in three different processes because they are about different things. We can then let each process run on a rhythm much better suited to each purpose and to the kind of business we are in.

Target

An aspiration, what we want to happen. Difficult when there is a lot of uncertainty. You must make assumptions. 

It doesn't help to hit 12.7% if most competitors are delivering better. What we want is the best possible performance, given the circumstances. 

A football team will not state that the ambition for the next season is to score 45 goals and reach 39 points. It is all about performing well against, and hopefully better than, the other teams.

Forecast

What we think will happen, whether we like what we see or not. 

The purpose is to support decision making. The further ahead we look in forecasting, the more uncertainty there is. We then need to forget precision and think more in terms of scenarios and ranges. 

Sometimes we must also accept that we don't have a clue about what lies ahead. Focus on creating options and agility so that we can move fast when the fog clears.

Resource allocation

Optimization of scarce resources, what does it take to make it happen? 

We want to move from questions like "Do I have a budget for this?" towards "How much value will this create?" and "Can we afford this as things look today?". 

Leave behind a myopic focus on low cost in favor of a more value-oriented thinking. There are both "good" and "bad" costs. Good costs create value, and bad costs don't. Spending is fine, wasting is not.

Separating target setting, forecasting and resource allocation should never be done sequentially. It must happen simultaneously.

How do we evaluate performance?

Performance evaluation must be holistic. Not everything that counts can be counted, and not everything that can be counted counts. 

The "I" in KPI stands for "Indicator", not "Truth". 
  • How did we achieve our results? 
  • How ambitious were the targets? 
  • Was there a headwind or tailwind? 
  • Which risks were taken? 
  • How sustainable are the results? 

These evaluation questions require more effort than comparing two numbers.

Hitting a target does not necessarily mean that this was the best performance possible because it assumes that the "right" target was set.

Beyond Budgeting is a journey where the direction is clearer than the destination, if there is one.

Changing what we do helps little unless we also change how we think. That is the hardest part.

"This is Beyond Budgeting" by Bjarte Bogsnes

Wild west to Agile

History's role is not to help us predict the future, but to prepare us for it. 

Jim Highsmith's career over the last six decades is a good start.

In the Wild West Era (1966-1979), software engineering was in its infancy and the knowledge of how to "do" software development negligible. This era was wild.

The Structured Methods and Monumental Methodologies (1980-1989) era was an attempt to go from the undisciplined wild west to a more disciplined and formal approach, trying to be recognized as an engineering discipline. 

IT projects were generally viewed as out of control, and business managers assumed building software was the same as building a warehouse. Focus on tasks rather than people and team dynamics.

A formation and expanded use of waterfall, control-oriented, and process-heavy methodologies emerged assuming that documentation was sufficient to communicate between groups with no need for further explanation. Variation from the plan was seen as poor execution.

Despite of this, the approaches managed to deliver value. The success and failures of one era form the base for the next.

"IT projects take too long, costs too much, and don't meet our needs". Welcome to The Roots of Agile (1990 - 2000). In response to executives cries for help, software developers began experimenting with iterative Rapid Application Development (RAD and RADical) methodologies, especially for Internet applications.

Focus on value, quality, speed, leadership and collaboration. Waterfall couldn't handle the level of uncertainty with new technology and changing requirements.

The Agile era. On February 11-13, 2001, 17 people met to find common ground, the Agile Manifesto.

The Agile movement is not anti-methodology. It's about restoring a balance. They embrace documentation, but not hundreds of pages never being maintained and rarely used. 

They plan, but recognize the limits of planning in a turbulent environment. Keep well-working teams together rather than continuously reorganizing them.

In the beginning, individual teams received dispensation to try this "agile stuff", and occasionally several successful agile projects were completed, but they where often downplayed: 
  • "It was just a small project", 
  • "It was a new project", 
  • "They didn't have to follow our standards".

Management wanted agility, but with traditional performance measures. To change behavior and culture, you must change measures of success.

In the current Digital Transformation period (2011 - present), the problem isn't scaling Agile, but enterprise-wide scaling of agility and innovation. 

We need to move from predicting and planning for the future, to building a platform that enables us to adapt to whatever happens.

Preparing for the future challenges us to scale an agility mindset, not simply agile methods and methodologies.