SIX

Create Stability

Blair notices that, even with programs that have typical contracting needs, a few issues keep cropping up at predictable times. Several large programs always seem to need a lot of contracting work at the beginning of the fiscal year, which requires a lot of overtime from her team. Even though these programs’ needs are fairly predictable, the team always seems to have a backlog of work. Another problem that Blair observes is that each team member takes a slightly different approach, which slows down the process when they work together on a contract.

She realizes that the team could benefit from having more consistent processes and codifying them in a way that they can easily understand. She just needs to figure out which processes deserve her attention right now.¹

Although you can’t always control or predict what’s going to happen, your team can benefit from stability, as long as you are creating that stability in the right place. Agile organizations enable the right response at the right time by balancing stability and flexibility. Too much of one or not enough of the other can make the organization less effective. In many cases, too much stability—when it comes in the form of red tape and unnecessary steps—leads to slow responses. Stability can be helpful, however, when it provides the clarity and consistency that supports quick, defensible decisions. Similarly, too much flexibility can result in confusion and inconsistent responses, while the right amount of flexibility lets the organization respond in the right way at the right time. In this chapter, we will explore the stable part of the organization.

MAINTAIN A STABLE ORGANIZATIONAL STRUCTURE

When changes happen quickly, undertaking a major restructuring is unlikely to result in the necessary adjustments, especially if restructuring is the only response. And, in fact, when immediate action is required, a major restructuring is the wrong approach because restructuring cannot be completed quickly. Yet we see many organizations whose sole response to a changing set of events is to restructure themselves. When the pace of change speeds up, traditional organizations often rely on wholesale restructuring, but agile organizations can maintain a quick-response capability by keeping the organizational structure stable, which enables employees to focus on the response. Agile organizations know that revamping the entire organizational structure every time something changes is a losing battle.

Not only are organization-wide restructurings costly, time-consuming, and distracting, but they often do not produce the expected improvements. Instead, they typically pull employees’ attention away from changes that are occurring around them, making it likely that they miss important signals. Given how quickly situations can change, the environment may shift many times during the time it takes to restructure! By avoiding unnecessary restructurings, agile organizations help employees sustain their focus on work that is not directly affected by the changes going on around them. This boundary helps everyone ensure timeliness and efficiency.

Although agile organizations reorganize from time to time when major, long-lasting shifts occur, they do not use restructuring as a primary lever for responding to short-term fluctuations. They know that restructuring should be undertaken in only two situations: when you’re certain that the change you’re responding to is unlikely to change again in the foreseeable future and when a revised structure will support better and faster responses. For example, if your customers change the way they operate, you may benefit by restructuring the parts of the organization that are affected so that employees can better support their customers. Or, if you need to create a new service offering, that may require setting up a dedicated staff and resources as well as a new business unit.

Restructuring doesn’t need to be a whole-scale endeavor. It can be as simple as creating new units, combining existing units, separating existing units into smaller components, or removing units that are no longer needed (and reallocating people accordingly). Even if you think that more small-scale restructuring is necessary, however, you may need to garner support for it from other leaders, depending on your leadership role; for example, a first-line supervisor who sees benefits to integrating her team with a peer team would need to start the process by discussing the idea with her manager and the peer team’s leader.

You might also consider experimenting to see if your restructuring ideas will produce the results you want: find a way to test a new business model or organizational design, for example. You would likely learn something, which would, in turn, enable you to refine the idea before putting it in place. Let’s say you want to combine two units to allow faster responses to changing customer needs and better coordination among employees who support customers. Before making the change, you could ask a few employees from each unit to begin working together. That would give them the chance to document the new process, identify any duplicated efforts, and discover whether any part of the process falls through the cracks. The new processes could then be better defined, leading to a smoother transition.

Although many different organizational structures exist, agile organizations often rely on combinations of structures as a way for each part of the organization to align with its environment. Common organizational structures are functional, divisional, and matrix. A functional structure groups people who do similar work, such as work in finance, information technology, acquisition, operations, or human resources. A divisional structure groups people according to products or services, type of customers supported, or geographies; each unit contains all of the necessary functions (e.g., information technology or acquisition) to support a service or geography. A matrix structure combines elements of functional and divisional structures, grouping people into teams that report to both a functional boss and a divisional boss.

