CHAPTER 5

Master “No”

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are.

—Steve Jobs

Luis was knee-deep in a transformation, and his patience was being tested.

The scene was Lonely Planet. For decades, the company has been one of the most celebrated brands in the travel business. Yet, in mid-2018, they were struggling internally.

For the previous few years, their very creative-minded CEO had run amuck, percolating new product ideas every week. Projects were not making any progress, because newer, cooler ideas would get more traction. Staff were exhausted from being pulled around in so many directions, and the bottom line was not looking good. Eventually, the firm’s billionaire owner had had enough. He removed the CEO and asked digital strategy consultant Luis Cabrera to assess the situation and introduce some stability.

As Luis started his discovery, the issues started piling on: managers complained they were paid less than their staff; the org chart had enough layers to rival large bureaucracies; leaders were jockeying for the empty slot at the top; the technologies in place limited innovation; the team practices were inconsistent and unstructured. The sheer volume was daunting. Jobs were at stake. And you have a billionaire watching your next move. The pressure was on. What do you do?

One thing was clear: he could not repeat the same fragmented, frantic approach of the previous leadership. He would not do everything at once. For many of the fixes that were needed, he would have to offer a short-term “No, not now.”

Paradoxically, to get everything done, he would have to resist the pressure to do everything. And it worked. Here’s why.

The Problem with Progress

In this chapter, we look at another reason why your transformation is stuck: the overcommitted workload. Here’s how it happens:

• The Boost. Yes, you seized all the right opportunities.

• The Barrier. And yet, you’re always behind on deadlines and expectations.

• The Rebound. So now, master how to say no.

The Pattern of Untapped Progress

The Boost: Yes, You Seized All the Right Opportunities

Success comes from bold moves. It’s good practice. Whether it’s internal influence, more features, or more products, nobody gets ahead by resting on their butts. You’re either moving or not moving.

Leaders Seize Opportunities

The Barrier: And Yet, You’re Always Behind on Deadlines and Expectations

Oddly, the more aggressive we are, the more dates we slip, the more our sponsors complain, the more work we have to do. The more we do, the more we’re behind.

Leaders Struggle with Limited Progress

The Rebound: So Now, Master How to Say No

The problem is you’re overcommitted. Period. The solution is focus. To get to the destination sooner, start saying no to all those detours and distractions.

We need to build everything on the radar, faster than reasonable. To do that, we need to be completely digital, lean, and agile. By yesterday. For that to happen, we need everyone to rise to the challenge.

To solve this dynamic, we need to move forward at the pace that matches who we are as an organization. That requires we learn how to say no to the three great sources of overcommitment:

• Say no to delivering everything. There is never a shortage of work to do. But the more work we do at once, the less capacity we have to transform the work itself. Reducing the daily load allows for more improvement.

• Say no to transforming everything. Some parts of the business need to be transformed first, but other parts can wait until later. Hold off changing too much at once.

• Say no to you in everything. High achievers see more opportunities than most and feel compelled to go after them. Knowing your tendencies and habits better can help in managing the personal backlog.

Master How to Say “No”

Say No to Delivering Everything

Executives are held to more performance goals each year. Sponsors are funding more projects. Competitors are disrupting our offerings. There’s a ton of work to do and never enough money, people, or time to do it.

Then isn’t it great we have agility? We live in the most innovative age of mankind. Shouldn’t we be able to “do more with less”?

Well, that certainly fits the narrative. The State of Agile Report says practitioners are more likely than not to increase productivity (61 percent) and increase speed (63 percent).¹ Indeed, the most recent State of DevOps Report² says that, relative to the lowest performing digital organizations, the highest performing organizations deploy completed work to operations 106 times faster and recover from mistakes 2,604 times faster. The best-selling book on the Scrum framework explains how to get “twice the work in half the time.”³

The expectation is this: agility means get more done faster.

