Scenario-Focused Engineering (2014)

---

Semantics matter

Are you a professional designer? Have you ever found that talking to an engineer about your craft was difficult? If so, you are not alone. One thing we learned, very early on, is that with engineers, the words you use matter.

In the very beginning, when we were experimenting with different content, formats, and instructional design patterns, we inherited a workshop titled “User Experience Design for Other Disciplines.” Okay, we confess, it’s a terrible name. As you might expect, the people who were attracted to that name were generally those who were looking to understand the design discipline at Microsoft. Some were considering a career change, and others already knew that they wanted to collaborate better with the designers on their team. But that was a relatively small number of people. And to be honest, the individuals who signed up for that course weren’t the most senior or the most influential people in the company.

Because our desire was to immerse the engineering population at Microsoft into the world of design thinking and user-centered design, we knew we had to somehow reach a different audience. The early feedback we received on the workshop content told us we were heading in the right direction, all we had to do was get the right people interested and motivated to consider change. The content of the workshop wouldn’t matter if we couldn’t get the right people to attend in the first place.

We tested a lot of different names, many of which were some variant of “Design Thinking,” “Design for Engineers,” “User-Centered Design,” and so on. Through those trials we discovered that design means a lot of different things to a lot of different people. We learned that many engineers have an allergic reaction to the word design. Associations such as “artsy, nonproductive, waste of time, and flower-shirted, pot-smoking creatives who are on a different planet and add no value to me” come to mind. Ugh. (And our sincere apologies to anyone reading this who is currently wearing a black turtleneck. Please read on.) What were we to do?

We eventually named the workshop “Scenario-Focused Engineering.” This title proved to be much more acceptable to our audience of leaders and technical engineers. The idea of writing scenarios was enjoying a resurgence at the time, so that made the name naturally interesting. And people’s general reaction to those words tended to be something like “I can guess what a scenario is, and I can see value in using one to drive an engineering project.” The word scenario was something concrete they could immediately understand, with no ambiguity or magical fairy dust. In that way, we found our audience to be open to listening to what we had to say. The SFE title has worked well and has served as a Trojan horse of sorts for the meta-topics of user-centered design and design thinking that we introduce.

The title has also failed us in some ways. Once we put “Scenario-Focused Engineering” on the door, some teams tended to give too much weight to the importance of scenarios in the grand scheme. (We talk about this phenomenon specifically in a previous lesson in this chapter.) We never did find a perfect solution to this particular naming problem.

Another lesson we’ve learned is about the power of aligning a group of people on a shared context and new vocabulary. We learned this fairly early, both on our own team and by watching teams go through the SFE workshop. After the workshop, we would see the new vocabulary begin to emerge in teams. We began to hear words and phrases such as “scenario,” “empathy,” “diverge and converge,” “less is more,” “you are not the customer,” “marinate,” or “let’s iterate one more time” as part of a team’s vernacular. Even teams that did not make dramatic changes to their processes still found tremendous value in the workshop because it normalized terms and created a shared language across their team. The importance of using words to get a team on the same page and communicating more smoothly was evident. The new “language” that teams developed created a sense of tribe among team members and was an important part of establishing a culture around the iterative process that focused on deep customer empathy.

The role of leaders

In our ongoing work with teams, it’s been clear that teams that make the biggest changes are those with strong leadership—with leaders who cared deeply about their customers.

Leaders: What got you here, won’t get you there

Even though the leaders we worked with knew they had to change their behaviors, we witnessed over and over again how hard it was for them to step into a new relationship with their team and nurture a customer-focused, iterative approach. We believe that the root problem is that these leaders have spent many years acting as decision makers. If someone has a question, these leaders are supposed to have the answer. Leaders have probably spent many, many years in the industry. And, in fact, they probably became a leader precisely because they did have some customer empathy, business savvy, and the ability to come up with creative solutions. As we mentioned in the previous chapter, these successful leaders have spent many years living the life of a HiPPO.

