Life as a facilitator

The boring, but necessary and at the end rewarding, part of it.

I remember when I invited 20 leading experts into a formal meeting room with chairs, a table and a big screen. 

I started my power point presentation introducing the challenge. Then I asked people to raise their hand if they had some suggestions on how to solve this challenge. 

Some people talked a lot, others didn't say a word. After two hours we were done. No conclusion. No solution. Just more confused.

Back then, I thought I facilitated a brainstorming. Now I realize I didn't. 

Now I realize that facilitation is an art.

A skill you need to acquire. An essential skill for any leader. Leading people through divergence, exploration, convergence and closure.

I learn something new in every workshop I facilitate. I have failed, but also succeeded.

There are three sources I use when planning a workshop. The toolbox from Liberating Structure, the team and workshop tactics from Pip Decks as well as the material from my Agile Team Facilitator Certification (ICP-ATF) from Distilled.

Do you have any facilitation superpowers or secret tricks you'd like to share?

What did I learn from playing Counter Strike as a kid?

This is me at The Gathering computer party 20 years ago competing in Counter Strike with my team.

I didn't know it then, but in this period of my life I built a foundation which I use to this day.

I learned that I couldn't win alone. Being in a team meant we were committed to a common goal, and we depended on each other to reach it. Put your own needs above the team, and we lost.

I got used to distributed and remote-only teams common in many companies today. We used Ventrilo and mIRC instead of Microsoft Teams and Slack. We met in person during the school holidays to get to know each other even better. The energy and mood in the basement when we won were unforgettable.

I didn't know about psychological safety back then, but we had it somehow. We had it because we stuck together over time through victories and losses. We learned each other's strengths and weaknesses and how to leverage it to our advantage. We respected and wished each other well. I learned that teams take time to form and become effective.

I didn't know about Tuckman's forming, storming, norming and performing stages, but I now know from my experience back then that the model is not linear. In one moment we were high-performing rock stars, but in the next we were middle in a storm. Nurturing a team is a continuous never-ending job.

I always go externally to learn from the best in class, just as we did 20 years ago playing Counter Strike. As a team we didn't start off great. We learned and became better by playing games and studying HLTV recordings from the best teams and players in the world.

I learned the importance of having a game plan, but more importantly how and when to change and adapt it when the circumstances required it. We had a plan A, B and C and when none of them worked out we relied purely on experience and intuition.

I learned that great skills and experience was not enough, it also depended on the surrounding environment. The graphics card, screen, mouse, mouse pad, configurations, headphones, and chair mattered, a lot. We needed the right tools and a support system around us. Parents cooking dinner and transporting us and our computers to wherever we needed to be.

So want to learn more about teams? Play computer games!

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

The Inevitable

Do you think a lot about technological imperatives that will shape the next thirty years and transform our lives?

Kevin Kelly does. Much of what will happen in the next three decades is inevitable, driven by technological trends that are already in motion.

Cheap, powerful, invisible, and omnipresent AI

It's hard to imagine anything that would "change everything" as much as cheap, powerful, invisible, omnipresent AI. Everything that we formerly electrified we will cognify.

We will surrender piece by piece of what is supposedly unique about humans, and we will face an identity crisis. 

The greatest benefit of the arrival of AI is that AI will help define humanity. We now question what humans are good for, what makes us special, and what is it that humans want to do. We need AI to tell us who we are. AI will help us better understand what we mean by intelligence in the first place.

Everyone will have access to a personal robot, but simply owning one will not guarantee success. Success will go to those who best optimize the process of working with AI bots and machines.

New interactions

In the coming 30 years, anything that is not intensely interactive will be considered broken. The future of technology resides, in large part, in the discovery of new interactions. 

We will use more of our body and senses to communicate with machines.

Computers are getting closer and closer to us. Computers have evolved from the basement, to smaller rooms, to our desk, to our laps, into our pockets, and now laid against on our skins (wearables). The only way to get closer than that is to go under the skin.

Personalization and instant access

We are going to pay for personalization and instant access. Anywhere we want personalization, new filtering inventions will follow. We need to pay attention to more and more sources to do our jobs and to learn. We need real-time filters upon filters to navigate the explosion of infinite choices. The filters will tell us what we want.

Hardware and software

Hard things will behave more like software due to embedded intelligence – there are so many more ways to provide a service than a hard product.

The truth?!

What's the truth?! The truth is not delivered by authors and authorities anymore but is assembled in real time piece by piece by yourself.

You make your own content and construct your own truth from the liquid stream of facts flowing through the web (hyperlinks, text, videos, images, sound). For every expert you will find an anti-expert. We have to constantly question what we think we know.

The status of creation will be inverted, so that the users, you, become the new creators. You will be a creator of digital products and content used to do your job.

Do we need more answers or better questions?

Technologies that help generate questions will be valued more. Question makers will be the engines that generate new fields. Questioning is simply more powerful than answering.

"The Inevitable" by Kevin Kelly

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.