Meanwhile, everyone’s already busy. How do we build the airplane as we fly it? It turns into a crazy cycle where we eventually throw up our hands in despair and shout, “We are too busy doing work to get better at the work we do!” So the answer is to move in the opposite direction.

Kill More Projects

Of all the role model companies we look up to, Google sits on the throne of the digital kingdom. From YouTube to Gmail to Chrome to Android to Google Maps to Google Drive, they have number-one market share in half a dozen Internet products. Oh, yeah, and then there’s that search thing too.

And yet, Google is also a graveyard of dead products. There were some that were around for years, such as Google Glass, Hangouts, and the Google Search Appliance. But for each of those almost-wins, there are several that did not last very long at all. KilledByGoogle.com is a fascinating website that lists products and services that are no longer offered or supported. The list includes such obscure gems as these:

• Dragonfly was going to fix search for Chinese censorship rules (lasted one year).

• Needlebase was a point-and-click Internet content organizer (lasted one year).

• NOOP was a programming language blending old world and new world computing (lasted three years).

• Buzz was a social media plug-in for Gmail (lasted two years).

• Writely was a web-based word processor (lasted one year).

The website goes on to detail almost 200 failed products. But how is that possible? How could a company be so successful when so many of their products fail? Because those products are killed before too much money is spent on them. They realize what techpreneur and creator of Innovation Games Luke Hohmann explains, “You don’t have insufficient resources, you simply have an overabundance of good ideas.”⁴

First, we already have too much going at once. To trim the fat and get more efficient, we need to master artillery. In their book Great by Choice,⁵ business authors Jim Collins and Morten T. Hansen explore how businesses succeeded during the Great Recession. One key technique: “Tracer bullets. Then cannonballs.” Go small to find out where to go. Then go big to get there.

• Stage 1 (Ideation). In every organization, managers mobilize projects to achieve their annual goals. But what if we dispensed with those annual goals and instead considered all those projects merely potential ideas. What if we treated all ideas as initially equal in their unvalidated state, and allow them to compete for funding based solely on their merit. Let’s say we collect 100 potential projects or products to invest in.

• Stage 2 (Exploration). For each idea, we invest a minimal amount of labor to seek data to confirm whether it has potential. Is there truly a need? Do we give it another round of funding? We use those first “tracer bullets” to see what lands where. Common sense tells us that of those 100 investments, maybe half will ever get around to running those tests.

• Stage 3 (Validation). With 50 sets of data, we can rack and stack which ones have promise. Then we can choose the top 25 candidates to see whether we can generate value at a larger scale. Can we have validate the business case? Is this the value we want, relative to our long-term vision? We narrow our aim and fire more targeted tracer bullets.

• Stage 4 (Exploitation). Eventually, we come to the survival of the top 2 or 5 or 10 fittest ideas. Now is when we switch from small bullet-sized experiments to firing the cannonball-sized investment.

Metered Funding Enables Lean Portfolios

This same concept is formalized in the Lean Startup method as metered funding.⁶ This is in contrast to the more common corporate tradition of entitlement funding. Traditionally, we fund every project and do them all at once. You get 5 million, you get 5 million, you get 5 million, and you get 5 million. All good? Call me back next year for your next round. Then we are shocked to discover that we need a lot of people to fire a cannonball, and we only have so many people. Moreover, all our best talent is needed on all those cannonballs.

Instead, we can use metered funding, which is doled out only to those projects that have proven their worth through several smaller experiments. All the other lower-value ideas, which would have normally been approved, are thrown by the wayside. This kind of organizational focus means more resources, more focus, more speed, more performance, more, more, more … all by doing fewer projects at once. You run this process continuously throughout the year, rather than a rigid annual cycle.

Hohmann offers another insight into high-performing organizations: “You can measure the maturity of your portfolio management by your project kill rate.”

This is how Google achieves its organizational focus.⁷ With the focus in play, it can run all kinds of transformational experiments, such as:

• Simplifying a quarterly 41-point employee performance management system down to a leaner 5-point system every six months, saving tons of overhead.

• Adopting a provocative “pay unfairly” compensation model that retains their highest performers.

• Installing employee amenities that keep them happy and focused, ranging from onsite bike repairs to mobile haircuts to Take Your Parents to Work Day.

Consider that if Google staff were still supporting those 200 dead projects, they would be running so ragged they wouldn’t be able to adopt or enjoy the transformations that make Google such a competitive place to work.

Kill more projects. Spend less money. You’ll get things done faster, and you’ll create room for teams for support the transformation you’re striving for.

Say No to Transforming Everything

Transformation initiatives fail to achieve their goals for one of two reasons:

• We didn’t go far enough. Our change needed to be safe and nonthreatening, so it was limited to pilots, which yielded only short-term results. We addressed that in chapter 3, “Give It Away.”

• We burned out. Our change needed to be fast and all-encompassing, so it was expanded prematurely to cover everything, which caused confusion, frustration, and cancellation. This is what we want to talk about here.

Organizational change is hard. Too much of it at once merely makes it harder. Here’s how to limit the change.

Ration Your Ambition

Here’s one I hear often. A leader catches the transformation fever and declares, “By the end of the year, we are going to be 100 percent digital, 100 percent agile, 100 percent lean. Every project, every department, every service.” It’s bold. Ambitious. Future-oriented.

And it’s a bad idea.

In 2012, Bansi Nagji and Geoff Tuff introduced the innovation ambition model, which differentiates three distinct regions: core, adjacent, and transformational.

• Core. You have your core business. You’re optimizing existing offerings for existing consumers. This is where you know what you know, you know how to win, and you know where to play.

• Adjacent. Meanwhile, there are a handful of true innovations, which add incremental products and offerings to adjacent customers. These carry a few more assumptions and are a little bit more ambitious.

• Transformational. Then there’s further out from your core, where you kind of don’t know how to win and you don’t know where to play. It’s a new place, it’s a different thing. And that’s where your approach should be a lot more agile.

That’s right, ladies and gentlemen; agility is not for everything. In fact, Nagji and Tuff’s research found higher-performing companies (as measured by stock price) carried a recurring pattern: the portfolio should be 70 percent on your core products and your core business, 20 percent on adjacent, and 10 percent on transformation. The further out you are into crazy land, with new ventures and new spaces, the more innovative you need to be, the more risk you have financially. Conversely, the more stable and reliable your products, the less effective those innovation methods are.

Put another way, if only three out of ten products or programs are using Scrum/DevOps/Kanban methods, then you’re following research-based innovation guidelines. Only 30 percent of your portfolio needs transformation.

Then I get the transformation purists rebutting: “Um, just because the outer regions incur more uncertainty doesn’t mean the Core is off the hook! They also need a more digital, collaborative, adaptive way of working, even if just to consume new innovations.” Fair enough. I will concede that general business agility is a new competitive necessity. But that does not mean the same full-scale transformation is worth the cost in every part of an organization. Context matters. Which leads us to a difficult question: When is agility worth it and when is it inappropriate? And how do we decide?

Agility Requires Investment

If you want the quick answer, here it is: Use agile/digital/innovation methods only when it’s worth the investment. Agility is not for free. If you want to play, you have to pay the admission fee. Here’s what that looks like:

• Collaboration. The Scaled Agile Framework is the most popular textbook model for organizational agility.⁸ It’s fundamentally designed to focus dozens or hundreds of employees around medium-term goals. To achieve that focus, the framework prescribes a ten-week cycle that consists of several collaboration events, ranging from fifteen-minute daily stand-ups all the way up to a two-day all-hands workshop. When you add it up, individual contributors spend a recommended average of 15 percent of their time in formally scheduled meetings.⁹ That makes sense for large interrelated efforts that require continuous communication. But working on more smaller independent initiatives may not need that much.