And when you live the life of a HiPPO, you get used to people listening to you and doing what you say. The trouble is that if a team truly wants to operate in a customer-focused way, the HiPPO needs to let customer feedback, not his or her personal opinions, drive decisions at many points. The discovery of great solutions is most likely to occur in a trusted group where you encourage crazy ideas, build on the ideas of others, and say the words “Yes, and . . .” a lot. The value of an idea is judged by customer feedback and not by whose idea it is, regardless of whether it comes from the newest hire or the most senior team leader. The customer-focused culture you aspire to gets messed up when a HiPPO is continually asserting his or her opinion, making decisions, and trying to drive the ship in the same way as always.

It’s not that leaders don’t need to make decisions anymore, far from it. A good leader is still responsible for the team’s business strategy and sets crucial guardrails and constraints within which the team must work. Leaders need to focus their team on a small set of target customers and make the bet on which customers and businesses are most lucrative. They may even act as tiebreakers from time to time when several solutions are available that seem equivalent or when a key tradeoff must be made. But for the bulk of the formation of detailed product plans and execution, leaders need to let go and trust in the iterative process. They must trust their team to talk to customers, listen to customer needs, come up with ideas, get feedback on those ideas, and iterate them until customers are delighted. A leader’s role becomes one of coaching the team to ensure that the right steps of due diligence are followed and to hold the team accountable for delivering compelling end-to-end experiences. Leaders need to make the shift from knowing the right answers to knowing which are the right questions.

As former HiPPOs, we can tell you how difficult it is to let go, to think of our personal opinions as being no more and no less valid than anyone else’s on the team, to accept that our instincts in knowing what customers want are not always accurate. Making the transition from being a person who is highly influential in the planning and creation of a product to being a coach, guide, and customer advocate who relentlessly tracks customer feedback and holds the team accountable for delighting the customer is very difficult. The pivotal moment in this change is when a leader realizes that her job is no longer to control the plan but to provide direction and to set the boundaries that enable the team to iterate the plan as quickly and efficiently as possible.

Here are specific areas where leaders have particular trouble or where they make mistakes that hamper their teams:

Allowing early iterations to truly inform product plans proved tricky for many leaders. Some leaders insist that their teams develop complete, final plans before they have really done much iteration. It’s tough for leaders to have the patience to allow a few iterations to happen without having a clear plan. It’s even harder for them to realize that the initial plan might be wrong and might need to change, possibly drastically. While the rational side of your brain knows that it’s better to allow iteration to happen up front—rather than find out much later that you built something no one wants or you have major issues to resolve—it’s tough for leaders to have the patience to last through the ambiguity of the early iterations.

It is also common for leaders to push teams to make decisions too soon, before the customer need and value are clearly articulated and validated with feedback. It’s very difficult for a team to report on the feedback and progress of three solution ideas when the manager is demanding to know exactly what the team is building and becomes frustrated with what seems to be an ambiguous answer.

One of the more unfortunate situations we saw involved leaders who empowered their teams to use a customer-focused, iterative approach but then imposed their own plan when what the team came up with didn’t match what the leaders had expected. This created a huge amount of ill will on the team because it essentially made the customer-focused iteration a sham process that was ultimately ignored or greatly discounted. The lesson learned is “Don’t disempower a team after you empower it.”

Letting go of a completely predictable schedule is one of the hardest cultural shifts that the managers of an Agile team need to make. Managers naturally want to know what you’re going to build, how long it’s going to take, how many people you need to do it, and what the end result is going to look like. We all know that it’s impossible to know all of these things in advance, but still somehow we pretend that we do and make our best guesses, if only to satisfy the boss. The reality, of course, is that there will be plenty of gotchas and mistakes and miscalculations and improvements that need to be dealt with throughout the project. The only question is whether you plan for those up front, allow yourself to be surprised during the course of the project, or feel bad when your first ideas don’t pan out as well as you thought they would. Seasoned managers know this, too: they know full well that the team will never ship what it originally intended to build, and usually leaders are quite happy as long as the biggest, most important investment areas land successfully. The rest is just extra. So stop fooling yourself, and instead of “committing” to a particular plan by a particular day, commit to getting a particular piece of the plan working to a high level of quality before you pick off the next major piece of work. This doesn’t mean that you don’t build a plan. Indeed, a plan is critical so that everyone can coordinate and be rowing in the same direction. But you have to have the humility to believe that your plan is imperfect and to leave space to make adjustments as you iterate.

