CHAPTER 7

Guide, and Allow for Variation

Empower reasonable deviation and new possibilities.

STANDARDIZED PROCESSES DO MAKE SENSE WHEN LOW variation is desirable and possible, given the nature of demand. Standards are necessary to communicate and manage requirements pertaining to product safety, quality, and adherence to mandated protections and regulations (FDA, IFRS, GAAP,¹ and the like). Standard practices are essential when equity and fairness are a concern across an organization. For example, diversity and inclusion practices need to be consistent across an entire company. Likewise, expectations for ethical behavior must be the same at all levels from top to bottom.

In other cases, applying the same process or standard can lead to problems and waste. In these situations, coherence is more desirable than consistency—aiming for the similar outcome but with flexibility to respond to varying conditions and avoid working at cross purposes. Standardize for simple problems where best practices apply, simplify and call on experts for complicated ones, and allow for local variation and emergence when problems are complex.

Seeking more-predictable project performance, an upstart financial services firm that had upended the industry by courting clients with less-than-stellar credit scores brought in a VP with a deep background in formal project management. He set out to standardize project management practices. He provided managers with a template that spelled out required milestones and activities. He handed out checklists and criteria forms. He specified a standard status-meeting agenda for use by all projects. He held up an ideal that project sponsors should expect a uniform experience.

But the projects in his division were not uniform. Some involved automating existing processes; others invented new customer experiences and tested new products. The company’s strongest project managers recognized the need to plan adaptively and choose an approach that fit the unique characteristics of a particular project. They chafed against the VPs restrictions. Many kept two sets of plans: one that guided the project and one to show the VP. Less experienced project managers followed the new rules and struggled to force-fit work into the required milestones and to track actuals against task categories that didn’t match the work.

There is nothing wrong with wanting more-predictable project performance (for some definition of predictable). But this method, aside from being heavy-handed, overconstrained the project managers without achieving transparency and open communication (which can help with predictability).

To my eye, this is an excellent example of a case in which some global principles apply and local variation is necessary. It might not be possible to achieve a completely uniform project experience because the projects and the people aren’t uniform (including the sponsors). Yet there are core principles about communicating progress and risk that apply to most projects. Those can be followed while accommodating project variation. Boundary stories provide a way to avoid mandating when it is unnecessary (and potentially harmful) and achieve desired outcomes.

Guiding with Boundary Stories

The day was “crisp,” as we say in early January when the temperature rises to a balmy −10 degrees F in northern Minnesota. It is a welcome relief from even lower temperatures. I’d picked up an urgent phone call from the CEO of a tech company in New York. This wasn’t his first successful company—he’d sold his first and could have settled into early retirement. This new company was a consulting firm that specialized in bringing technical chops to tough problems. The company aimed to deliver code but also to improve the tech capabilities of teams they worked with.

This CEO wasn’t a rookie, and he recognized a serious problem when he saw one. He’d just seen a big one in the annual employee engagement survey.

“Too many people feel blindsided in their year-end performance discussions. That came through loud and clear in our survey,” he told me. “I’m meeting with my managers next week to address this. I’ve decided to require every manager to meet with each direct report on a regular basis.”

Regular check-ins seemed like a reasonable idea. “How often should I tell them to meet?” he asked. “Weekly? Biweekly? Monthly?”

I gave the universal consultant answer: “It depends.”

“Depends on what?” he asked. I provided a few examples, such as experience, learning curves, client sensitivity and risk, development goals, the skills a person was working on, and so forth.

“I need a matrix that tells managers how frequently they should meet,” he posited.

“Not exactly,” I replied. “Focus on the outcome you want, and then let people use their best judgment on a case-by-case basis.”

We talked a bit more, and the CEO agreed that weekly meetings were not the goal. The outcome he wanted was for people to feel supported by their managers and treated fairly. To achieve that, he wanted managers to point out any problems they saw, have conversations, address issues early, and get things back on track. If that meant an informal chat on a monthly basis, weekly one-on-ones with a formal agenda, or some other means, that was okay. It was the end that mattered.

When the CEO met with managers to discuss the engagement survey, he told them, “I want to hear more stories about people feeling supported by their managers and that managers care about their professional growth” and “I want to hear fewer stories about people feeling blindsided by problems at their year-end reviews.” Within those boundaries, managers determined meeting frequency, topics, and focus based on individuals and specific situations.

The CEO achieved his goal and avoided the dreaded checkbox problem: going through the motions and checking the box. Checkbox behavior happens when people complete a mandated activity or follow practices without understanding the value behind it (or achieving the desired outcome—I see this with retrospectives and other agile practices). Checkbox behavior is compliance at best. Boundary stories support mindful variation within boundaries rather than mindless adherence to a mandate.

Appropriate Variation Is Necessary

