Chapter 10. Adaptive Leadership
One of the key questions that this book proposed to answer was “How can we adapt fast enough?” Fast enough today is different from what it was five years ago. Surviving and thriving while change accelerates requires a leadership culture built on responding to change over anything else. Whether you are responding to new opportunities or reacting to a competitor’s new product release, adapting fast enough must be one of your strategic goals.
When outcomes are uncertain, answers hard to devise, that’s the time to form a team, tap dreams, and improvise…. Putting lipstick on a bulldog won’t transform enough. Makeup can’t hide everything; change takes deeper stuff.1
1. Kanter, Rosabeth Moss. e-Volve!: Succeeding in the Digital Culture of Tomorrow.Boston: Harvard Business School Press, 2001.
Adaptive Leadership
Leadership material—books, articles, blogs—is full of platitudes. “Learn from your mistakes” is a classic one. Has any leadership book published in the last 20 years not voiced this platitude? So, as Kanter says, let’s attempt to go a little deeper. What are the things that make changing to an adaptive leadership culture so challenging?
“Agility is the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”2
2. Highsmith, Jim. Agile Software Development Ecosystems, Boston: Pearson Education,2002.
Let’s start this journey with an example. In the early years of the agile movement, and in some organizations today, managers had to overcome a significant change in the timing of their discomfort. In the traditional process of upfront planning and specification, managers became “comfortable” that the project would succeed. “Surely with all this front-end work and detailed documentation, the project will go as planned,” they said. However, as projects progressed, their comfort level often decreased as the team ran into problems. Near the project’s planned ending, usually as tests began failing, their discomfort increased dramatically.
Agile introduced more discomfort at the beginning of projects, rather than at the end, by accepting the looming uncertainty of plans that were not prescribed in detail. There is always some discomfort toward the end—EDGE doesn’t abandon Murphy’s Law. On waterfall projects, however, the discomfort at the end tended to be at a panic level. On agile projects, comfort tended to increase over the life of the projects as uncertainties were dealt with and completed features delivered. You would think that this latter scenario would be more attractive to managers and leaders—but in one case it was a big change that proved difficult to overcome. A mid-level manager in a 1000-employee software company (a company making a transition to agile) made the comment, “The managers who commit to a plan, even one they absolutely know is unachievable, are rewarded. Those managers who question the plans, and admit to the uncertainty of the plan, are castigated for not getting ‘with the program.’ Even when the plan-supporting managers are proved wrong in the end, they get better performance reviews. Agreeing to poor plans that upper management ‘wishes’ were achievable wins out over realism.”3
3. We have often referred to this as “wish-based planning.”
So, what is adaptive leadership? Several years ago Pat Reed and Jim Highsmith pioneered a class in adaptive leadership at the University of California at Berkeley. One diagram, filled with interlocking circles, had more than 30 topics to be covered in the class. Adaptive leadership—where do we start, where do we go, where do we finish? It’s not a surprise that the content of adaptive leadership is so elusive—just think of all the books written about leadership in general in the last 25 years.
Remember the challenge you face—transforming to a digital business as exploding technology opportunities are transforming our world. The concepts that transformed the software world were contained in the Agile Manifesto, and those ideas can form the basis for defining the essence of adaptive leadership—people and their interactions, delivering actual products and services (code), adjusting and learning, and customer focus. The Agile Manifesto uses somewhat different words, but these four values form the essence of agile.
True digital transformations involve a lot of change to fundamental ideas that organizations have operated on for a long time. Changing your fitness functions, embracing Tech@Core, moving from project to product thinking, and building autonomous teams are all in their own right big changes—much less trying to accomplish them together.
“Shortcomings in organizational culture are one of the main barriers to company success in the digital age. That is a central finding from McKinsey’s recent survey of global executives, which highlighted three digital-culture deficiencies: functional and departmental silos, a fear of taking risks, and difficulty forming and acting on a single view of the customer.”
Adaptive leaders must have the ability to articulate both core values and the competencies and practices that reflect those values. They must be bold in the changes they propose, and persistent in leading others through the morass that change entails. Put simply, you must lead. Lead in these four behavioral ways:
Encourage an adaptive mindset.
Lead change.
Be bold.
Inspire others.
Changing behavior takes courage, as in the courageous executive concept introduced in Chapter 1, The Big Picture. Without courageous leaders, no digital transformation will occur: There are just too many obstacles. Changing mindsets, leading change, being bold, inspiring others, and learning what works and what doesn’t—all require overcoming the status quo, learning, and moving ahead.
Encourage an Adaptive Mindset
An adaptive mindset is one of Envision–Explore, rather than the traditional Plan–Do.
The Agile Manifesto is very explicit in its use of the word “over” rather than “versus” in describing preferred courses of action. The word “over” indicates that one item is more important than the other, not that the second item is unimportant. There are times and situations in which a Plan–Do mindset would be appropriate, but Envision–Explore will still be the primary mindset of an adaptive leader.
Envision–Explore could also be called Hypothesis–Experiment, although the latter doesn’t roll off the tongue quite as smoothly. Envision speaks to possibility, externality with customers, value, outcome orientation, and blueprint orientation, whereas Explore speaks to openness to change, responsiveness, autonomy, and learning. Plan–Do brings to mind internal focus, output measures, reacting to threats, delegation, and detail task orientation.
“In a nutshell, senior executives must move the company—and themselves—away from outmoded command-and-control behaviors and structures that are ill-suited to today’s rapid digital world.”
The use of the term “bet” in the Lean Value Tree (LVT) reinforces the idea of experimentation. Given a particular goal (which itself might change), you place “bets” on how best to achieve that goal. Some bets work out and deliver value, some need to be dropped, and others require significant modification (a pivot).
The legacy of decades of a Plan–Do culture is difficult to overcome. We are drawn to certainty, not ambiguity. Admitting “I don’t know” has not been a path to managerial success, but more a path to ridicule. Adaptive leaders have to overcome this negative connotation associated with not knowing, by expressing it in another way: “I know our vision. I know we will experiment with how to get there and eventually succeed.” Adaptive leaders help teams build confidence in their process and ability to solve difficult problems.
Plans have historically included schedules and costs. Adaptive leaders don’t abandon these, but redefine them as constraints, not objectives. The constraints are real and affect how bets and initiatives are implemented. One reason short iterations are so critical to experimentation is that they force difficult decisions—early and often.
Envision–Explore defines an experimental process—one that iterates to a good solution. However, it can also oscillate back and forth without coming to a good solution. Without clear goals, exploration will be too open-ended and lead to endless investigations. The goals need to be broad enough so that explorations are useful, but narrow enough that they are achievable. Good measures of success help you bring the goals into greater focus and ensure that solutions deliver value. They also provide the team with the ability to determine if they are getting closer, or further away from the desired outcome. In other words, Measures of Success (MoS) are the compass for the EDGE steering mechanism.
Exploring is the process of delivering results—whether that is software, services, or other products. In the software business, the approach that epitomizes exploration is agile delivery. It focuses on speed, learning, and adjusting—just what experimentation requires. In today’s world of exponentially expanding opportunities, ambiguity, and uncertainty, a culture of experimentation—guided experimentation, to be sure—needs to permeate your enterprise. Chapter 2, Tech@Core, addressed the technical components of experimentation. But even the best exploration tools are useless without leadership support and encouragement.
In the LVT, the second-level items are called bets. Agile teams talk about hypotheses and then testing those hypotheses. Replacing the word “plan” with “bet” or “speculate” recognizes that prescriptive plans no longer work in our era of uncertainty and change. Thinking of bets and initiatives as experiments helps overcome the stigma of plans. The first step is revising your planning and execution strategy.
Lead Change
This book contains a number of concepts and practices critical to a digital transformation:
Customer value fitness function
Autonomous teams
Product thinking
Tech@Core
Portfolio management using LVTs and MoS
Collaborative decision making
All of these areas require change—change that needs to be led. The first order of business is to think about how each of these changes affect you. As a leader, some of these changes may come easier than others. While some may sound easy, they may be very difficult in practice. For example, changing your fitness function may sound easy; after all, who could be opposed to focusing on customer value? Nevertheless, making the change requires changing decades of buildup of practices, processes, personal beliefs, and performance measures.
One of the changes you as an adaptive leader need to support and guide is the transition to autonomous teams. Authors have been writing about teamwork and team dynamics for decades. The Wisdom of Teams by Jon Katzenbach and Douglas K. Smith,4 originally published in 1993, reignited interest in teams and how to make them effective. Agile proponents have championed a blend of high-performance, self-sufficient, empowered, autonomous teams since the inclusion of the value “people and interactions over process and tools” in the Agile Manifesto. Autonomy is one of the three principal motivators, according to Daniel Pink. But like the other changes required to become an adaptive leader, creating autonomous teams, figuring out their goals and boundaries, and helping them grow into high-performance teams are difficult. When teams are granted more power, leaders inevitably have less. It can be a difficult transition.
4. Katzenbach, Jon R., and Douglas K. Smith. The Wisdom of Teams: Creating the High-Performance Organization. Reprint edition. Boston: Harvard Business Review Press, 2015.
Manage Anxiety
One of the most difficult roles in leading change is that of empathetic listener. You are undertaking a digital transformation because of economic forces of change—external pressure. Making this transition requires multiple changes to processes, organization, and culture—internal pressure. Once again, leaders need to balance on the edge: They must acknowledge their own and their staff’s anxiety without multiplying it, but not be complacent and ignore it.
Nearly every aspect of adaptive leadership requires balancing. You need to express confidence in the future, yet not ignore the reality of the present. Teams need to think positively about their vision and desired outcomes, yet remain open to data that indicates the need to pivot the solution. As an adaptive leader, you must learn to balance anxiety and progress.
Overcoming the Culture of Fear
One of the biggest barriers to experimentation and learning is overcoming the culture of fear.
A recent Google study5 investigated what high-performing teams had in common. The most important trait? Psychological safety. That means team members share the belief that they won’t be punished when they make a mistake. Encouraging positive emotions during the creative process broadens this mindset. Barbara Fredrickson6 found that having such a mindset enables the brain to discover new knowledge and skills, thereby building new resources to tackle problems. Leaders who create a safe environment foster more open-minded, creative, and resilient team members. Incubating this mindset at scale creates a learning culture that can sense and respond to the changing environment.
5. Rozovsky, Julia. “The Five Keys to a Successful Google Team.” re:Work, November 17,2015. https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/.
6. Fredrickson, Barbara L. “Updated Thinking on Positivity Ratios.” American Psychologist 68, no. 9 (December 1, 2013).
“Courage is not the absence of fear, but rather the judgement that something else is more important than the fear.”7
7. Robinson, David. “Courage—Critical Success Factor for Innovation.” Blog post,October 4, 2014. http://www.false-summits.com/?cat=20.
Building your practice of experimentation includes overcoming a culture of fear that is often couched as fear of failure, but is actually much more. While we can talk about fear of failure, fear of power loss, or fear of job loss, at the core of these lies the fear of loss of respect. The fear of loss of respect—especially that of peers—derails many teams.
The technology arena is to a great extent a meritocracy, which can be both good and bad. Expertise is critical to executing on your bets and initiatives, but experts can cause conflict on self-sufficient teams because maintaining respect across different experts can be difficult. All too often, the undercurrent is illustrated by unspoken but understood thoughts: “If you don’t understand my area of expertise, then you don’t deserve respect.”
Meritocracy, creativity, diversity, and respect—the interplay of these four concepts drives experimentation success. First, you need expertise because of the complexity of the technology (for example, the software technology “stack” is exponentially more complex than it was just 10 years ago). Second, you need multiple forms of diversity—multiple technology experts, business and technical skills, and social diversity (gender, ethnicity, geographic, and more). The wider your diversity, the wider your potential creativity—unless that same diversity keeps the team from jelling. Often respect is limited to “my” group, often one that is narrowly defined by a particular skill. From a technical perspective, you might think of developers and business analysts: There may be respect within each of those groups but limited respect across them. Or, think about engineering and marketing: Often these specialties don’t respect each other’s expertise.
An experimentation mindset admits that we don’t have the right answer and that we have a difficult problem to solve, one that needs creativity and diversity. Two things help us overcome the fear that experimentation often breeds—respect and trust. Respect relates to expertise, and trust to execution. “I respect your abilities to help this team. I trust you to accomplish what you agreed to do.” Self-sufficient teams have the advantage of learning about others’ abilities, and that increases respect.
Note
Jim was once the VP of sales and marketing for a small startup company. “I was fairly new in the job and recall sitting in a conference room with a cadre of potential client technical managers and lawyers from a large West Coast company. Running through my mind was my CEO’s last comments to me that if I didn’t get this contract signed we wouldn’t make payroll next month. It gave me greater respect for sales people. Understanding this nail-biting part of the sales job was an eye opener.”
The Thin-Slice Change Strategy
The topic of change management is much too broad to cover thoroughly in this book. There are many approaches to change management, as outlined in a raft of books. We don’t want this book to turn into a change management book, so our recommendation to you is simple: Investigate different approaches, find one that appears to fit with your goals and culture, and use it!
Here, we will address just a small, but important piece of change management as it applies to digital transformation—namely, your coverage strategy. That is, how do you apply change that includes technology to your organization: all in, incremental (either top-down or bottom-up), or thin slice? In the early days of agile development, almost all implementations were bottom-up. A team or two was given the OK to try this “agile” stuff (or they sneaked it in without an OK). If they proved successful, other teams might try it, and over time a number of teams implemented this newfangled approach. Typically the use grew slowly, and mainly within software development teams (often without testing or product management involvement). Often these teams were labeled as “rogue” and given little organizational support. Expansion upward into project management or IT management ranks was usually slow, or nonexistent.
As agile became more widely used, a few organizations—typically software companies—tried top-down implementations in which senior executives decreed that all teams would use agile. The success of these decrees was variable, but often less successful than the bottom-up approaches. In the 1980s and 1990s, many, if not most, traditional waterfall methodology implementations were top-down. These implementations failed because they offered nothing to development teams except extra paperwork and bureaucracy.
Both top-down and bottom-up implementations could be incremental or all-in approaches—changing a team or two at a time versus trying to change everyone, from teams to management, at once. All the various combinations and permutations of these change strategies succeeded, but also often failed. At an agile conference several years ago, Jim was talking with a VP from a very large Chinese company. “How many agile projects did you do this year?” Jim inquired. “Six” was the response. “How many would you like to do next year?” was the next question. “About 200” was the response. “What do you think the probability of going top-down from 6 to 200 agile teams in a year is?” (You can make your own guess.)
In a top-down approach, organizational support and infrastructure may be easier to obtain, but actual use by delivery teams goes slowly. A bottom-up strategy generates the opposite result—more use at the team level but challenges getting management support and process and infrastructure changes.
If your goal is to transform an entire organization, the strategy we’ve found most successful is a “thin slice” implementation. The strategy is not to change an entire organization at one time, but to change all levels, from development team to senior management, for one to a few delivery initiatives. In the bottom-up era, many efforts were confined to developers. Particularly with bottom-up implementations, management tends to grant exceptions to policies, procedures, and other infrastructure items but doesn’t engage in actually changing them. In a thin-slice approach, teams have much broader functional participation—developers, technical specialists, testers, operations, and product and project management. In addition, managers and executives in both the IT and business hierarchy participate. By using this thin-slice approach, the organization learns from successes and challenges very quickly.
Being fractal is one of the characteristics of EDGE. Fractals are patterns that are repeated at multiple levels. For example, the LVT is fractal in that similar activities happen at each level—goal, bet, and initiative. The thin-slice practice is also fractal. It was first introduced in Chapter 6, Building a Product Mindset, as a way of breaking down products into smaller chunks of business functionality that “sliced” along lines of customer value and included all the technology components needed to implement the slice. Using a thin-slice strategy for organizational development is similar in that the slice includes all levels of an organization that support a delivery team.
At an organizational level, this thin-slice approach is similar to the agile approach to software development—planning and executing business “stories” rather than developing by technical layers. The technical layer approach had one group doing the user interface, another doing the business logic, another doing database development, and yet another handling testing. Customer value was often the last thing these groups thought about: They just built their individual components. As you might guess, integrating these pieces was often a nightmare. The story approach focuses on an increment of business functionality—delivering something useful and understandable—to the customer.
In Secrets of Consulting, author Jerry Weinberg states, “Never promise more than 10% improvement.”8 Change is always more difficult than you planned for. The optimal approach to change involves all levels of management and delivery teams at the same time—but limited in the breadth of impact. Having a few teams (one to three) at the delivery level (including product managers/owners, developers, testers, operations staff, and other necessary personnel) learning a new approach (agile) while management is addressing infrastructure items for these teams (policies, accounting practices, governance, performance measurements, and staffing) enables the organization to learn what works and what doesn’t at multiple levels—quickly. The next product (or project) builds on that learning when undertaking the next slice. As slices accumulate, more and more of the organization—at all levels—participates.
8. Weinberg, Gerald M. The Secrets of Consulting. New York: Dorset House Publishing,1985.
With any significant change, organizational “antibodies” will likely appear. Like biological antibodies, they are resistant to change and try to move back toward the status quo. This is a particular issue with bottom-up change, as middle managers often take on the antibody mantle. Because the focus of change is on delivery teams, few managers are engaged for a long time period, giving them time to hone their anti-change rationale. Antibodies are illustrative of the problems of scaling change whether you use a thin-slice strategy or another approach. But resistance can also be a source of learning.
What Not to Change
Much of this chapter, and the book as a whole, is about change, about adapting. However, the world of opportunities and your potential response to those opportunities, is infinite. As an adaptive leader, you need to understand when to change and when not to. You can build an understanding of when not to change by thinking separately about core values that don’t change and operating practices and specific goals and strategies that do.
For software development, the Agile Manifesto’s four value statements have guided practitioners for nearly 20 years (as of the release of this book). While some have proposed additions or modifications to the value statements, they have remained core to the success of the agile movement. There are very few aspects of software engineering, or general management for that matter, that are still at the forefront of those disciples after 20 years. It speaks to the resilience of the agile movement that its core values have stood the test of time. But there have also been changes. As agile practices have approached mainstream status, organizations have molded practices and processes to their own unique situations, and strategies for expanding agile into wider organizations uses have all been accomplished—guided by four short, concise value statements.
Your next level of what not to change is the LVT. While many view the LVT as a guide to what to do, a well-articulated LVT can also help us determine what not to do. “Does this help us meet goal 1?” would be a useful type of question to keep in mind. The universe of things you could do is vast compared to the number of things you should do. So part of succeeding at adapting fast enough is being good at knowing when to change and when not to.
Be Bold
A digital transformation requires leaders with a well-articulated purpose that inspires those around them. It is driven by an experimental process and a technology platform geared toward experimentation, but in the end people and culture dictate success. This transformation doesn’t happen unless you have executives and leaders who have the courage to be bold and champion bold investments.
Earlier in this book, we introduced the biological concept of fitness function. In biological evolution, mutations provide the mechanism for adaptation: Good mutations further the organism’s fitness goals, whereas bad mutations die out. The mutation mechanism has both an upside and a downside. The upside is that organisms can adapt to changes in the ecosystem. The downside is that they take time, sometimes tens of thousands of years. When the environment changes quickly—think of the meteor impact that cooled the earth rapidly about 65 million years ago and led to the demise of dinosaurs—your ability to adapt can be severely challenged. Of course, the extinction of the dinosaurs also aided the evolution of mammals.
Businesses don’t have thousands of years to adapt, and often not even tens of years. However, businesses do need a mechanism similar to mutations that can act as a catalyst for adaptation to environmental changes. The business mechanism is guided experimentation. Random experimentation might work—eventually—but you don’t have “eventually”: You need to adapt now.
The first guide to your experimentation is your LVT. It provides goals and boundaries. Bold experimentation doesn’t end with the product: Your guided experiments could cover organizational structure, business model, a technology platform, and culture. The outcomes, measured by your choice of MoS, also help bound experimentation.
During the first week of the 2018 Winter Olympics was the qualification round for men’s snowboard half-pipe. Scores kept escalating—91, 93, 95. This was an unprecedented number of scores in the 90s. American two-time gold medal winner Shaun White went last. Since it was just a qualifying round, he only had to score in the top 12 to move on. But he chose to go big, to go bold—and put up the highest score of the day, 98.5. In the finals, on the last run as the last shredder down the pipe, White faced a daunting score of 95 from the previous competitor. Once again, his boldness and competitive spirit won the day: He scored 97.75. Boldness, striving to be the best, will sustain teams and individuals through the difficulties of transformation. Boldness and courage are needed for sustained innovation—and, of course, a team with the right capabilities.
Leading a digital transformation can be a daunting task, in large measure because it affects financial and power relationships in an organization. When you read about or have a consultant tell you about a process such as EDGE, it appears that there is a direct cause and effect. Build an LVT, define MoS, prioritize initiatives, and then you get results. The piece that is often missed is that success and failure are more about judgment and experience than about process. Remember again the agile value of “people and interactions over process and tools.” The culture of individuals and their collaboration are key to success.
Of course, you should also think about what the future brought to the digital camera business. In a short period of time, the low- and mid-range digital camera business was severely impacted by cameras in smartphones. This required a serious pivot in a new business that was just getting started.
Riding Paradox
What is an adaptive leader or manager? There are countless answers to this question revolving around the desirable characteristics, mindset, or behaviors—for example, collaborative, light touch, servant, and failure tolerant. One of the critical traits is that of “and” rather than “or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Consider, for example, the paradox of needing predictable delivery while also needing to be flexible and adapt over the life of a project. Agile teams face difficult choices because managers haven’t addressed this paradox. They often continue to admonish teams to do both, without really giving them direction about how. Alternatively, they may give lip service to adaptability and focus on delivering to plan—scope, schedule, and cost—just like in the waterfall development days. Or worse, they may focus on velocity and forget quality.
Agile teams succeed, in part, because they embrace seeing reality, the reality that “stuff” happens during a project and that the path to success involves adaptation. Ambiguity, risk, and uncertainty are an integral part of innovative projects today. As such, they offer leaders paradoxical situations—situations that require backing away from the direct paradox and figuring out inclusive solutions. Adaptive leaders need to become “riders of paradox.”10
10. This section is excerpted from Highsmith, Jim. Adaptive Leadership: Accelerating Enterprise Agility. Boston: Addison-Wesley, 2013.
Agile leaders need the courage to view issues from different perspectives, to gather data without undue prejudice, to formulate both/and rather than either/or resolutions. Too few organizations make it past what we have labeled “prescriptive agility,” which should be an oxymoron, but unfortunately isn’t. These organizations are as rigid about their agile implementations as they were previously about their heavy methodologies! They fail to move beyond rules to understanding. Adaptive leaders need to be riders of paradox, always thinking, “how can I do this AND that” at the same time.
“Learn the law very well, so you will know how to disobey it properly.”
We will illustrate with two other examples from software development, issues that have been written about as either/or cases: waterfall versus agile, and BUFD (big upfront design) versus NUFD (no upfront design). In each case, proponents on either side have set the other up as an enemy to be defeated, rather than considering what is useful in each approach. The bottom line is that all models are flawed, but all are also potentially useful. The true adaptive leader—whether an iteration manager, a project manager, a technical lead, a development vice president, or a CIO—attempts to “include” the best from different models. It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over again, until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.
We live in a culture of absolutes—think of the current rhetoric of our political parties—but most people recognize that reality imposes a lot of gray. If we think human (or business) affairs are rational, then we attack everything as a problem to be solved by highlighting the issue, gathering facts, looking for root causes, formulating solutions, and implementing the solution. Once we’re done, it’s “problem solved” and on to the next problem.
But what astute managers have learned is that most serious issues are not problems, but rather paradoxes that arise again and again. Paradoxes aren’t solved once and for all; they require balancing actions again and again. There is even difficulty finding a word for the outcome of a paradox. A “problem” has a solution, but what is the outcome of a paradox—a “temporary solution”? The best word seems to be “resolution,” which has a dynamic aspect to it that “solution” doesn’t. So, problems have solutions whereas paradoxes have resolutions.
Take, for example, the issue of short-term versus long-term focus. There isn’t a single answer to this issue; a balancing needs to occur from one time frame to another. When a company is in serious financial trouble, working on a five-year strategic plan probably isn’t a good use of management time.
The ability to differentiate between problems and paradoxes, along with the ability to balance paradoxical resolutions time after time, are among the defining characteristics of an adaptive leader. These abilities don’t come easily because discernment and judgment are involved. Paradoxes that leaders face include the following:
Accountability versus autonomy
Hierarchical control versus self-organization
Predictability versus adaptability
Efficiency versus responsiveness
None of these is a problem, and none has an easy solution. Any resolution must contain elements of both—delicate balancing acts that change over time. Take the issue of predictability versus adaptability. The traditional mandate that “We must be within 5 percent (or whatever number) of our schedule or cost plan” just doesn’t drive people in the right direction if we want them to learn and adapt over time. Conversely, not giving any predictions doesn’t work either. Acknowledging a paradox means giving up the notion that you are in control and can dictate (plan) the future. At the same time, you cannot take a totally cavalier “let’s wait and see what happens” approach. Living with paradoxes means planning, but not becoming wedded to the plan. It means sensing when actual events override the plan and responding with the appropriate “resolution.” Learning to do this well is a keystone of adaptive leadership.
Inspire Others
Adaptive leadership is about leading. It’s about defining and embracing an ambitious vision. It’s about having the courage to push through negativism. It’s about having the grit to persist in the hard work required to change. It’s about persistence—the willingness to adjust and move forward, but not giving up on the vision.
Motivation has gotten a bad rap in recent years as academics and consultants have moved on to “modern” concepts. While motivation means the willingness or desire to do something, it has often been considered manipulative. But studies indicate that large percentages of employees are not engaged in their work. They work, but are not inspired to fully engage.11
11. Kruse, Kevin. “Why Employee Engagement? (These 28 Research Studies Prove the Benefits),” Forbes, 2012. https://www.forbes.com/sites/kevinkruse/2012/09/04/why-employee-engagement/#4fdcfb303aab.
Transformations are hard and scary; so is innovation. Both of these create emotional roller coasters for staff and leaders. Leaders must articulate the vision, in multiple different ways, to encourage engagement.
While inspiration, courage, persistence, and engagement are important traits, they sometimes sound academic. That is why we are drawn to the concept of “grit.” The first time Linda tried a new recipe using Australia’s venerable Vegemite, her dog wouldn’t even touch it. He didn’t fancy the next six versions, either. Rather than turn in her chef apron, Linda researched tried-and-tested flavor pairings, which inspired her to make Vegemite lamb shanks. Delicious!
“Gritty teams collectively have the same traits that gritty individuals do: a desire to work hard, learn, and improve; resilience in the face of setbacks; and a strong sense of priorities and purpose.”12
12. Lee, Thomas H., and Angela L. Duckworth. “Organizational Grit.” Harvard Business Review, September–October 2018.
Organizational grit is the perseverance to continuously learn from set backs so that it becomes “just the way we do things around here.” It’s about a commitment to solving a problem incorporating feedback, experimentation, and learnings from failures. Customers didn’t like the first prototype? Product pitch didn’t make it past the funding round with stakeholders? That’s not the end of the world in a company with strong organizational grit. Employees take the learnings and find better ways to solve the same problem. In such organizations, teams are rewarded for learning, not punished for failing.
Grit refers to strength of character and the resolve to get something done—no matter what. The most famous story of grit comes from the 1969 movie True Grit, for which actor John Wayne won his only Academy Award. Wayne’s character Rooster Cogburn persisted in the face of multiple setbacks and his own limitations (he is a falling-down drunk at the beginning of the movie) to eventually get the bad guys.
Final Thoughts
In many ways, management is about the present whereas leadership is about the future—a future of adapting to change. Adapting is about uncertainty, anxiety, experimenting, judgment, fear, innovation, collaboration, and decision making. It is about envisioning and exploring, rather than planning and doing. It is about bold, gritty leadership and inspiring others to engage in the future.
Adaptive leadership is a critical component of the EDGE operating model. Take a new style of leadership away from your transformation and it’s unlikely to end well. However, the same can be said for other components, such as Tech@Core or building an LVT. While every organization needs to adapt the components of EDGE to its own situation, don’t forget that you have to understand how the components are integrated to form a whole. Don’t leave out a key piece.