How much can we achieve? Leadership isn’t enough

It’s that time of year again: most companies are pushing hard to close the final quarter of the fiscal year while simultaneously planning the budget and strategic objectives for next year. Depending on the type, size, and maturity of your business, this exercise could include anything from a rigorous, zero-based, quantitative analysis of global operations to a white board session over a beer. Or maybe not: Basecamp doesn’t plan more than six weeks ahead. Most likely, your experience involves too many revisions of painfully formatted spreadsheets that will be forgotten in a few months when the reality of daily business sets in.

Regardless of the mechanics of your planning process, the fundamental question is: how much can we achieve?

In many organizations, the answer to this question starts and ends with leadership. But when growth requires broad adoption of new systems, behavior change by the end users of these systems matters as much as, or more than, leadership capacity. Let’s look at why this matters, and what you can do differently in this year’s planning cycle to incorporate the concept.

Leaders think leadership is important. Whether it’s self-preservation or cognitive bias, many leadership teams will over-weight their role in driving change. I’m not endorsing the leaderless organization fad, and I believe it’s essential to sanity-check the number of strategic objectives and special projects assigned to each leader (in addition to his or her “business as usual” responsibilities) when building an annual plan. Even an Agile approach to program and project management, with more frequent interrogation of outcomes, risks, and blockers, can leave leaders overwhelmed. When a single leader is overloaded, delays and dependencies can put an entire program at risk. When the organization is capable of a high rate of change without enough effective leadership capacity, employees feel disengaged and top talent starts to look elsewhere. So if we’ve established that leadership capacity matters, why isn’t that enough?

Sustained improvement happens when a new, better thing happens more often than the previous, worse thing. Even in highly technical, capital-intensive industries, measurable changes in performance only occur with adoption of new solutions. Software teams can ship new features, and if users don’t adopt those features, the users don’t realize the benefits, no matter how many times in a row you say the word “done.” Managers can train teams on new procedures, and if those employees don’t perform their work differently, the same defects, inefficiencies–even accidents–will persist. Marketing teams can crank out more content, and if sellers don’t change the way they engage with buyers…you get it.

Therefore, in addition to a “top down” assessment of leadership capacity across projects, take a “bottom up” view of behavior changes during your annual planning cycle. Look across your portfolio of projects: which roles, or individuals, in the organization will have to sustain behavior change for the projects to succeed? Are we asking too much of the same people?

Here’s a hypothetical example from a fictional software company:

  • HR leadership plans to change the performance management process, using a new online tool
  • Marketing leadership plans to change the content management system, including how inbound leads are routed to Sales
  • Operations leadership plans to change the quote to cash process, including a new set of contract templates
  • Sales leadership plans to change the compensation structure, with different payouts for new logos vs account expansion
  • Product leadership plans to introduce a new self-service subscription feature as part of the next major release

From a top down view this set of projects will require cross-functional coordination, however, no single leader will be overloaded with responsibilities. Great, all set, let’s get started–right? A bottom up view of the behavior changes required for these projects to generate results, however, reveals that Sales Managers will be overwhelmed by requests from different project leaders to work differently. It is much better to identify this risk during the planning cycle than in the mid-year review, when each project leader is scrambling to understand–or worse, to blame the Sales Managers–why they are not hitting their numbers.

Leadership matters. But without behavior change that fuels adoption, results don’t stick. Try this approach in your annual planning cycle to see if it generates a greater rate of improvement–and leave a comment below with any questions or feedback.

The Myth of Unintended Consequences

A quote that rings in my ears from time to time, especially when I get caught out in the rain, is: “There is no such thing as bad weather — only a poor choice of clothes.” I’m not certain where I heard it first but I’m going to attribute it to my colleague Taylor’s mother.

In business, politics, or our personal lives we often hear much hand-wringing and excuse-making about unintended consequences. Today I offer you a more pragmatic view: “There are no such things as unintended consequences — only a poor choice of solutions.” After looking at a couple examples, I’ll suggest how you can help your team avoid unintended consequences by:

  • developing a more robust understanding of the problem and the system that governs whether the problem occurs
  • executing effective trial solutions, and then leading change effectively at full-scale

Recently, a few examples of unintended consequences in the news have reminded me of other historical examples. Copenhagen is trying to get more of its residents to commute using bicycles. At the same time, concerned advocacy groups also started promoting bicycle safety through helmet use. What happened? Ridership dropped. Let’s look quickly at a few more examples for reference:

As leaders, we all understand that the future is uncertain and “the ideal time to make a decision is never” (see diagram).

The ideal time to make a decision is … never. Increase your certainty in decision making by steepening your team’s learning curve with a structured approach.

Over time, we gain more and more information about the system and can be more certain. The slope of this curve depends on the method we use to understand the system — and sadly many teams rely on nothing more than brainstorming. For more about using a structured approach to understand a system quickly, read my previous post challenging the effectiveness of “5 Whys.”

When it comes trialing solutions and then managing change, there are countless “proven models” to follow. Two resources I can recommend are:

  1. John Kotter’s Leading Change — straightforward and timeless
  2. The Build Network has concise, informative articles targeting senior leaders in rapidly growing business. One example is about mapping a business model before you improve it.

Do you believe in unintended consequences? have you busted the myth? Leave a comment!