While we don’t want to get into a full discussion of the advantages and disadvantages of functional versus divisional versus matrix structures, we do want to emphasize that agile organizations enable both stability and flexibility—which means that, rather than choosing a single type of organizational structure for the entire organization, agile organizations maximize the benefits of each type of structure, using each type where it is needed the most.

Because a functional structure allows processes to be defined, it works well when changes are predictable, understood, and identifiable in advance. The result is often operational efficiency and high levels of productivity. A functional structure also provides a so-called home base that allows employees to develop specific expertise. The stability of a functional home base promotes the career growth of employees who reside in that functional group and allows more experienced employees to mentor and coach those who are less experienced.

A functional structure, however, can be less responsive when unforeseen changes happen, as coordination across the functional units can be time-consuming. Rather than changing the entire organizational structure, then, agile organizations often retain their functional components for predictable changes while incorporating cross-functional teams to accommodate unforeseeable changes. Cross-functional teams bring people together from different functions, allowing them to collaborate more easily to meet customer needs, especially in the face of random events. Cross-functional teams can be formed around specific customers, projects, or programs.

A good example of how cross-functional teams work can be found in hospitals. A hospital system’s stable organizational structure helps it respond quickly and effectively when needed. During a medical crisis—such as a pandemic or a mass-casualty event—a hospital doesn’t respond by attempting to restructure the entire organization and reallocate employees and resources to the emergency room or intensive care unit. Instead, hospital leaders rely on the organization’s structure to determine doctors, nurses, and technicians who can be temporarily reassigned to address the immediate situation.

To be successful, cross-functional teams should have (1) clear goals that align with the organization’s strategic goals, (2) members with the right expertise and skills, (3) a leader who approaches leadership with a coaching style, and (4) access to the necessary resources, such as budget and tools. Cross-functional teams also help employees develop specialized knowledge around a customer, project, or program and to broaden their skills across functions.

Cross-functional teams go by many other names, including committees, task forces, tiger teams, rapid-response teams, and so on. They may stand alone or be part of a matrix organization in which employees report to both cross-functional and functional teams. In this way, the agile organization combines stability with a quick-response capability. They gain further flexibility by sending a functional expert on a short-term assignment to help a cross-functional team with a specific problem. Employees can move back and forth between teams depending on the organization’s needs and the employees’ developmental goals. We’ll explore how teams help achieve the right level of response in the next chapter.

Smaller-scale restructuring is another way to respond when needed. For example, it may be faster to reorganize a few units of a few dozen or few hundred people than to reorganize divisions of thousands of people. If you have enough time and are confident that a smaller-scale restructuring will help employees respond to upcoming changes, then go ahead and restructure—or better yet, find a way to pilot your idea with part of the organization first. Also remember that modifying one aspect of the organization means that you will probably need to change other aspects, too, such as processes, roles, decision-making authorities, and the ways different parts of the organization work together.

Finally, if you do restructure, make sure that employees get the support they need to carry out their work in the new structure, or better yet, collaborate on the design of the new structure with the employees who will be affected. Just be sure to explain why a new structure is needed and provide the necessary conditions for the team members to accomplish their work: clear unit goals, defined roles and responsibilities, effective leadership, clear processes, and necessary resources.

IDENTIFY WELL-DEFINED PROCESSES

Another way that agile organizations maintain stability is by figuring out which processes are affected by known factors and can therefore benefit from standardized procedures. Processes that can be defined as a series of steps that should be carried out the same way each time can be normalized. In addition to defining the steps in the process, be sure to clearly define the handoffs at the beginning and end of the process, as that is where things often fall through the cracks and cause problems. For example, IT departments usually have a well-defined process for creating computer system accounts for new employees. When defining these steps, they should indicate what occurs at the beginning of the process—such as an email notification from human resources a few days before the new employee’s start date. They should also indicate what happens at the end—such as an email from the IT technician to the new employee’s supervisor that says the account has been set up. By explicitly defining every step in the process, including those at the beginning and end, you can ensure all team members are on the same page.

Although well-defined processes are typically used when factors in the environment are not changing in complex ways, changes may still occur that affect a well-defined process. You can prepare for them by creating contingency plans. If unanticipated changes start to occur regularly, then you should reconsider whether the process can continue to be well-defined. The process, or the specific part of the process, affected by unanticipated changes may need to become flexible. For example, when you call a help desk, you usually start off talking to someone who can handle a routine request, such as helping to reset a password or install a software update. If you have a more complicated problem, however, you are usually directed to a different support person who handles less-routine problems. Another example is the payroll process. The steps for making a salary adjustment or changing a tax withholding are known and defined, and these changes generally happen at the same time every year. However, some non-routine, unanticipated changes might be needed throughout the year, such as when a unique new position is created or a law suddenly enacts a temporary change to withholding amounts.