I’ve experimented with different ways to describe this concept and find that this analogy often helps: Suppose you want to plant trees across a wide area. Specifically, you want oaks (genus Quercus) because they are long-lived, generally pest- and disease-free, and very beautiful. There are hundreds of oak species. It would be easy to choose one particular oak if conditions were uniform across that wide area. If the conditions are not uniform, the chosen species will thrive and grow to their full potential in only some niches. Trees may survive but fail to thrive, resulting in a smaller, less-resilient forest. Some will simply die because they are not suited to the environment in which they have been planted.

Each oak species thrives in specific conditions. Swamp white oak, water oak, and pin and willow oak flourish in wet conditions. Quercus rubra, or northern red oak, adapts to many soil conditions in US hardiness zones 3 through 8. Black oak (Quercus velutina) does better with more moisture and good soil. The genus is the principle; the local environment determines which species is the best choice. SEE 7.1

Okay, nice analogy, but deciding what to manage closely and what can vary isn’t like boring soil samples, examining historical weather patterns, assessing plant communities, and googling which oak will work best.

7.1  The oak tree analogy: you know you need an oak, but which oak depends on the environmental conditions. In organizations the outcome may be clear, but how people achieve it depends on their local context.

A client with teams in the United States, Europe, and India planned to roll out a standard project framework across several software development teams. We did an exercise to understand local variations. First we identified several characteristics that seemed relevant to the teams and their work. Considering each characteristic, the client and I talked about the various teams and gauged whether all of them were essentially similar, completely different, or had both similarities and differences. SEE 7.2 After visualizing similarities and differences across those locations, the client took a different approach. All the groups needed to cooperate on some level, and others collaborated closely. The leaders articulated the desired outcome and a handful of constraints:

7.2  This figure depicts the initial analysis of similarities and differences across several teams. Though they all did software development work, there were some differences in the types of work and the programming languages used. Cultural differences were even more significant. This discussion raised awareness that a one-size-fits-all approach wasn’t appropriate. After this exercise, the group completed a more granular analysis to identify clusters of similarities.

    Use terminology in the same way (e.g., implementation testing and definition of done needed to convey the same idea on all sites).

    Avoid optimizing local work at the expense of overall group effectiveness (coherence).

    Consider the customer’s point of view.

Choosing what must be managed closely and what can evolve is not an exact science. Nor is it a once-and-done decision. It requires scanning, looking for appropriate adaptation, and allowing people to use their heads and creativity. Conversely, also scan for people copying without due consideration or checking boxes. Look for contexts in which something completely different might be needed, then adjust boundaries for variation accordingly.

Shaping Patterns with Constraints

Constraints can be stated explicitly. In the early 1990s, I participated in Jerry Weinberg’s Problem-Solving Leadership workshop. In 2007 I started co-teaching the workshop with him.² One of the featured exercises involves crafting a problem for another group to solve. The exercise specifies an outcome and provides three explicit constraints. I verbally convey a limit: I will reject any candidate designs that involve choices about which participants will live and which will die (this boundary was added after one group designed such a problem).

Over the years there have never been two problems that were exactly the same, though there have been similar themes. Given these minimal constraints, the participant teams discover one another’s skills and unleash creativity. The problems they design (and the way the other participants solve them) go well beyond what I might devise or even imagine on my own. The key to success of both the workshop exercise and the participant-designed problems is the use of constraints.

Boundary stories act as constraints, as do requirements and standards. In life outside of work, people use and operate within constraints to shape patterns without giving it a second thought. A theme for a party, a vacation budget, limits on screen time—all are constraints that shape patterns.³ Once you start consciously noticing constraints, you see them everywhere. You may have to live with systemwide constrains (see the SEEM model described in chapter 4), but you can work with those in your domain consciously—tightening, loosening, adding or removing them—to shift patterns.

Guiding Evolutionary Change

Many change plans focus on activities—defining new processes, developing communication plans, and designing and scheduling training. Action matters. In complex systems, however, change happens and new patterns form through small evolutionary steps. Those evolutionary steps occur when the conditions allow for something new to emerge. Processes, communication, and training—all are most effective when they support creating the conditions for the next evolutionary step, rather than focus only on end-state behavior change.

How do you find the next evolutionary step? Landing zones (described in chapter 6) do something similar but typically focus on a particular problem. A horizon map is a thinking tool that uses a similar thought process on a broader scale; it helps people determine the conditions that must exist for a new pattern. SEE 7.3 I used this method with a client whose aspirational statement was Customers love our product. Delivering on that statement required much more than an attractive product that performed well in marketing tests. The client needed to build the internal capability to produce and support that product.

7.3  Horizon maps help people think about the conditions that must exist for a new pattern. Think right to left, then work left to right. This is a thinking tool, not a plan. Experiments and actions change the system, and conditions will change. Keep scanning to find new opportunities to build on and new insights about what is needed.

We worked backward from the aspirational statement, answering a series of questions for each of the SEEM domains: Steering, Enabling-and-Enhancing, and Making (see chapter 4):

    For that to happen, what conditions must exist?

    What constraints might be at play?

    What must people know how to do?

    What must people learn?