• Rework. Building prototypes for customer feedback creates a stronger product with more alignment to market needs. It also invites adjustments and additions to the workload. That rework is a necessary part of the exploration of new customers and products, but it may not be needed for work that is already well known.

• Allocation. Most thought leaders recommend increasing productivity, quality, and morale by fully allocating each team member 100 percent to a single team working on a single stream of work. However, what is the likelihood that this month’s highest priorities will 100 percent align to each and every staffer’s skill availability? Zero. That means every month there is at least some idle time. In theory, a little slack in workload for one or two people allows them to assist on other team activities, boosting teamwork and knowledge sharing. However, it may be hard to justify that intermittent idle time for every skill set on every project everywhere in the company.

All that work and time represent investment. Should we be investing that much in our transformational initiatives? Yes! Otherwise, we incur risk that undermines the entire venture. On the other hand, is that investment worth applying to operational, everyday, run-of-the-mill, no-surprises work in the core region? I doubt it. Rather, it makes the most sense to focus your transformational energies on your transformational regions.

Don’t Ask Whether Agility, Ask How Much

Now that we know to focus our transformational energies to only some of the organization, we can make progress on evolving just those programs and products.

But isn’t that inconsistent and confusing? How can we simultaneously have agility here, but not there? What kind of organization do we design to support multiple operating systems?

The Either-Or Approach

In recent years, the innovation-ambition matrix has been further elaborated by Gartner’s bimodal framework for IT organizations.¹⁰ It recommends the organization be governed by two exclusive management systems. Mode 1 is the marathon runner. It matches the core region in our innovation-ambition matrix, and optimizes management for areas that are more predictable and well understood. Mode 2 is the sprinter. It matches the adjacent and transformational regions. It’s exploratory, experimenting to solve new problems and optimized for areas of uncertainty.

It’s a logical construct, except it creates lots of problems. An article in CIO magazine highlights a few of them:¹¹

• The false free pass. When leaders designate work streams as core/traditional/model, many interpret that as a waiver on having to do any improvement at all. Although collaborative team building, retrospectives, and strict priorities are associated with agility, those outcomes could have benefits everywhere.

• Two options isn’t enough. Meanwhile, advocating a dual operating system directly implies a limit of two ways of working. Either all mode 1 projects are done exactly this way or all mode 2 projects are done exactly that way. This encourages a monolithic use of a given approach, without adjusting any elements to specific situations.

• Mode 2, right now. And if all our fast projects are to be run the same way, then it generates undue pressure to transform all those teams right away. Otherwise we can’t support all the projects moving into that category.

• Dependencies. Meanwhile, a fast-slow division of the organization ignores the reality that many fast projects are dependent on slow projects, offering little guidance on how to reconcile that tension.

• Team division. Breaking up the organization into two modes creates an us-versus-them culture. The slow teams are envious of the cool stuff the others get to do, and the fast teams look down on the others for doing things the old way.

And so on, and so on. The either-or mindset is a recipe for headaches. Fortunately, there’s another way.

The Hybrid Approach

Change is rarely instantaneous. It is more than just before and after. It evolves over time. For every person who quit smoking cold-turkey, there are plenty of others who have to cut down a little at a time. For every person who learns to ride a bicycle in a single lesson, there are those who wobble forward—walking, then peddling, then walking again before ultimately settling into a groove.

When scaling change beyond a single person to an organizational scale, the awkward, ugly in-between state becomes a universal pattern. That state of practice is referred to as hybrid.

In 2017, I served on the team that wrote and published the Agile Practice Guide,¹² a collaboration between the Project Management Institute and Agile Alliance. For the first time ever, both associations offered concrete guidance on hybrid approaches. Rather than divide the organization into bimodal’s opposing mode 1 (predictive) and mode 2 (agile), it introduces four general patterns:

• Pure agile, then pure predictive. Designing a skyscraper is a very iterative design effort. Many conversations lead to many sketches and models. But once we break ground, it becomes a very strict affair. Building the building is not, and should not be, as flexible as designing it was.

• Combined agile and predictive. For the annual release of the new smartphone model, we all know there’s a lot of fancy graphics, sounds, and whiz-bang software that need an agile approach. However, during the whole year, there is a rather predictive supply chain project running in parallel, ensuring the thing can get built over and over.

• Mostly predictive, with some agile. A corporate training initiative will likely follow a pretty reliable life cycle, defined by the Association for Talent Development. We start with analysis of the needs, design, and develop the curriculum. Then we deliver the program to a pilot audience and iterate on the program with their feedback, after which we roll it out at scale.

• Mostly agile, with some predictive. Finally, we love our websites. Those are the most obvious agile projects, with lots of opinions on fonts, colors, text, and menus. Except for when it’s time to move it into a predictively minded data center, who wants an infrastructure request well in advance.

Embracing the transitional hybrid reality reduces the burden to “get agility right.” Moreover, many of these in-between combinations represent an approach that better aligns to the realities of a given product or service.

Bottom line? Don’t ask “whether” agility. Ask “how much” agility. Don’t ask whether a given project, department, or business unit should pursue agility. Instead, asking “how much” makes more sense.

Say No to You in Everything

The lamentations of the average project manager usually sound like this:

As a project manager, I am the face of the project, which means I have to attend meetings with stakeholders and customers for most of the week, getting the fullest possible understanding of the goals and constraints we’re working with. When I’m not in meetings, I check the specifications my team produces, because they often contain assumptions and vague statements that need to be clarified. Meanwhile, since I was assigned to this role based on my technical seniority, it’s my responsibility to review the work items the team produces, which are generally okay, but not as good as they need to be. I stay late to correct whatever feedback my team gets from the compliance reports, which are often unfair and misdirected. Weekends are when I schedule all the meetings, catch up on emails, and type up reports. I’m working sixty hours a week, and I know I’m pulled in a lot of directions. But that’s what it means to be a leader. Right?

The Afflictions

Sound familiar? This is the struggle with getting ahead in our careers: we gain more sphere of influence, more responsibility, more expectations. What was an exciting step forward becomes another and another, until it becomes exhausting, overwhelming, and painful. Here’s how you got yourself into this.

Got Hero Syndrome?

Do you ever wish you could be cloned? There’s so much work for you to do, and you’re the best one to do that work. On the one hand, you’re the thought leader that everyone comes to for decisions, perspectives, input, and expertise. On the other hand, you’ve become the bottleneck for both the organization’s delivery and its growth.

This is often referred to as “hero syndrome.” It’s the belief that your value is based on being the center of gravity. If you don’t do it, it won’t get done right.

To scale your impact as a leader, you need to scale your capacity beyond your physical boundaries. This means leveraging more of your team. Which means shedding things that are beneath your role—less doing, more delegating. Which means investing more in building capacity in others to take on those tasks.

Got FOMO?

Have you noticed that you spend most of every day of every week in meetings? Don’t worry, it’s a common affliction. But what if I were to tell you that you didn’t have to? If I were to challenge your involvement in so many things, what would your response be? Well, if you’re honest with yourself, your response might sound like manager Maria:

Does this sound like someone you know?

This mindset is referred to as FOMO—fear of missing out. It’s natural to want to be involved in as many things as possible. Knowledge is power, and the more knowledge leaders have, the better decisions they can make. Except we can’t be everywhere. Moreover, the work we do today is becoming more and more complex, to the point where all the ins and outs simply can’t fit into one person’s mind. Just like with hero syndrome, you become the bottleneck.

The Prescription

Your teams need your support more than they need your output. You need an antidote. Here are some techniques to try to overcome your workload affliction.

The Personal Backlog