Employees who carry out well-defined processes should, in turn, have roles that are clearly defined. Job aids, “if-then” guidance, and contingency plans can provide structure and definition to employees working in these roles, allowing them to perform the process consistently each time while also helping new-hires learn it quickly. Another way to handle exceptions or unique situations is to have employees seek guidance from more senior employees or supervisors who have relevant expertise. A well-defined process should result in quick, efficient, and consistent products or customer service in most situations, and when a situation warrants a different response, employees should have enough psychological safety to bring in a colleague with more expertise.

Sometimes employees working in a well-defined process can find it helpful to have documentation in the form of job aids, procedures, or templates; however, the time necessary to create complete documentation may not always be warranted or available, such as when employees must respond right away or when a standard response is needed only for a short period. In these cases, here are a few tips to follow for a “just enough” approach to documentation:

• The documentation doesn’t need to be pretty; it just needs to be good enough for the purpose at hand.
• The documentation should meet the needs of the audience.
• The documentation should change or be updated as circumstances change; employees working in the process should be able to update the documentation based on what they learn as they carry out their work.
• To prevent silos from forming, employees working in the process should be able to share knowledge often, informally and formally, both with their functional or technical colleagues and with leadership.

Even well-defined processes can be improved. Tools such as business-process mapping, six sigma, and lean six sigma can be used to document existing processes and achieve incremental improvements. Processes can be improved iteratively by identifying possible improvements, trying them out, gathering metrics and stakeholder feedback, and then adjusting.

Steps within a process that do not add value can also be removed. There is a common roadblock to removing steps, however: employees who support those processes usually recognize where non-value-added steps exist, yet they don’t have the authority to remove those steps. This roadblock can be addressed by the advice we provided in chapter 4: pushing decisions to the level where the relevant expertise resides will help the organization respond faster and become more efficient. This advice is especially relevant when it comes to refining processes; employees supporting those processes should be given the authority to revise them, including removing unnecessary complexity, as long as they ensure their proposed changes will be effective and defensible. They should be expected to carry out a pilot or experiment, as well, to make sure the changes will not have unintended negative consequences on others, especially on those whose work feeds into or falls downstream of the process.

We’ve also seen many organizations attempt to improve a process—usually when an employee makes a misstep while carrying it out—by adding steps, reviews, and approvals over time. Unfortunately, this usually makes the process slower and ultimately ineffective. Rather than adding steps when someone makes a misstep, then, the agile organization enables the employee and other team members to learn from the misstep while highlighting part of the process that can, and likely should, be improved.

One way that an increasing number of organizations are speeding up standard processes is to use artificial intelligence (AI) and automation. Using AI allows them to carry out routine work faster while maintaining or even improving consistency and quality. For example, many doctors now use automated systems that incorporate AI to diagnose diseases more accurately than was possible in the past, which helps the doctor select the best treatment approach. As another example, some government agencies that process forms and letters from customers now use AI-enabled systems to route requests to the right person for processing.

But whether you are completely redefining a process, incorporating AI, eliminating steps that don’t add value, or adding steps to improve efficiency and standardization, all process changes can be tested using experimentation. Rather than testing out possible redesign solutions in a “live” process, however, it’s often best to use an experimentation approach that relies on testing specific parts of a solution in a safe or “offline” manner. Trying out completely new approaches to carrying out a process could be risky and result in highly negative consequences, such as harm to people, delays in service, or dissatisfied customers. For example, it’s probably not advisable to put an airplane pilot and passengers in a new type of aircraft that has not first undergone significant safety testing. Rather, the aircraft should be determined as safe through a series of tests. Perhaps, this would start with simulations that show the aircraft can fly at the required altitude and engineering tests to confirm that the materials and structure can withstand takeoffs and landings, eventually leading to test flights under controlled conditions. On the other hand, small or incremental changes to a well-defined process can often be carried out safely, allowing a solution to be refined and confirmed; so it may be perfectly safe to install a new type of seat-back tray in a few airplanes in order to gauge customers’ and flight attendants’ reactions before installing them across the fleet. But regardless of the testing approach, once a solution is perfected, it can then be integrated into the well-defined process, with job aids updated to reflect new steps.

