Emile Kfouri: With Great Change Comes Great Opportunity

Introduction

As they say, the only constant in life is change — and that has certainly been true for the 12+ years that I've been at Autodesk. Each change brings an opportunity for rebirth, which makes it critically important to know what to hold on to, and what to let go of. Over the past six months, in this latest season of change, our new CEO, Andrew Anagnost, has given us a great roadmap of where we want to go, and what we need to do to get there, without being overly prescriptive.

With that context in mind, I'd like to share some of my thinking about turning change and transformation into opportunity, specifically by using the Agile Leadership methodology.

From my perspective, as someone who has spent most of my professional life building products, I see mostly opportunities looking ahead. My job, at its essence, is to understand the landscape of the businesses I am responsible for as it relates to technology, business opportunity, and human talent. I focus on identifying an "unfair advantages" Autodesk might have and figuring out how to exploit them. At the core of success for me are two interrelated topics, the first of which is knowing what our WHY? is. The WHY? is that "One Thing" that ties business opportunity, technology, and human talent together. The second topic is what I call Agile Leadership.

Clarifying the WHY?

Over time I've realized that, if I can figure out what the "One thing" is in any situation, our team will be very successful. Andrew is great at identifying that "One Thing." He's done it very successfully with suites, and again with kicking off the business model transformation. And he has continued to prioritize that kind of intense focus in the early part of his tenure as CEO. For a product group, there is nothing more important than focus and alignment, and I believe those things to be equally important in every other part of our business. The simple question that I ask over and over again is: "Is this information or opportunity part of the 'One Thing,' or just system noise?" Usually, it's just noise. The other question I ask a lot is "Am I being agile, or unfocused?"

Agile Leadership

Agile Leadership is even trickier, because it requires doing things that are sometimes counter-intuitive for some managers. The best way to define agile leadership is with two sayings:

1. "Give a person a fish, and you feed him for a day. Teach him to fish, and you feed him for life."

2. "We are stronger together."

I draw upon a number of books for my concept of Agile Leadership:

• The Lean Startup: A very good resource for understanding how everything is an experiment, and failure is not defined as "not meeting your objectives," but rather, "not learning from any outcome."

• Scrum: Before you run to get this book, start first with The Agile Manifesto, and then The Agile Principles. The first thing you are probably going to do is think that this stuff is about software development, per se — but it's not! It's actually the way you solve every problem. I manage my whole organization using these principles.

• The Innovator's Dilemma: Keep in mind that this concept is about how you need to disrupt yourself before you are disrupted; the other side of that coin is you can't get from here to there by continuing to just do what you are doing today, because what you are doing today has a predetermined trajectory. So, to change your trajectory you need to change how you do things.

• Switch: This has great tools to help with organizational change.

• Start with Why: Teaches you to always start with first principles and check everything you do against those principles.

At the core of Agile Leadership is the idea of building an organization that can lead itself by bringing stakeholders into the WHY of their mission, helping them participate in the HOW, and empowering them to decide on the WHAT. It's also about doing all of this in an environment that:

• Values calculated risk;
• Encourages data-informed decision-making;
• Enables decisions to be made as low as possible in the org;
• And gives people the security to learn from every experience, regardless of whether the outcome was expected or not.

With this way of managing teams, the expectation is that everyone on the team, regardless of title or seniority, has regular direct contact with users — and that means that they know users by name, and understand their needs and goals.

Agile Leadership is about turning actions into experiments that are used to inform future experiments. Saying the words "I don't know" is not a bad thing, especially if the topic is important enough to be followed up with a strong "let's find out." Using the Agile Leadership model, we instrument and measure everything that we can, even if the measurement is subjective, and not at all objective. However, it's also important to know that data does not drive every decision, but helps inform them all; and sometimes you need to use data to do a "gut check." After more than 20 years running product groups in companies small and large, I can safely say that there is no way to eliminate risk by using data. You can only mitigate it, that is why I talk about calculated risks and data-informed (but not data-driven) decision making. We also tend to work via small iterations, rather than doing very detailed long-term planning; that way we can continuously course-correct over time as we gain more knowledge. This approach also lends itself to connecting with each other regularly and frequently, and having mercifully short meetings when possible.

There are four risks inherent to agile leadership:

1. Some teams want to just know the answers to their problems, and then to just move on. Early on with this process, it can be frustrating when individuals and first-line managers are being walked through first principles every time they have a question small or large. Teaching them to fish!

2. Teams can get emotionally attached to the customer and become vested in the customer's success. That means teams are much less fungible, so before they start to service another constituency, they need to go through the WHY, HOW, WHAT journey for that new constituency, as well.

3. Teams can be much less tolerant of an answer or instruction without rationalizing back to first principles. They will expect a very clear rational for the instructions they get if they are not well-aligned with the WHY, HOW, WHAT.

4. This methodology can be very stressful, and often requires teams to take breaks well beyond vacations and sabbaticals. To address this challenge, it's important to give teams a sprint once or twice a year where they can work on anything they want to, as long as it meets some basic requirements of relevancy. We call this "Fun for a Sprint," and it helps drive future innovation because it allows people to explore areas of interest that they can't explore during their regular work. Fun for a Sprint demos are some of the most enjoyable to sit in on, and we often pull ideas from this process to inform our future planning.

Here are some of the most important Agile Leadership values:

• We are always stronger together
• Move fast
• Take calculated risks
• Data-informed decision-making
• Empower individuals to make decisions
• Make sure everyone understands WHY you are doing WHAT you are doing, first
• Challenging existing assumptions is encouraged
• Learn from successes and failures
• Everything is an experiment
• Think of the customer first and last, but don't insist on always making them happy in the short term
• Everyone should know the customer, regardless of their position in the organization

Conclusion

My litmus test for success is a simple question: What happens if I get run over by a bus? I would like to think that people will miss me, but that they will not need me to continue to be successful. As we move into this new era of rapid change at Autodesk, I will continue to focus my team and our efforts on that all-important WHY?, and also to use Agile Leadership to turn change into opportunity whenever possible.