The lesson learned is that leaders have to change, too, and their shift may be the hardest of all. They need to empower their teams to make decisions and not require teams to run ideas by the boss before they make a decision. They must embrace the iterative process and trust that it will lead to an optimal solution as quickly as humanly possible. You might be able to build a crummy solution faster, but is that really going to get you where you want to go?

You can’t fake a business strategy

We can’t count how many times we’ve talked with a bunch of group managers prior to running a workshop for their teams and found that they can’t clearly articulate who their target customers are or just describe their target customer extremely broadly (“anyone with a computer” or “enterprise customers,” for example). Digging a little deeper, it’s often not entirely clear what their business strategy is either. Or, more likely, they have several reasonable directional ideas but haven’t really done the work to test those ideas with customers or even to take the time to build consensus among the team’s leadership about what direction they should try first. Without a clear strategy, it’s no wonder that they have trouble identifying their target customers and crisply communicating that strategy to their teams.

Later, we’d hear from individuals on these teams that they didn’t know who their target customers were and never got a straight answer when they asked their leaders, so they felt like they couldn’t really use customer-focused approaches. The more industrious team members made up reasonable target customers on their own, thereby creating their own version of a strategic direction in the absence of an official one, which sometimes resulted in several competing customer targets across the team. Members of these teams commonly reported frustration about team politics and disagreement and confusion about what were the most important things to work on and how to make progress. Not having a clear direction certainly does make prioritization very difficult. Decisions become unstable and unwind when someone changes his or her mind or when different people are in the room. These teams eventually build something, but it is painful to watch and not very efficient, and none of the products they ship are particularly outstanding.

How you build a business strategy is outside the scope of this book, and we list several great references in Appendix C that we encourage you to read. But our lesson is that having a clear business strategy isn’t optional; you can’t fake it. A team needs a clear direction to make forward progress in an efficient manner and then either confirm that the direction is viable or to use data to instigate making a change. Leaders need to communicate that direction so that everyone is working toward the same North Star and with a shared mission.

You can’t overcommunicate

Nearly all of the leaders we’ve worked with appreciate the fact that they need to communicate a huge amount of information to their teams as part of the shift to SFE practices. Whether it’s announcing changes to schedules and tools or reinforcing behaviors they wanted to see, there is plenty to talk about. Leaders assured us that they were getting the word out.

However, when we talked to individuals on various teams later, the message we heard was invariably very different. Those folks felt like they still didn’t know what’s going on. They didn’t know who their target customers are, what scenarios had been prioritized, or what they should be working on. In a more severe case, a schedule was created, but substantial portions of the team missed the first deadline because they had no idea there was even a deadline coming up.

When we’ve dug into a few of these situations, leaders were always surprised. They agreed that they could certainly do more to communicate, but they felt as though the major messages had been more than adequately communicated, in some cases multiple times, and didn’t believe that the team felt so uninformed. In fact, leaders worried that they were going to start sounding repetitive, that the team was going to tune them out for saying the same things over and over again. Yet we never heard a single team complain about too much communication, too much repetition, or anything remotely like that. Sometimes, the problem was that the message was delivered only once, maybe in an all-hands meeting or in a long status email. But it often seemed that it was just a matter of not enough repetition, and the simple truth that not everyone reads every single email or attends every meeting.

Leaders who do a better job with communication realize that they need to rally the troops and be cheerleaders, not just relay information. Often they delegate this role to a key lieutenant who is in charge of beating the drum. Some teams create catch phrases or rallying cries. Others clearly articulate the team’s directives or create a short list of principles. The best leaders found regular, predictable ways to get information out, whether through a weekly email, all-hands meetings, or demos at the end of every iteration. These simple, memorable, repetitive messages helped keep people on track and keep the organization’s priorities and key milestones at the top of everyone’s mind.

The lesson we learned is that you can’t overdo communication. Overcommunicate, beat the drum.

The way to convince an executive . . .

How do you convince an executive that design is important? We have tried lots and lots of different approaches. Although some tech companies do have a culture and organizational structure that makes customer-focused design a leadership mantra, many do not. We’ve seen many talented people attempt to push inside their company the notion that design must be at the center and therefore you must place trusted designers at the highest levels of the organization so that they can implement a cultural shift toward design-centricity. That might be a great end goal for some, and may even be a recipe for success, but we have never seen that strategy work unless the top executive has already decided to drive that change.