Finally, if you find that incremental improvements will not yield the results that you need, you may have to consider completely redesigning the process from scratch, which we will explore in more detail in chapter 7.

STAFF STABLE PROCESSES WITH STABLE ROLES

Once you have identified the processes that should be well-defined, you will need to find the right people to carry them out. Agile organizations don’t just put anyone into those roles. In addition to making sure that employees have the skills they need for the job (while adhering to legal, human resource, union, and other requirements), agile organizations look for employees who prefer to work in routine and predictable situations.

People tend to self-select into jobs and roles that fit their personalities and interests. So when there’s a choice about which role to place an employee in, their ability to deal well with ambiguity is one factor to take into account. Or better yet, ask the employee what her preference is. For example, two engineers with similar skill sets may have different personal preferences about their work; one may prefer the routine of supporting a defined process, while the other may enjoy the variety involved in reengineering processes or defining new ones. Both engineers would look for opportunities to improve processes but would do so in different ways. The engineer supporting the routine process might rely on process-improvement approaches, such as lean six sigma or process mapping, while the other engineer might find that design thinking, use cases, or other innovation approaches are more applicable.

Leaders should demonstrate and communicate that both well-defined and flexible processes and roles provide value to the organization. It’s easy for employees to perceive that their work culture prefers one over the other, so leaders should help them understand that both types of processes support organizational agility. Leaders can even turn the tension between the two processes into an ongoing exercise to find the right balance. Of course, the specific roles and number of employees supporting each type of process may change over time. For example, as work becomes more automated, the amount of routine work typically decreases and the amount of non-routine work increases (e.g., handling rare cases, new types of cases, or problems that pop up).

Leaders also need to recognize which employees might not transition easily from a well-defined to a flexible role. Employees who thrive in a predicable routine don’t always succeed when every situation requires a different response; conversely, employees who prefer variety and developing creative, yet viable, solutions can be quickly bored by routine work. At the same time, rotating employees within each type of role can promote employee development. Employees in well-defined roles can develop by learning process-improvement tools and techniques as well as specialized functional or technical expertise.

Finally, note that while many organizations have undefined processes that would benefit from more standardization and documentation, the trick is figuring out the right level of detail to include in such documentation. We’ve seen organizations fail because they provided too much detail and didn’t account for a basic level of tacit knowledge. Or they provided too many specifics that would soon be outdated (e.g., when a new software version was released and menu options changed). So be sure that your well-defined processes provide enough clarity without becoming overly specific or detailed.

PROVIDE STABLE NORMS AND EXPECTATIONS

Another way that agile organizations provide stability is through consistent norms. Leaders in an agile organization provide a sense of stability by ensuring that clear, shared norms are accepted and followed. And norms must support the behaviors that are needed. Examples of norms that should not change over time include the following:

• We openly share knowledge as widely as possible.
• We encourage new ideas.
• New ideas can come from anywhere—from any level of the organization and even from outside the organization.
• We learn from experiments and pilots.
• Employee development is an investment.
• Leaders do not have to have all of the answers.

Agile leaders actively manage the organizational culture—which is simply the behaviors and actions that people are expected to carry out—by involving employees in a collaborative discussion to define the norms. As a leader, you can facilitate discussion to identify and define norms that support agility, but the exact wording of these norms should be the employees’ own, and the norms should be shared explicitly. Although posting the norms in visible locations, such as in a lunchroom, in a conference room, or on a website is a good way to make them explicit, you will need to do more to get employees to follow them. Some employees will instantly try out the new norms to see if it’s really okay to follow them, while others will wait to see what happens to those who are early adopters.

To encourage adoption, you must find positive examples of people displaying the norms and be genuine when you highlight those positive examples. Think back to chapter 2 and the skills you developed in giving specific, positive feedback. When you see someone acting in accordance with a norm, point it out to reinforce that the person did the right thing. This might be a simple “You did a great job listening to your coworkers’ idea” or a shout-out in an email or newsletter. Keep in mind that praise should be meaningful to the employee you’re giving it to. In other words, not everyone relishes public recognition, so a more personal “thank you” may be better for some. You may need a keen eye to spot these behaviors at first but will probably find them easier to spot as time goes on and the norms begin to take hold.

