Imagine, for a moment, that you are standing on a beach gazing out at a distant island. Your kayak sits next to you. You are planning a day trip to the island and back, and you're getting a bit of a late start; you have to make sure you'll be back by sundown.

You face a choice. You could sit on the beach and try to plan your trip in detail to make sure it will be successful. To do that, you'd have to take measurements of the strength of the wind and its direction. You would calculate the size and direction of the waves. You would have to check the weather to see if the winds are likely to pick up or calm down. You need to estimate the timing of the tides and the strength of the pull of the moon. You would also have to remind yourself to estimate the impact of currents on your course. With all this information, you would then need to make some calculations to plot your course.

Alternatively, you could check the weather forecast, quickly assess the conditions ahead of you, get in the water, and start paddling.

The smart choice is to pick up that paddle. The only way to understand the true impact of the wind and the waves on our kayak is to experience it. We can then make calculations on the fly and adjust. Using the same approach, we can see how the other invisible factors influence the direction of our kayak. We don't really need to know whether it's the tides or the current that are causing our boat to drift. We simply see that our boat is drifting, and we make a subtle change in our direction. On a calm day, we don't need to make these adjustments very frequently. But if the wind were to pick up so that the wave action on our boat were to become more violent, we would be smart to make these adjustments more frequently. Instead of adjusting our course every ten minutes or so, we might make adjustments after only two or three paddle strokes.

We like this kayaking analogy because it captures a lot of the uncertainty that we all face as we live our lives. We may all have an outcome to achieve in our mind – a better job, a more agile organization, a more prosperous community – and we want to get there as quickly as we can. The reality is that we really can't learn how to make progress toward that outcome until we start doing something. That does not mean that we don't sit for a moment, gather some information (like a weather report), and think. It does, however, mean that we don't try to come up with the perfect plan. We don't become paralyzed with analysis. We don't lock down our capacity to act by engaging our fears. Instead, we face the future with confidence in our ability to experience what we can't fully understand, to learn, and to make decisions that blend both facts and our intuition. We have enough experience to recognize that we can trust our intuition, yet we are smart enough to realize that we might be wrong. We might need to make adjustments. When the invisible forces affecting our course are strong and quickly changing, we will need to be prepared to make some quick decisions.

The agile leader understands the limits of our capacity to understand and analyze complex, invisible systems. Agile leaders are biased toward action for a simple reason: we only learn about these complex systems by doing. If we want to make big changes fast, we have to go slow … but above all, we have to go.

LAUNCHING YOUR LEARNING

When you have an outcome in your mind, it does not have to be perfect to start. Equally important, you don't need to plot a perfect path to your outcome before you do anything. In order to learn how to get from here (where you stand) to there (the outcome you want), you need to start. You start with something quite limited in scope – the first few paddle strokes, so to speak – and see what happens.

Here's why: without starting, you can easily become overwhelmed. Karl Weick, a psychologist at Cornell University, published an important paper in 1984 that captured this idea. Weick was exploring why large‐scale social problems can close down innovation. These social problems, such as increasing poverty, rising crime rates, environmental pollution, heart disease, or traffic congestion can loom so large in our minds that we become paralyzed. Sensationalizing these problems, all in the hope of mobilizing action, can do just the opposite. We easily become more frustrated, and we are more prone to feeling helpless. Weick astutely observes, “Ironically, people often can't solve problems, unless they think they aren't problems.” He proposes the idea of addressing the challenges of large problems with an approach emphasizing the value of “small wins.”

We've all been in those situations, in which we've defined a problem at such a large scale and general terms that we have no idea where to start. “Boiling the ocean” is a bit of somewhat‐annoying business jargon that captures the idea. We can never boil the ocean simply because there is too much water. In the same vein, we can never make much progress, if we set ourselves up with an impossible task from the start. We are taking on more than we can handle. Because our resources are limited, we end up spreading ourselves too thin. We end up, as Weick observes, feeling frustrated and helpless. By contrast, when we break big challenges into smaller, more manageable tasks, we not only reduce our risks, we also increase the chance of feeling good about getting something accomplished.