Brute force and even logic will not work. The bottom line is that the leader who is going to drive change must have a sense of urgency that the long-term business is not as healthy as previously thought or that there is tremendous additional value that can be captured ahead of the competition. In class, we are very careful to frame the changes needed for customer focus as one leg of a stool. The other legs that you need are business and technology. So changing to a customer-focused approach is not about losing any of those existing assets or skills but about expanding your skills in developing team-wide customer empathy and then using that empathy to create compelling end-to-end customer experiences.

If you see advantages for your team in embracing some of the principles in this book, yet your leadership doesn’t see it that way, is resisting, or is unwilling to change, here are a few things you can try. There’s no single recipe for success, at least that we’ve been able to discover, but we have had a lot of success working with executives by using different combinations of these strategies.

Experiential approach

The best way to get someone to appreciate the power and potential of a good design process is to let them experience it firsthand. Among other institutions, the d.school at Stanford University has an excellent executive-education program that teaches professionals the techniques and values of design thinking using an experiential approach.

There are a number of interesting exercises that your team can do with a professional facilitator or just on its own. The “wallet” exercise provides an introduction to design thinking and is used at the Stanford d.school to experience how paper prototyping a new wallet for a colleague can be a productive approach for a difficult task.² The “marshmallow tower” challenge is another exercise used to help teams quickly experience the process of creativity and innovation.³ In this exercise, teams are given a limited amount of time to build the tallest tower they can using only marshmallows, tape, string, and spaghetti. Invariably, the team that builds the tallest tower is usually the one that brainstorms, collaborates, prototypes, and iterates over many options.

The biggest blocking issue with these experiential approaches is the amount of time they require. From the point of view of an executive (who in this case is your customer, right?), these hands-on experiences are costly in terms of time, requiring anywhere from a half-day to a week. To take this much time out for something that is foreign and unproven (to them) is often a deal breaker. If it’s improbable that you’ll be able to convince an executive to invest this much time, perhaps you can identify a trusted lieutenant who can instead.

Recruit the trusted lieutenant

If you can identify someone who the executive trusts, it’s usually easier to get this person’s time and attention to turn him or her into a champion of design thinking. Often, these lieutenants are on the lookout for new and interesting ways to advance the business and their own careers, and they may be more motivated to take the time to hear what you have to say and perhaps even to attend an experiential workshop. The advice of a trusted lieutenant is a powerful way to build buy-in. It’s even better if you can find several.

Start from the bottom up

One of the reasons the SFE workshop was adopted by so many teams at Microsoft is that we used a grassroots approach. The general pattern we followed was to first hold an open enrollment class, available to anyone. From that class, future champions would emerge. These were passionate people (albeit not particularly senior in the organizational hierarchy) who became enamored with the concepts we presented and who wanted to help their teams make a difference. They asked us if we would be willing to give the workshop to just their team. Our answer was always yes . . . but we told them that they first had to work from inside their team to develop the desire and sense of urgency up through the leadership ranks. We might offer to meet with a few other champions to help build a base of support in that team. Eventually, we would receive an email message several weeks or months later saying that the triad (program management, test, and development leaders) would like to speak to us about the SFE workshop and whether it would be appropriate for their team. During that first leadership meeting, we gave an overview of SFE and the key challenges of adopting it. For large teams, we arranged for team leaders to attend a half-day or full-day experiential workshop. In this way, the leadership team had the opportunity not only to learn about and experience Scenario-Focused Engineering but also to discuss which principles were more or less important for their team and to give us guidance so that we could customize the workshop to fit the team’s specific needs. This leadership workshop was an essential way for leaders to be exposed to the depth of these ideas, get hands-on experience, and create consensus among the group of team leaders for how to move forward.

Data approach

Many executives respond well to data. They want to see proof that there is a favorable cost vs. benefit and ROI for whatever you are proposing. To be brutally honest, we never had great success with this approach. We were never able to put together the killer data set that categorically proved to an analytical person that if you embrace customer focus and iterative techniques, you will be better off. We showed some analyses that correlated companies known for good design with stock prices, revenue, or market share. But correlation isn’t causation, there are always counter examples, and an analytical person can always poke holes in the data or the conclusions.

