4. Learning to Let Go
It’s easy to think of an organization as a kind of machine for producing particular results, one whose roles, responsibilities, and processes define a kind of “work engine” that produces desired outputs. The reality is that organizations are complex social networks that reward people for getting things done. Compensation is one form of reward, but rarely the most important. Instead, the most important rewards usually relate to status: recognition, reputation, and influence. Introducing an agile way of working into an organization can change all three of these, often for the worse for the people who benefited from the old system. This is not a particularly new problem, nor was it new when Machiavelli observed:
[T]here is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. This coolness arises partly from fear of the opponents, who have the laws on their side, and partly from the incredulity of men, who do not readily believe in new things until they have had a long experience of them.1
1. Niccolò Machiavelli, The Prince.
This chapter explores how the agile leader helps the organization take its first steps toward empowering teams by letting go of old ways of working and the reward structures that enabled them, and by starting to build the reward structures that reinforce the new way of working.
Empowerment Doesn’t Come for Free
Agility isn’t really about delivering faster and more efficiently. That happens as a by-product of improving ways of working to eliminate waste in both the process and the product, but the primary goal is to deliver better outcomes by obtaining frequent feedback, inspecting the results, and adapting based on that feedback. By starting to test assumptions early in the process, the team members will shorten their time to learn.2
2. See this blog from Henrik Kniberg for more information on this topic: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp.
The scenario described in the case study is quite common: Everyone loves agility until it starts to undermine their own perceived authority. This is especially true for executives who have been used to “calling the shots.” They typically don’t express their concerns as a loss of control, but rather focus on concerns about quality and consistency, whether in processes or messaging.
Everyone loves agility until it starts to undermine their own perceived authority.
Empowered teams are deeply threatening to traditional organizational hierarchies. When the traditional organization is threatened, it tries to constrain the change, limiting it to minor improvements in delivery processes. While the organization still realizes some benefits, it fails to achieve the motivational advantages that empowered teams provide, and it fails to significantly improve its ability to quickly respond to change because decisions take too long to navigate the siloed hierarchy.
To counter these drags on agility, senior leaders must do two things: They must support and protect the nascent agile teams from being dragged back into old ways of working, and they must change the power dynamic in the organization so that people, and especially other leaders, in the traditional organization improve their own perceived status by transferring some kinds of power to the agile teams. Chapter 1 introduced the term “agile cell” as a protection mechanism for nascent agile teams that creates a space where these new power dynamics can be installed with less resistance and more support and focus from leadership.
There is an art to doing this, but its essence is to elevate the importance of supportive, nurturing, and coaching behaviors both by example and by changing the organization’s implicit—and sometimes even explicit—reward system. This change has to come from the very top, and it has to be consistent. Inconsistent support for empowered teams will tell everyone that the shift toward an agile organization is simply a facade, and a lack of support from the very top will tell everyone that the shift is not really strategic. All too many agile transformations fail because they have support only from middle managers, and not from senior executives.
A related part of this art is that agile leaders cannot devalue the contribution that every person in the organization makes, especially the people in the traditional organization. In the early stages of an agile transformation, most of the organization will not be working in an agile way. If a schism develops between the agile and traditional teams over their perceived importance to the organization, the traditional organization will find subtle ways to kill the agile initiative.
A solution to this problem is to show how everyone contributes to the goals of the organization, but in different ways. Not all parts of the organization actually need to be agile; in fact, there are many parts of an organization in which stability and incremental change are not only important, but essential. Agility is essential where large customer satisfaction gaps exist or where customer needs are changing rapidly. In contrast, where satisfaction gaps are small and needs are stable, stable processes often best meet customer needs.
This is not to say that even teams supporting very stable parts of the business cannot benefit from being empowered to improve their own way of working. Modern agile practices owe their success to the work of Deming and others, and to models like the Toyota Production System, which were focused on improving complicated but not constantly changing manufacturing processes. The point being made here is simply that different teams will take different paths toward their organization’s goals, and that agile leaders need to create space for everyone to contribute.
Agile Leaders Help Teams to Grow Their Ability to Reach Audacious Goals
Most organizations focus on the visible domain. In fact, in the leadership training classes the authors conduct, nearly 80% of the participants indicate that they mostly focus on the visible domain. This same pattern plays out when one considers the stalled rate of agile adoption in recent years, and the reasons behind it (see Figure 4.2).
Figure 4.2 Agile adoption lags while common leadership problems remain unresolved.3 (Source: VersionOne/digital.ai Annual State of Agile Report since 2014. Graph courtesy of Microsoft.)
3. For more information on the State of Agile Survey, see https://stateofagile.com.
Organizations focus on the visible domain (processes, tools, structure, communication, key performance indicators) in the hope that doing so will lead to clarity and explicit outcomes. While these things are certainly important, excessive focus on the visible leads to employee disengagement.
Focusing on the invisible domain (alignment on values, turning values into a mission, coaching people in their personal development, and practicing by actively listening to people’s problems and fears) helps to improve engagement and creates strong connections between people. However, only focusing on the invisible domain can lead to poor results, insufficient impact, and little customer value creation.
Balancing leadership’s focus between both domains helps people feel engaged, helps them to continuously grow, and helps them to deliver better results for the organization and their customers.
Achieving Balance Between the Visible and Invisible
Ensuring adequate focus on the visible domain requires attention to two aspects of communication (see Figure 4.3):
Figure 4.3 Teams grow when leaders help them to focus on specific aspects.
Explicitness, which means establishing clear and measurable goals, and ensuring that everyone understands the goals well enough to start thinking about how they can contribute to achieving the goals.
Presence, or one’s ability to consciously choose a communication style and behavior that considers another person’s needs in the invisible domain. Presence also means the ability to address and eliminate unwanted manifestations in the visible domain.
Measuring the invisible domain can be more challenging, but focuses on two related aspects:
Ownership, or the degree to which a team is personally committed to reaching a goal. People who feel “ownership” experience intrinsic rewards whenever they make progress, however small, toward achieving a goal. As teams demonstrate greater ownership, they “earn” greater trust and often greater independence in self-managing. Granting greater freedom to these teams also sends a clear message about desired behaviors to teams that are exhibiting less ownership.
Awareness, or the degree to which individuals are aware of their own motivations and the motivations of others in the invisible domain. Being aware of a person’s driver in the invisible domain helps you to better cope with its manifestation in the visible domain. Explicit invisible drivers also help a team to discover their purpose and to recognize unwanted conflicting drivers. High levels of awareness tend to contribute to a person’s appreciation of diverse perspectives because it helps teams to increase their creativity in solving complex issues. High levels of awareness also tend to increase a person’s sense of psychological safety.
These aspects correspond with the factors that Google found in its research on team effectiveness:
In the visible domain, teams create impact, structure, and clarity.
In the invisible domain, teams have psychological safety, dependability, and meaning.
Letting Go in Small Steps
For teams to grow, leaders must give them the space to grow. For teams to become empowered, leaders must let go of their own power and give it to teams. By doing so, leaders gain a different kind of power that comes from seeing the effectiveness of their organization, and their own influence, multiplied. But at the point where they make the decision to give away power, leaders make a leap of faith.
It’s fairly easy to see where a leader falls on the trust–empowerment scale. You just have to look at what they manage (see Figure 4.4):
Figure 4.4 Stages of leadership focus.4
4. For more information about empowered teams and agile maturity, see https://agileleadershipschool.nl/agile-maturity-model/.
Activities. Leaders who manage teams to perform a set of activities have very little trust in those teams, as in the case of traditional managers who use detailed project plans to track, manage, and monitor teams. Managing activities leaves very few choices to the team; their only freedom is in the small tasks that constitute the managed activity.
Outputs. Leaders who manage teams to produce a set of outputs provide teams with the freedom to choose what they do, so long as they produce some set of outputs. Examples of outputs include product features, project contract deliverables, and various information reports. The teams experience a little more freedom than if they were managed to a set of activities, but they are still little more than “order-takers.”
Outcomes, specifically customer outcomes. Leaders who manage teams to produce a set of outcomes give those teams the freedom to not only choose what they do and how they work, but also what they produce to achieve the desired customer outcomes. Doing this demonstrates a very high level of trust between the leader and the team.
Societal impacts. Leaders who focus on societal impacts are rare, and are most frequently seen in organizations focused on social causes or broader health and well-being initiatives, potentially spanning organizations. Leaders focused on societal impacts may have very little direct control over the work of their associated organizations, but can have tremendous influence on the success of their initiatives.
Empowerment Strategies
In the preceding scenario, Carl feels very little trust toward the teams; he assumes that they don’t know what they are doing unless they have a plan that tells them what to do, and his preferred management approach is to monitor the activities of the team to ensure they are performing to their plan. This demonstrates a low level of trust and reflects a desire on his part to micromanage the teams.
Of course, leaders should not blindly trust teams to perform at high levels; teams need to prove that they are worthy of trust, and of the power to work independently that comes with that trust. Leaders and teams must negotiate an agreement about the appropriate level of trust and delegated power based on the team’s demonstrated capabilities. This negotiation usually results in one of the following delegation strategies, listed from lowest to highest level of trust:
Seven Levels of Delegation5
5. Adapted from Management 3.0’s delegation levels. For more information, see https://management30.com/empower-teams/delegation-empowerment/.
Tell: Leaders tell the team what to do.
Sell: Leaders let the team try to convince them what to decide.
Consult: Leaders consult the team’s opinion and decide.
Agree: Leaders and the team jointly decide.
Advise: Leaders share their opinion but the team decides.
Inquire: Leaders let the team decide and are informed after the fact.
Delegate: Teams decide with full independence.
Depending on the demonstrated capabilities of the team and the type of decision that needs to be made, any of these strategies may be appropriate, and the degree of freedom allowed to a team usually depends on the potential impact of a decision. For example, any team will likely have complete freedom to decide minor things like where to eat lunch, but only a few teams will have the freedom to set the overall product strategy.
Leaders have to decide which level of delegation is appropriate based on the maturity of the team and the potential consequences of the decision. Having a transparent conversation with a team about the level of independence for which they are ready can help the team to develop their decision-making capabilities. Leaders helping teams to develop greater autonomy can let the team make a minor decision, monitor the results, and then help them improve based on those results. As the team demonstrates sound judgment on small decisions, the leader can gradually expand their autonomy in making more impactful decisions.
Leaders have to decide which level of delegation is appropriate based on the maturity of the team.
Slow Decision-Making Kills TeamSelf-Management
It’s not just who makes the decisions that matters, but how quickly those people make decisions. Waiting for people, resources, or decisions always creates waste; when a team has to wait, they will work on other things, but those other things may not be valuable. They may simply create waste that can sometimes take additional work to remove or correct. Waiting, in an agile system, is always bad. As evidence of this, the Standish Group’s Jim Johnson reports in the 2018 Chaos Report that waiting for decisions—which the report calls “decision latency”—is a significant root cause of software project failures.6
6. For more information on the causes and effects of decision latency, see www.standishgroup.com/sample_research_files/BBB2017-Final-2.pdf.
An experience from the authors’ own consulting work provides useful context. A product development team working for a telecommunications company was looking to improve the speed at which they were able to deliver new capabilities to their customers. They had a sense that implementing automated software build and test capabilities would speed their delivery.
As we worked with them to create a value stream map of their delivery process, we found a different problem: decision latency. The team was spending almost 70% of their cycle time7 waiting for some other part of the organization to make a decision. Even automating 100% of their build test process would have saved them less than 10% of their cycle time.
7. Customer cycle time is defined as “The amount of time from when work starts on a release until the point where it is actually released. This measure helps reflect an organization’s ability to reach its customer” (www.scrum.org/resources/evidence-based-management-guide).
This is not to say that automating build and test processes is not a valuable thing; it can be quite valuable, especially when it eliminates rework caused by human error. But it wasn’t the largest source of this team’s cycle time, and the same is true for most organizations. Communication delays, interruptions, multitasking, and decision latency are typically far greater sources of waste in most organizations.
When You Discover That You’re the Bottleneck, Get Out of the Way
The decision to let go of decision-making authority and transfer it to someone else, or to a team, can be frightening at first. In organizations in which decision-making power denotes status, giving up that power can seem like a resignation. At the point at which the leader confers power to others, there appears to be no guarantee that the leader will see any personal benefit from that action. Such a decision to give up power represents a leap of faith that it is the right thing to do, and that good things will come of it.
In reality, this decision represents an inflection point in the career of the agile leader: It signals that the leader is leaving behind reliance on formal authority and shifting toward indirect influence. Of the two, indirect influence represents a more powerful form of leadership because its span of influence extends far beyond the boundaries of formal authority. Developing the ability to influence others through example and inspiration allows leaders to tap into powerful motivating forces that order-givers will never experience. Teams that perform at the highest levels do so not because someone orders them to do so, but because in doing so they earn the respect and admiration of people whom they admire.
But for the leader just learning how to do this, it’s a scary first step on a journey that may feel awkward for quite some time. The lack of a well-defined path with certain rules and prescribed outcomes is daunting, and when both the team and the nascent leader are new to having a dialogue about decision making, both are likely to make missteps at first. At these times, it is natural to want to retreat to old ways of working, but the better solution is to learn from the misstep and adapt, both for the leader and the team. By taking smaller steps, specific to the type of decision, and using the appropriate delegation level, it will become easier to let go. Doing so helps both the leader and the team to grow in their new relationship.
The reality is that traditional managers think they know more about how things should be done than they really do. When they start to trust their teams, they find that the teams, who are closer to both the customer and the work, are better able to decide how to work. When managers let go of feeling that they should have all the answers and embrace guiding their teams to find better answers, they find their influence and effectiveness are amplified, and they also free themselves to focus on seeking better goals rather than being stuck in merely seeking better means to reach goals.
Decision Latency Can Be Caused by Cross-Team Dependencies
Slow decisions can also result from one team waiting on another to do something, or waiting for an external expert with skills the team needs but does not have. Waiting for another team is sometimes caused by siloed skills, in which all the people with one set of skills that many teams need are located in one team, such as a database administration team or a security team.
Various solutions can help solve this problem:
Improve the cross-functionality of teams so that they have the skills they need.
Automate solutions so that teams can self-service.
Break up the siloed team and assign them out to teams.
Keep the siloed team structure but increase the number of people with the scarce skill so that no team ever need wait for help.
Use a more hybrid approach of restructuring, with an emphasis on optimizing team interactions for flow.8
8. For more information, see the concept of travelers in the book Team Topologies by Matthew Skelton and Manuel Pais: https://teamtopologies.com/.
Organizations typically choose to use all these approaches in combination to reduce the decision/resource latency problem.
Decision latency can also be caused by a siloed product architecture in which each team owns a set of components. Teams developing new products or services that use these components often need to make changes to many different components. If the organization and the product architecture are siloed, that team will have to wait on many other teams to get their work done.
The solution to this problem is to eliminate the silos and let any team change any component, so long as they don’t break the component for other teams. This last point is essential. Breaking the component for others can be detected and prevented by using automated testing, so that any deviation from agreed-upon behavior or performance (or security, reliability, usability, etc.) are detected anytime a team attempts to change a component. If any test fails, the change is rejected and prevented from affecting other teams. In fact, this approach is much more reliable than assigning the component to a team and expecting them to catch any damaging changes.
Teams Can Also Cause Their Own Decision Latency
Even agile teams can fail to make timely decisions, such as when they continually postpone dealing with technical debt, or when they continually ignore problems identified in team retrospectives. Teams may fail to raise an issue with a stakeholder because they are afraid of being viewed as “troublesome.” Or they may continue to develop new features without understanding whether what they have delivered to customers so far is valuable.
Agile teams can also experience group indecision. A team may feel that they need to reach consensus on everything and that anything other than unanimous agreement means they can’t make a decision. While consensus is a wonderful thing, not everyone on a team is going to see things the same way all the time. Teams need to form working agreements that allow for moving ahead even when some team members disagree. This usually means they have to establish measures to test the decision (for example, by doing an experiment), and an agreement that these measures will guide any adjustments to the course of action.
Leaders can also help teams make better and faster decisions. They need to watch for signs of decision procrastination and help the team to move the decision ahead—not by taking over the decision, but rather by coaching the team to make better decisions on their own. This can be challenging for a leader who is used to making the decisions and to whom the decision seems clear, but if the leader undercuts the team’s decision making, the team will never develop the ability to make their own decisions.
Reflections on the Journey
Not everyone is going to like agility. More importantly, self-managing teams pose a threat to the parts of the existing hierarchy that benefit from that hierarchy because they will, eventually, reduce the scope and importance of the traditional parts of the organization. The people who benefit from the existing system are not naïve, and they are not going to accept a reduction of their scope and status without a fight.
Agile leaders play an important role in protecting self-managing agile teams from the potential harm that the existing organization might cause to them. Agile leaders need to both nurture those self-managing teams and gradually increase their empowerment by shifting responsibilities to the teams as they are ready to take them on, all while keeping the existing organization from preventing the self-managing teams from being starved of the skills and resources they need to grow.
Among the biggest change for both teams and leaders is accepting that not all experiments the teams run in pursuit of their goals will produce positive results. Traditional organizations that punish any shortfalls in results from expectations will kill agility. Protecting agile teams from this toxic culture is essential for creating an environment in which teams can try new things and learn from their experiments.