Weick's ideas have taken hold, especially in the worlds of design and innovation. Elizabeth Gerber, a professor of design at Northwestern University, highlights the importance of low fidelity prototyping, a closely related idea. Gerber defines a low‐fidelity prototype as a minimally detailed expression of an idea. In the case of designing a new website, a low‐fidelity prototype might simply be a drawing. For a new product, it might be a cardboard mock‐up. According to Gerber, low‐fidelity prototyping speeds up the development process. She cites a number of reasons: it reframes the possibility of failure into an opportunity for learning; it improves communication among team members; it provides the team with a sense of progress; and it increases a team's confidence in their own creativity.

There's another reason that getting projects off the ground quickly is important. They act as experiments to test some key assumptions. In the management world, good experiments help companies deal with complex, dynamic situations. Perfect knowledge is not possible, so the best option involves testing ideas. Jeanne Liedtka, professor at the Darden School of Business at the University of Virginia, calls these experiments learning launches. This concept captures the entrepreneurial mind‐set and the bias toward action. Analysis can be time‐consuming, misleading and paralyzing (think of the poor soul trying to analyze every detail of a kayak trip). In contrast, designing experiments generates knowledge about what works (or doesn't). This practical knowledge is far more immediate and relevant than a grand plan.

QUALITIES OF A GOOD STARTING PROJECT

We've concluded that there are a number of important characteristics of a good starting project:

They are short (enough): As with group size (p. 51), they follow the “Goldilocks Rule” – not so simple that they can be completed in a week, but not so complex that they take a year to complete. If the project is too short, you won't have enough time to reap the other benefits that we'll describe in a moment. If the project takes too long, your team can easily get bogged down and discouraged; 90 to 120 days is a good length to avoid both of these risks.

They engage everyone on the team: They build trust among team members, but this can't happen if only part of the team is involved. This usually happens for two reasons: First, the idea may be too simple. If it is too easy the group will lose interest early and could disband before the more difficult work is addressed. What's too easy? As long as the idea will take at least a small contribution from everyone, it's big enough. Remember the planters the citizen's downtown improvement group wanted to build? Although it's straightforward, there was plenty to do: pick locations, get permissions, buy materials, assemble the planters, and make a plan for ongoing maintenance. There is another bad habit we are trying to overcome with this idea. Many of us are in the habit of coming up with good ideas for someone else to do. This tendency works against the formation of a cohesive team. You can't outsource this process.

They create a “buzz,” garnering attention for the work: They present a wonderful opportunity to create a new story, a new narrative, about what is possible through collaboration. Every organization and community has a narrative. Too often these narratives look backward. They are often cynical. A good starting project provides a new narrative to explain what is possible if we align our efforts and adopt new ways of thinking and behaving. The team provides a model to follow.

They test some key assumptions: At the early stages of a collaboration, we are making some key assumptions. An early project enables us to test some of these assumptions and accumulate new insights. For example, a low‐fidelity prototype often tests customer acceptance: Will customers be willing to pay for the product, and how much? A Chamber of Commerce hosts an afterwork event downtown. Will this idea draw enough people to launch something like a “First Fridays” series? A company wants to retain its young talent. Will more professional development opportunities help?

They don't require permission: It's important to work on a project that can start immediately. That is, the team designing the project does not need permission to launch it. It is important to move a potential collaboration out of the talking stage quickly. Otherwise, the probability of success declines dramatically. Team members lose focus and enthusiasm when permission becomes an obstacle – you suddenly find yourself back in “If Only Land.” Avoid this by designing a starting project that does not require permission. You are better off scaling back a project than designing one that can be easily delayed or derailed.

KEEPING THE TEAM ON TRACK

A starting project does not need a detailed project plan with milestones. However, it does need a logical route to follow, and it's useful to mark the path with guideposts – just a few key points along the way that will warn you if you're getting off course. In this way, guideposts help a team manage risks. Much like walking a trail, the team knows that if it misses a guidepost, it should stop and figure out why. Should they reset their course? Is the project too ambitious? Has a key assumption failed? Deciding on what the guideposts are should be also confirms that you'll be able to complete the project in a reasonable time. Remember, you are using your project as a learning process to figure out what works.