That said, we never went into a meeting with an executive without an ample supply of backup data. We just wouldn’t necessarily start with the data, nor would we rely on the data to be the convincing factor. It just never worked for us.

Defog the vanity metrics

Data did help, however, when either us (or, more likely, the champion who had been working on the team) presented data about that specific team, its customers, market-place, and competitors. The idea is to defog any and all vanity data that tells everyone how great the team is doing. The revenue, sales, and even survey data might all look quite positive. But show the leaders a multimedia presentation with their own customers displaying frustration, anger, or annoyance with their product, and then contrast that with customers showing love and loyalty for a competitor, and you may get some attention. In Chapter 1, “Why delight matters,” we talked about how in the team workshop we spend a good amount of time having participants list products they love and discuss why that is so. And then, in stark contrast, we have the room discuss “What are people saying about your product?” For many, that discussion creates an aha moment.

Read a book

We’ve seen executives become curious and have a strong thirst for understanding why it is that some companies tend to continually design great stuff for their customers. Many will do their own research and reading. If you have the opportunity, you may be able to recommend one or two books that you find relevant to your team and situation. When Tim Brown’s book Design for Change was first published, we gladly gave it to any leader who showed interest. We encountered some executives who read the recent biography of Steve Jobs to better understand the magic of Apple. A new book that we are recommending lately is Outside In by Harley Manning and Kerry Bodine.

And, of course, there is this book. Obviously, it hadn’t been written when we developed the SFE workshop. But maybe it will be helpful for some. Part I is designed to be approachable as a quick introduction.

Just do it

We’ve discovered that grassroots efforts can go a long way. If you don’t or can’t get top-down support from leadership, do what you can at your own job and level. Pick some of the techniques in this book and use them. Enlist the two or three people you work most closely with. When you are successful, others will notice and want to follow. Of course, you are a bit limited alone. You can’t get an entire engineering team to build prototypes and iterate quickly if they haven’t bought in to everything involved. And you may need to be creative about how you manage your schedule. But it’s certainly possible for you to quickly draw sketches and ask teammates opinions before committing to details. You can certainly raise your hand in a meeting and simply ask, “Why are we building that? Is there a customer in mind or a particular need that is being solved? Oh, really? Would it be okay if we took a few minutes to quickly see whether we can think of any other possible options?” Or you can go into the world to collect some qualitative and quantitative data on your customer. That data is often very interesting for a team, and once it exists, people will be curious. Share and keep referring back to that data to help drive daily decisions around you. Many have found that one of the easiest and most meaningful techniques to start using is to write a scenario describing a crucial customer problem, sketch a few storyboards, and use those as a tool to influence and align partner teams without getting into the weeds of arguing on implementation details.

Vote with your feet

This may not be practical for many people, and it is a last resort. But if you are deeply passionate about focusing on the customer, feel that your team and leadership have a different view, and are failing to lead them to a more customer-centered view, you always have the option to leave for a team with the same values and ideas about business, customers, and product development that you do. After all, business is business. Some succeed and many fail. If you discover that you are not on what you perceive to be a winning team, and you cannot affect the changes to make it a winning team, go find a winning team and join it. Everyone will be happier.

Managing change

Change is hard. We were often humbled by that fact. Here are some things we’ve learned about change.

Teams with sustained focus from leaders make bigger changes

Teams that have passionate, sustained, long-term support from their leaders are the ones that make the biggest changes, with broad adoption and large-scale changes to their culture. We figured out right away, when we started teaching teams, that team leaders needed to deeply understand and accept SFE ideas for a team to get anywhere. We learned over time that an initial burst of passion and buy-in was not really the important part. The teams that made the biggest leaps in their practices did so because their top leaders, often a vice president, director, or general manager, had strong conviction and drive about leading the team through this shift, and they sustained that focus over years, not just weeks or even months. They had long-term plans that counted on this shift and were able to create a sense of urgency on their teams that this shift was essential and must happen now. They proved the old adage that “you get what you measure,” and used metrics, project reviews, and a focus on scenarios to keep their teams focused.