Another way to catch someone doing the right thing is to ask employees to share their own examples of adhering to the norms. Some organizations hold daily or weekly status meetings, which are great opportunities to allocate five minutes for employees to share examples of their own or teammates’ actions that demonstrate desirable behaviors. At first, sharing positive examples might seem like bragging, so make sure to draw a connection between the examples and team norms. This practice does not have to be time-consuming or permanent either. Use it when your team is working on adopting a new norm and retire it when you’ve implemented the changes that you or your team desired.

Finally, explain your actions and decisions in reference to the norms. It’s not always obvious to employees how you arrived at a course of action or decision; some explanation of your rationale and thought process can help demonstrate your commitment. You might explain that a certain decision was made by testing out two options, for example. Or you might describe the process you went through to make the decision, explaining your decision-making approach. If you are a new leader, ask other leaders to share the organization’s norms if necessary. They will likely want to gain your buy-in. Communicate your acceptance of and intention to keep those norms to engender trust while maintaining the sense of psychological safety in the organization.

MYTH: WE CAN RESPOND TO FREQUENT CHANGES BY RESTRUCTURING

We’ve seen many organizations use restructuring as the primary mechanism for responding to change. When we talk with employees whose organization is undergoing a restructuring initiative, we often hear that only the “boxes and lines” on the organization chart will change, despite significant resources allocated to the effort. Employees frequently also describe a range of less-than-desirable results from restructuring, including processes that remain unchanged, roles that become more unclear, and an increased mistrust of leaders who don’t adequately communicate the reasons behind the restructuring. To employees facing turbulent, complex changes, having to focus on figuring out a new structure takes time that could otherwise be devoted to agility routines. In short, employees often perceive that restructuring will not address the changes that the organization is facing.

The truth is that when situations change rapidly and in complex ways, establishing teams is a much more effective way to deal with those changes than restructuring. We will talk more about how you might leverage small teams to respond to rapid, complex change in the next chapter. For now, let’s just say that keeping the organizational structure stable can help keep everyone focused on responding.

Blair decides to chat with Vincent. She explains, “Our standard contracting process isn’t going anywhere. The work that Barb is leading—to explore ideas for a more incremental approach—will never completely replace what we usually do. Instead, we may have two approaches operating at the same time. Let’s talk more about why our standard approach still isn’t always getting us the results we want. I’d like you to lead an effort to update the process guide.”

Vincent expresses relief that Blair isn’t throwing out a perfectly good process. He replies, “Well, the process guide does need some improvement. Some parts of it are incomplete; other parts aren’t written down. And another part of the problem might be that the process described in the guide is just inefficient.”

She suggests that he get help from a couple team members and ask them to use their network—people on their team, on other teams, and in the programs—to come up with ideas for improving the guide. She also gives him the email address of a process-improvement specialist in the western division.

A week later, Barry asks if they need to restructure the division so that they can meet the new requests from programs.

“No, not right now,” Blair says, “but it might be a possibility in the future, depending on what Barb learns about the programs’ needs. First, we need to focus on designing a more responsive process that improves our efficiency for standard contracts. If we think that the programs will continue to need an incremental process, then we can decide if we need to change our structure. I don’t want to reorganize if the programs’ quick-turnaround needs won’t continue.”

“Will we all be required to learn the new process?” Vincent asks.

“Of course not,” Blair responds. “I want you all to be learning new things. But I won’t force you to learn; what you learn is really up to you. And we need your expertise on the standard process, Vincent.”

Relieved, Vincent starts to see a new role for himself, one in which he can rely on all of his years of experience to finally work out the kinks in the standard process. He also realizes that taking out the quick-turnaround work will speed up the processing for standard contracts. He tells Blair, “Barb and I will need to find a way to route incoming requests into the right process. If we can do that, then it should be possible to update the steps in the process guide, get everyone on the same page, and quickly train new team members.”

Blair nods approvingly. “That’s a great idea! I know you have a lot of knowledge in your head. The team would really benefit from documenting all of that knowledge so that they can learn from you.”

Blair starts to feel that the tension between the “old” and “new” way of doing things may be starting to dissipate. She’s heard some of the more experienced team members complain that newer team members ignore the process guide, while newer employees say the more tenured team members are stuck in their ways. Blair’s message that both the old and new ways are necessary—reinforced by her efforts to put people into roles that support each—might be starting to sink in. Blair is confident that getting everyone working on the same page with the process guide will improve the team’s efficiency in carrying out routine work.

1. Jessica Tierney and Greg Waldrip contributed to this chapter.