Maria has an overwhelming workload of transformation activities. She’s held accountable for results, but several peers and stakeholders have opinions. So, like most good managers, she organizes it all into a sorted backlog like the one shown in the figure.

Maria’s Personal Backlog

This is a simple technique that’s been formalized countless times by countless books over the years. From the Franklin Planner to Getting Things Done to the Bullet Journal, the principle is the same: effective self-leadership starts with “write it down.”

It doesn’t matter which personal productivity system you use, just use one. But it doesn’t end there.

The Must/Want Filter

Yes, a personal backlog provides helpful clarity. But if you’re an overachiever like me, failing to do the stuff on the lower end of the list is still very agitating. Missing the project Y boot camp makes me feel guilty, because the sponsor really wants me there. Missing the project X redo is frustrating, because I hate low-quality work. How do I move forward without the fear, uncertainty, and doubt that I’m going to be forever behind?

Several years ago I was wrestling with some family issues and sought out a family therapist to offer some perspective. He explained, “All of life’s decisions can be boiled down into three emotional categories: Must Do’s, Want To’s, and Should Do’s. And it’s the Should Do’s that are the source of all regret, pain, bitterness, and unfulfillment.”

He went on to elaborate:

• Must Do’s are the things that we choose to do because they align with a deeper definition, a larger vision of who we are as a human. We choose them, even if we don’t want to, because we are compelled to. This is going to your brother’s wedding even though that weekend is the same as a major work deadline.

• Want To’s are the things that we choose to do because they fill us, energize us, and give joy. We choose them because we believe we are worth it, even if it means something else doesn’t happen. This is going to the ball game with your friends Tuesday night, even if it means that status report is a few hours late tomorrow afternoon.

• Should Do’s are the things that we submit to doing because we think we’re supposed to. Not doing them would incur the disappointment of other people, making you feel guilty and embarrassed. These are things that are simultaneously annoying and unfulfilling. This is jumping on every phone call because that’s what’s expected of your role, even though you’ll be catching up on email the whole time.

The distinction is between things we choose to do for personal fulfillment or greater purpose versus the things we submit to doing out of guilt or fear. The therapist further explained, “Anything on your list that you can’t put into a Must Do or a Want To is a Should Do that will suck your soul. Kill it. Remove it from your list with the confidence of knowing it serves neither a greater purpose nor a personal goal.”

Therefore, Maria might rearrange that backlog to something like the figure shown.

Maria’s More Focused Backlog

After some reflection, she realized her primary value right now is offering answers about new ways of working. That places a priority on training new pilots (Project Y) and staying a step ahead of everyone’s maturity (advanced agility course). Meanwhile, the pressure to take over chartering is a Should Do, because that activity isn’t impacted by the transformation yet. Moreover, updates will have to wait (quarterly newsletter) until there’s something to report for successful pilots (Project X). Finally, Maria discovers in herself a need for peer support in order to stay strong under these pressures. That Community of Practice was originally just a good change management idea, but now feels like a deeper personal need.

This new list limits the change to the most critical items for right now. This feels right.

Offer a Crap Sandwich

Now that you’ve discovered your personal priorities and boundaries, it’s time to enforce them in a way that gives credibility, rather than criticism.

One of the most helpful leadership tools I’ve come across is William Ury’s “positive no.”¹³ In his book, he spells out a concrete process for saying no in a constructive, diplomatic fashion. Here’s how it works:

1. Say yes! Acknowledge the value of the request.

2. Say no. Explain what you can’t do and why, without apology.

3. Say yes? Offer meaningful alternatives to the request.

Let’s see how team lead Ted turns a no into a positive, credibility-building response, when he’s under a personal deadline.