The best leaders reiterated their goals and expectations in nearly every communication—in email, at all-hands meetings, in project reviews, in one-on-one conversations with their direct reports—and they formalized those expectations in the schedule, in team goals, and in personnel review criteria. They kept their focus on the changes they wanted to see, kept it at the top of their mind, and they held the team accountable and gave it feedback when they saw behavior that wasn’t aligned with their expectations. Leaders changed their own behavior in project reviews and other interactions with the team to ensure that they were practicing what they preached. When things got tough or there were bumps in the road, these leaders didn’t abandon their goals. Instead, they helped the team see a setback as valuable learning on the journey and encouraged the team to iterate and keep at it. Most importantly, they were not distracted from their top-line goals by the next shiny object, whether it was a competitive wrinkle, a new technology, or less-than-glowing customer feedback on their latest iteration. Leadership focus on customers and iteration continued alongside whatever else was happening in the landscape. Leaders who did these things rocked it, and the results showed.

On the other hand, a few leaders we worked with treated the workshop day more as a fun “morale event”—after all, the workshop got rave reviews, was highly interactive, and had teams brainstorming and developing ideas based directly on the team’s own target customers. Heck, their team might even come up with a breakthrough product idea right in class! These leaders believed the ideas we taught were all goodness, motherhood, and apple pie and wanted to expose their teams, hoping that some of it would rub off. Some leaders had the impression that their teams already worked this way, which was true some of the time, and saw the class mostly as a refresher. Overall, they thought that maybe their team would pick up and adopt some good changes, and the workshop certainly wouldn’t do any harm. Unsurprisingly, what actually happened in these cases was that a team would see some incremental benefits, but their leader did not have huge expectations, so this was perceived as a successful outcome for many of them.

For only a couple of teams did their leaders truly not understand what customer-focused iteration was about, despite a conversation we held with them ahead of the training day. Those workshop days were painful—for instructors, for leaders, and for their teams—as the depth of the disconnects surfaced and became obvious to everyone over the course of the day’s discussions. In those cases, we probably did more harm than good—stirring up a team to start thinking differently about how it went about building products—because its leadership had no intention to change their approach at all.

For the majority of teams, the top-level leaders had passion and a strong desire for driving a customer-focused change on their teams. They made the time and effort needed to take their management team through a special “leadership edition” of the SFE workshop a priority, and they supported the underlying principles we presented. They supported (and paid for) their entire team to go through the workshop. But problems came up weeks or months later, when those high-level leaders moved on to other urgent issues and stopped visibly following through on the changes they had initiated. In their minds, they had set the direction, delegated the responsibility for team-wide change to their middle-level managers, and assumed all was well. In these situations, it became difficult for the middle-level managers to drive change because the team did not see support for change coming from the top. The top leaders on these teams were the most disappointed: they had assumed big change was underway and were let down when they realized that the actual changes were smaller and slower than they had hoped for. They had underestimated the difficulty of change.

The bottom line is that sustained leadership, clear expectations, constant communication, and changing the way success is measured are major factors for successfully leading a team through this change. It takes a lot longer than you think to overcome old habits, and both managers and individuals need ongoing, clear signals from leadership that the effort and anxiety inherent in changing things is going to be worth it. If the leadership team isn’t fully committed to adopting these ideas, the large-scale, long-term change you may be hoping for is not going to happen.

Middle managers are the hardest to bring onboard

It wasn’t especially hard to convince rank-and-file members of each team to give Scenario-Focused Engineering a try. We quickly became pretty good at taking a room of (sometimes) skeptical engineers to the point where they could see that making changes might help them make better products.

It also wasn’t that difficult to show the value of customer-focused practices to higher-level leaders. They tend to take a longer-term, strategic view of their products and business and saw the inherent value of getting closer to customers and using customer feedback to fuel creativity. Most already understood the customer-focused, iterative approach intuitively.

We noticed, however, that group managers (middle managers) had the most difficult time seeing the value of SFE. To be more precise, they had difficulty seeing the value with enough confidence to outweigh the inherent risk of change. After all, they were being asked to consider changing the processes, tooling, and culture of their team. That’s a lot of change, and that made them weigh the risks very carefully. Change can be difficult and scary.

We realized that middle managers had the most to lose. They are the ones who feel responsible for executing the changes that are explored in the workshop. For them, embracing the iterative patterns of SFE represents a difficult and risky proposition, and if it didn’t work and they still didn’t deliver the right product on time, they were accountable. We found three important factors that helped middle managers get onboard:

Leader support Middle managers need confidence that their own manager believes in these ideas and genuinely wants them to pursue changes to build products that resonate more deeply with customers. They need to know that if they make some dramatic changes in how the team goes about building products, that those changes will be rewarded and not punished, even if results are not obvious right away. Without hearing a strong message from their management, and without support and encouragement from key players on their team, middle managers are incented to keep up the status quo and not make any real changes. It’s essential to ensure visible buy-in and support from higher-level leaders.

Active buy-in It’s not enough for high-level leaders to buy in and dictate that the team should adopt these ideas; team managers need to buy in as well. We began to require a preworkshop session with each team’s set of group managers at which we presented the high-level concepts of the workshop and what would be required of them to make changes successfully. At the end of this session we asked them to make an informed go/no-go decision regarding the rollout of the workshop to their team. These manager meetings became a critical part of the rollout of the team workshop because they gave managers time to think about the concepts and make a conscious, active decision to move forward (or not). In fact, we learned this lesson so strongly that we refused to schedule a workshop for a team until we had a preworkshop meeting, the middle managers had actually shown up, and they agreed to support and participate in the workshop with their teams. Further, we made it a practice during the workshop to have one of these managers stand up about 45 minutes into the workshop and explain to the team why they have asked everyone to spend their valuable time with us on that day. (Why not have the managers kick-off the workshop? Because as many as 20 percent of attendees arrive a few minutes late, and it is much more important that everyone hear from their manager than from us.)

Support them with champions Passionate champions were important in helping managers continue to see the value and need for change. These champions were typically highly respected individual contributors (perhaps an architect, a strong program manager, or a particularly influential developer). We supported these champions closely, and through these relationships we saw a healthy tension between the risk-averse middle managers, who were faced with executing change, and the optimistic influencers, who were able to rally the team around the value of customer-focused iteration and figure out how to make process changes happen.

Harness champions as change agents

Even when leadership support wasn’t crystal clear, passionate champions were a powerful force for change. Almost all teams had champions with fire in their belly that deeply believed in customer-focused iteration and were driven to do whatever it took to get their team using these tools. Sometimes they were experts in some aspect of the process or a specific technique, but often they were just passionate people with a bent toward being change agents, eager to learn and figure it out on the fly.

Champions are needed to figure out the pragmatic steps for adoption: which techniques should be used by the team, what’s mandatory and what’s optional, and what are the implications for team systems such as schedules, tools, and processes. For this reason, we sometimes call these champions operationalizers, because they take charge of figuring out the practical details of how to operationalize Scenario-Focused Engineering on their teams.

The champion role is ideally served by an individual who is senior enough to have the trust and respect of top leaders and with sufficient authority to make decisions stick. Yet, they also need to be close enough to team members doing the work to understand the realities of day-to-day activities. They act as a critical liaison, translating the desires of leadership into an actionable plan for the rest of the team. They might have a formal leadership role, such as a lead or a manager on the team, or they may be an individual contributor who acts as a thought leader.

Often, champions provide the impetus that encourages top-level leaders to continue talking about customer-focused iteration after the workshop. They feed them key ideas to reinforce with the team as they see needs arise in their interactions with the team. Champions are particularly effective when they have a close relationship with their leaders and are also often pivotal in helping a team decide to sign up for the workshop in the first place. The best champions have a touch of salesperson in them—a dynamic personality that’s fearless—as well as patience and a willingness to keep working with reluctant individuals or skeptics until they come around.

On some teams, this role is served by a single individual. On other teams, usually larger organizations, a group of people work collaboratively to coordinate and encourage changes across different parts of the team. Either way, these folks are essential for understanding the specifics of adopting this approach, for adapting it to their team, for helping explain these ideas in detail to all the members of the team, and for beating the drum to keep communication going and to keep people moving.

We’ve found that every organization already has change agents who are ready to go above and beyond for a cause they believe in. They fall into a few different categories. First, not all of them have the authority or depth of experience needed to be successful in their ambitions; these people are most effective when they are paired with a more senior person and can act as a powerful duo. Some have a lot of motivation but not a ton of direct experience with these new techniques, so while their learning curve is steep, their passion usually makes up for this, and they are still quite effective.