Based on those answers, characterize the state:

    What would we see and hear if this state were realized?

    How would we detect and recognize that we’d achieved this state?

They kept working backward toward the current state until they found the near-neighbor state—their next evolutionary step. The horizon map made it clear that it wasn’t strictly a matter of building up skills and processes in frontline teams.

These maps look something like the output of Effects Based Planning,⁴ an operational planning process to conduct effects-based operations within rapid-decision operations. (I sometimes use EBP software when I’m thinking on my own about nudging a system.) The maps give an indication of how changing one thing will influence others and how precursors for one intermediate state support other states.

This is a useful reminder that everything touches everything and that changing one thing is likely to have a ripple effect. For this reason I don’t worry much about precision, and I expect the map to shift (sometimes significantly) after a few interventions. This is a wonderful dynamic, but it does require letting go of the notion of following a plan. Instead follow effects; options and actions that aren’t visible or possible from the current state of the system become available as the system evolves.

Evolving the System Iteratively

In a presentation at the Agile2015 Conference in Washington, DC, Hendrik Esser, VP of operations and programs at Ericsson, described seven iterations aimed at changing how organizations handled uncertainty across levels. The goal was to reach a point where both R&D and product organizations accepted that uncertainty was normal and ever-present in their projects and responded productively.

In the first iteration, they started including ranges in all estimates and plans to make uncertainty more visible. This made it possible to talk about the uncertainty in their projects, which led to many debates. The second iteration introduced tool support for capturing plan and estimate ranges, lending more organizational weight to the concept. Teams hated the tool, however, so in the third iteration they lightened up, made the tool optional, and provided a lightweight process for determining ranges. At the time of the presentation, they’d been through seven rounds of shifting the system with small evolutionary steps. They’d make significant progress, to the point where they could have productive conversations about uncertainty both internally and with customers.

Ericsson’s success didn’t result from a perfect plan and flawless execution. It came vis system tweaks, fast feedback, learning, and persistence.

Shifting Narratives

Change involves modifying conditions and adjusting constraints, structures, and policies. It also involves altering habits of thought and cognitive frameworks. Organizations are inherently social; thus the change in cognitive frameworks must transcend the individual. It must extend to influencing the organization’s metaphors and narratives (by this I mean sense-making in a shared context), which profoundly shape what people see as possible and how they explain the past. That’s a social process.

A number of large-group methodologies (e.g., Open Space, World Café) support people to engage an issue and generate new ways of thinking and talking about it. Gervase Bushe, professor of leadership and organization development at the Beedie School of Business at Simon Fraser University in Vancouver and a seminal thinker in the field of dialogic organizational development, recommends focusing on an issue instead of a predetermined outcome.

“The point of these events is not to identify, agree upon, and then implement the change,” he writes. Rather, the purpose is to change narratives and create a sense of different options for decisions, actions, and interactions (Bushe 2013). Seeing new options may lead to experiments or contribute to the next evolutionary step.

Such shifts in an organization can also occur though inserting new questions. Recall the discussion in chapter 2 of the development teams who “weren’t accountable.” The vice president’s explanation for why work wasn’t getting done was that the development teams didn’t have the motivation (or perhaps the good character) to follow through on commitments. Variations on that theme carried through discussions at all levels (except among the developers). Asking new questions prompts different explanations and, over time, shifts how people make sense of events.

My questions obliquely challenged the narrative by bringing in bits of data related to the developers’ context, who was involved in commitment meetings, and so on. Slowly, the narrative shifted, as did the level of problem-solving. With the shift they were able to look more broadly and systemically at their problems.

KEY TAKEAWAYS

    There are situations in which standardization is essential. When there is one known best way and little to no variation in the work, standardize! Knowledge work and complex organizations involve variety, however, and unnecessary standardization can stifle ownership and lead to illogical, inefficient, and suboptimal behaviors.

    Attractors, such as vision statements, tell people the direction of travel, but they aren’t enough to get anyone to the destination. Focus on the near-neighbor and taking the next evolutionary step to make progress and maintain motivation.

    Complex change is impossible to predict and, frankly, messy. Learn to live with the mess and muddle through. Try something, observe, adjust, and keep moving forward until the way becomes clear (or at least until it gets messy and foggy again).

    Boundary stories give people concrete examples of desirable and undesirable outcomes without overspecifying the means. I’ve seen many wonderful, creative solutions emerge when people know the need they are working to meet, set appropriate boundaries, and have complete freedom within those bounds. Targets lead to gaming, and checklists can lead to rote behavior and surface compliance.

    Articulate the outcomes and the rationale behind them, then add a handful of constraints or boundary stories to guide adaptation. When people have freedom to bring their own knowledge, experience, and intelligence to refining a change, they own it. They aren’t victims, but co-creators. That’s a success story.