This follows a similar pattern for offering critical feedback sandwiched between two compliments. My wife refers to these patterns as the “love sandwich.” I thought that was a great analogy until I shared it with a colleague named Steve who burst my bubble: “Actually, Jesse, that’s not how it works. A chicken sandwich has chicken in the middle; a cheese sandwich has cheese in the middle. We label sandwiches by what’s in the middle. So it’s not a love sandwich you’re offering. It’s a crap sandwich.”

So be it. To save my relationships, to be true to myself, to improve my performance in life, I offer the universe my crap sandwich. Just don’t tell Ury that’s what we’re calling it.

Lonely Planet’s New World

After some initial discovery, Luis started compiling a transformation backlog that looked very similar to those from his previous ventures.

• Restructure lines of reporting

• Refactor existing technical debt

• Overhaul employee compensation model

• Resolve the print-versus-digital issues

• Craft a new vision around the right market positioning

• Consolidate the diverse technology footprint

• Install modern innovation practices

• Find a new senior executive

• Install analytics to aid with product decisions

• Improve revenue strategy for existing digital products

And so on and so on. Like all of us in the change business, he was confronted with the question of where to begin. After talking through the options with the team, he settled on a strategy: do what we can while we wait for what we need.

Yes, the longer-term health of any organization comes from a clear, coherent vision, a true north. Yes, they needed a new senior executive. Yes, they needed to modernize the technology base. But all those things would take time to realize. Instead, there were other things that could be done right away. While those longer-term initiatives were being formulated, they started on several cleanup activities that would need to get done regardless of where the eventual vision would take them.

• The teams were formed into pods that featured product, engineering, and quality skill sets.

• Pods were formed around workstreams to address known gaps around analytics, search, and other technical debt.

• DevOps concepts like automated testing were prototyped on each of the pods.

• Meanwhile, research was started on the bigger-picture items.

The ownership was pleased to see a logical plan and some initial momentum. But the bigger organizational changes weren’t happening fast enough for some of the senior staff, and they started complaining even more than before: “We’ve had such challenging leadership, how can we trust you? There’s been so much change in the past, when do we get to the new org structure? How can we do good work before we solve the vision, the technology, the headcount?”

At this point, it would have been easy to be distracted by the criticisms of tenured managers who threatened to leave. Luis listened patiently to their emotions, but reiterated the strategy: “Yes, I agree these are challenges that need to be fixed. And we will get to them. But we’ll focus first on the low-hanging fruit right now.”

His stance kept most of the team on board, but not everyone. When the new digital product chief was selected from another department, two more resignations came in. In hindsight, everyone agrees that new leader was the right choice. But the baggage of the previous years was just too much for some people to carry through into yet another administration.

Luis held firm to transforming one small step at a time, and it started working. By the end of the following year, the new technology platform was in place. Agile team practices are the norm. Revenue is up. There is a breath of fresh air in the office. And Luis was even invited to accept a role as the president and CEO of the company.

Yes, it was painful. Yes, there were plenty of people unhappy with the transformation choices, and the pace of the transformation. But going slowly enabled more stability, and ensuring the cultural health of a decades-old company. That is no small feat. Luis’s secret was focusing on less work at once. You can use the same secret. Overcome your workload by become a master of no.

Summary

In this chapter, we’ve explored the problem of workload. By exploiting every opportunity that comes our way, we’ve fallen behind on most of them. To regain our sanity, we’ve learned :

• Say no to more delivery. There will always be more work to do. Successful organizations make tough choices as to which projects deserve funding and how much. To get those done faster, you can build a systematic process of killing more of the lower priority projects.

• Say no to more agility. No, we should not go wholly agile/digital/lean overnight. Rather, strategic leaders assess where agility is needed the most and focus organizational resources there first.

• Say no to yourself. Our personal overcommitment stems from our perception of leadership as solving all the problems (hero syndrome) or participating in all conversations (fear of missing out). High-performing leaders take the time to run a mental audit on their personal backlog and make choices with intent.

It’s time for you to switch from playing catch-up to playing in front. Doing that means mastering how to say no to everything slowing you down.