Here's an example from our work. Suppose a corporate team comes together to design a new approach to managing customer relationships. The company has multiple divisions, each selling a different product line – primarily business office equipment and furniture. Some, but not all, of these business units have customers in common. Originally the divisions were separate companies, and over the years, various mergers and acquisitions have resulted in a single company. However, each division has its own sales operations, and each of those uses its own “customer relationship management” (CRM) software platform. A CRM includes all the relevant data about each customer – contact information, sales history, deals being negotiated. These CRMs do not communicate with one another, so if a customer from one division decides to buy a product from a salesperson representing a different division, that salesperson has to enter all of the same information over again in the new CRM, process a new credit application, and so on. This is a huge waste of time for both company employees and customers. The company's upper management team defines an outcome of deploying a new single CRM across the company over the next two years. This system would include the capacity to analyze data to identify new cross‐division sales opportunities as well as to flag problematic customers who take an inordinate amount of support or who do not pay on time. It would be a big shift for the company with a great deal of training required, but one the team is convinced will pay off handsomely in higher productivity.

The team defines their starting project as combining just a sample from two divisions' CRMs as a pilot. They reason that by installing this system on a small scale first, they can spot problems that might crop up before they launch a larger scale deployment. The team decides that the project will be up and running in 180 days. If all goes well, they will then integrate the two divisions' data into one CRM that could be expanded to other divisions. To set the guideposts for the project, the team then decides what has to be done in 45 days, 90, and 150 days, if they are to stay on track. So, for example, within 45 days, the team agrees it must decide on an outside vendor to help design the pilot and complete the specifications for a deployment that could scale across the entire company. In 90 days, all the test data needs to be uploaded. In 150 days, the training process for the sales team should be developed and approved.

WHAT NEXT?

Those first tentative paddle strokes will give you important information, but it wouldn't make for a very satisfying day on the ocean if you stopped there. It's best to think of our initial project as both standing alone and at the same time part of a series – when one is complete (or nearing completion), you'll see what the next one should be. You'll know what adjustments to make based on what you've learned, and possibly have identified some challenges you still need to learn more about. And while the kayak may be strictly a one‐person craft, there is plenty of room for others to join you in pursing the goal you've set for yourself. That “buzz” you created means that you now have a bigger team and your next project can be bigger in scope.

Here's another example of this skill in action: a team of HR leaders has come together to think about its management training program. The company's current program targets “up and coming” young talent. Participants attend a series of weekend courses over the course of two years; at the end they have earned about half the credits needed for an MBA degree through a local university; many then choose to complete that degree on their own. The number and quality of applicants has decreased over the past few years, primarily because supervisors have to “nominate” participants and agree to pay about half the tuition cost – and the “word on the street” is that the program isn't worth it (and more generally, the MBA degree isn't in as much demand as when the program started more than 20 years ago). The team would like to create a set of courses based on simulations and other more modern learning approaches. They know that eventually the company's “top brass” will have to approve the new program, but several of those individuals came through the current traditional program and view it very favorably.

The team decides that these kinds of major changes in the curriculum will never happen without strong support throughout the company – beyond just the HR department. The team decides to test the assumption that this support can be galvanized. They design an initial project of creating a class that uses a “pop‐up” format. Pop‐ups are informal, noncredit classes that “pop up” informally for just a few sessions, and they are a great way to test student interest in a topic quickly. They hope a dozen or so participants will come to a one‐session workshop on creating budgets – a modest goal, since it's scheduled for a weekday night, and they're not offering any food or drink. To their delight, more than forty employees show up. Not only have they demonstrated that there is plenty of interest, a few of the participants attending ask if they can be part of the re‐design effort. Their next project, with an expanded team that can handle a bigger challenge: a series of pop‐ups.

PUTTING THE SKILL TO WORK: THE AGILE LEADER AS EXPERIMENTER

Applying this skill means reminding yourself of where you want to go, and then finding a way in which you can start in a low‐risk, small‐scale way. Examples of good starting projects include projects like a pilot, a low fidelity prototype, a forum series, a website, site visits or field trips, customer discovery interviews, or a business plan (or a business model canvas). Remember that you are experimenting: you may find that your first project doesn't go the way you're hoping. That doesn't mean it's not the right project.

Agile leaders understand that especially in a complex environment with an adaptive challenge, moving toward a big goal requires experimentation and small steps. To go fast, one has to start by going slowly. Getting to a clearly defined starting project is an exciting moment for a group: chances are no one has traveled the exact path that the team has outlined. By quickly and confidently outlining a project with a handful of guideposts, the team is inviting others to contribute. The anticipation created by a good initial project is infectious. As an agile leader moves the project into action, the excitement will only grow.