Some teams have passionate change agents in place who have been attempting to stimulate similar changes for years or are already deep believers in the tenets of a customer-focused, iterative approach. Some of these people have successfully gathered an enclave of like-minded individuals and are the thought leaders behind enormously successful teams or subteams, sometimes opting to fly under the radar or who call their approach the team’s secret sauce. Other times these change agents have been frustrated, knowing what the team should be doing, but finding their attempts to influence reduced to tilting at windmills, feeling powerless to affect the depth of change they know is needed. Either way, these individuals are critical to identify and harness if broad, team-wide adoption of these ideas is to be successful.

In particular, we’ve learned that it is essential to identify these people when we first start working with a team and to bring them into the conversation early. After all, they have already been down this road and have experience on this specific team about which approaches work and which don’t, what the roadblocks might be, and all of the intricacies of the team’s existing culture, processes, and tools.

We learned this lesson the hard way. One of the first large organizations we worked with started by bringing its entire executive leadership team through a full workshop. They liked what they experienced and then asked us to start bringing their individual engineering teams through workshops. From our perspective, this seemed like a great start, with strong leadership support leading the way.

But from the perspective of the change agents already on the teams, this didn’t look rosy at all. Think about it from the perspective of a person who has already been independently driving a very similar agenda. They start asking themselves, “Doesn’t our leadership know that we’ve already been pushing these ideas for years? Is this a not-so-subtle hint that we’ve been doing it wrong? Or is this confirmation that we’re just not very effective? Why didn’t they ask us to lead this training instead? We know just as much, more in some cases, than these people they’re bringing in.”

Sure enough, many of the existing change agents became upset and angry, and some even started campaigning against the need for training or for team change. But once they attended the workshop, the majority realized that we were all aiming at the same goal, although they still had some pretty ruffled feathers. And these were the people who should have been the strongest supporters and the biggest assets on the team for figuring out how to put these ideas into practice on a team-wide scale. Yipes!

This lesson deeply informed our engagements with future teams. We’ve made sure that we always identify and include a team’s natural champions from the beginning so that they fully buy in and can help direct and focus the change process for the team. Champions have ended up being instrumental in customizing the customer data used in the workshop as well as contributing and fine-tuning the workshop topics. Several were invited to serve as coaches during the training day itself to help answer questions in a visible leadership role. All of this adds up to making the training day that much more effective for a team. But, more important, it harnesses the passion and motivation of change agents to become visible, empowered champions for driving change throughout the team in the weeks and months afterward.

There is a limit to what champions can do on their own, however. When big conflicts come up—perhaps a more significant schedule change is proposed, or a long-standing process needs to be adjusted, or the need for a well-articulated target customer is questioned—sometimes even the most passionate champions hit the wall in what they are able to accomplish. As we discussed earlier, without visible, sustained support from top leadership, teams become confused about whether making the shift to customer-focused iteration is still a priority, especially as people begin to realize the more challenging implications of what needs to change.

You can’t grow a foot overnight

We’ve developed a deep appreciation for how long it takes to shift behaviors, team culture, tools, systems, and institutionalized ideas about how to get things done. We’ve known from the beginning that this was going to be a long journey for teams we’ve worked with, but we have been surprised at the depth of the implications that stem from implementing these seemingly straightforward ideas and how long it takes to build these skills and mindsets on a team. Leaders and managers consistently underestimate what it takes to start working this way.

Early on, we noticed that many teams had unrealistic expectations about how much change would occur, how long the change would take, and how quickly they would see results in the quality of the products they shipped. The more passionate champions tended to downplay the magnitude of change needed and to be bullish about the team’s ability to snap to a new way of doing things.

Looking back, as we’ve watched teams go through this transition, they’ve grown a lot more slowly than they (or we) expected. We’ve learned and observed that old habits die hard and that change takes a lot of work and sustained effort. Teams hoped to be proficient and comfortable with these new techniques by the time they started their next release cycle, but the reality is that several major release cycles were needed to make enough of the transition that the teams began to see clear results from this new way of working.

Appendix A details a list of the 10 most important capabilities we’ve identified as being central to adopting Scenario-Focused Engineering. We didn’t see any team become good at all 10 capabilities at once—most teams followed a path through a set of stages.