boss versus leader

Top 5 Ways Executives Destroy Agile Companies

Photo credit: philozopher via Foter.com / CC BY-SA

A few months ago, a senior executive of a large company asked me, “With our Agile transformation, how am I going to screw it up?”  

The question shook me to the core.

A few years earlier, a senior executive of a different company asked me the same question. My response then was to blather about sprints, user stories, and backlogs.  I don’t think I did a good job of educating this executive, and felt somewhat responsible when the project failed to launch and the executive was fired.  

When I was confronted with the same question again by this new executive, I was determined to get it right. My updated response was: “You will fail by not realizing that Agile is an executive leadership philosophy, not a project management workflow.”

This is a somewhat controversial statement, but in my time meeting with senior leaders at several companies, most have signed up for Agile for the wrong reasons. They heard “faster time to market” and ordered a haphazard Agile transformation. They rarely consider what Agile means for their own leadership behavior. They treat Agile like a tool and not like the leadership philosophy that it is.

I tell executives that they should sign up for Agile because they want their people to lead the company beyond their tenure; to refocus their management team on meaningful relationships; to prioritize the stream of value over punctuated milestones; and to rapidly debug the organizational bottlenecks. Faster time to market is the exhaust of Agile, not the driver.

Here are five ways executives are missing the mark with their Agile transformations.
 

5. Executives allow for individual do-ers, not teams.

Let me tell you a story about a man named Greg. Greg was an IT systems engineer who supported the digital marketing group of a large company. Everyday, Greg would keep the website and mobile apps running smoothly while the marketing group tried new campaigns. His isolated professional life revolved around traffic spikes, overloaded servers, and bogged down databases. He rarely knew what the marketing team was doing — and he didn’t care. What was important to Greg was keeping the servers up.

That was Greg’s world until his company reorganized into cross-functional Agile teams. They created a team — which named itself “Team Neptune” — that had two representatives from digital marketing, two from development, and Greg from IT. The goal was no longer for Greg to keep the systems up, but for Team Neptune to execute amazing digital campaigns. Within a month of practicing Scrum, Greg discovered what marketing was really trying to do, and had a list of a dozen improvements the business could make. The same phenomenon happened the other direction, with digital marketing moving funding to development and IT when they saw the benefits of a few rewrites.

If your roles and team structure match your reporting hierarchy, you are doing it wrong. You want to see the primary value of your business divided up into cross-functional teams. Each team is able to deliver, with the same people over the span of quarters and years, the entirety of their slice of the business value. Do these cross-functional team members have different bosses? Yes! They don’t focus on their boss; they focus on their slice of business value. They are a team of many disciplines, many bosses, and one slice of business value.
 

4. Executives delegate Agile.

What stops you from running your leadership team with an Agile philosophy yourself? Why not eat your own dog food?

When I discuss this with executives, they keep swinging back to their corporate strategy, their expenses, and their objectives. There is nothing Agile about any of this. If leadership teams were Agile, they’d be thinking instead about how they are relating to one another; how they are empowering people down the chain to make final decisions; how they are pivoting from the plan with gusto; how they are teaming up and not siloing; and how they are doing one thing at a time to completion before moving on.

My own leadership team runs a variation of Scrumban. We work in sprints on one priority at a time; we don’t move on until we finish that priority; we work cross-functionally; we own goals as a team, and not as individuals; we check in every day; and we keep a backlog of goals and challenges and reprioritize this list constantly. We live the spirit of Agile at the leadership level.
 

3. Executives tolerate the Abstract Customer.

A few months ago while at dinner with one of my favorite executive clients, I asked him if he had ever talked to one of his customers. To be honest, I was painting him into a corner because I already knew the answer: in consumer markets, few executives meet with end consumers. Instead, they use data and research to "derive insights."

“We use data and research for that type of thing,” he told me. “Our new analytics initiative launching next year will give us greater insights than ever before.” My response was a personal mantra: “If you wait for the data, you will lose.”

Without rich, intimate, and personal empathy with your customers, you will never fully understand what the hell you are doing. You are not too important to talk to customers, and neither is anyone on your team. Every CxO, every VP, every director, every manager, and every team member must talk to customers. Here are some ideas:

  • CEO has regular check-in calls with the top five buyers, power users, or superfans.

  • VP of Operations takes a group of target customers — such as stay-at-home parents or IT security professionals — out to lunch twice a year.

  • CMO hosts a BBQ on the corporate campus or rooftop patio with a target group.

  • Frontline managers and team leads host an office tour and hangout session with small groups of customers every quarter.

  • Senior engineers fly out to visit with customers — even if they just work out of their office for the day. Bonus points if you fly your people in business class and treat them like the professionals that they are.
     

2. Executives don’t coach how to distribute authority.

Last fall, I met with a group of folks in middle management at a large global company. The company’s executive leadership told me they thought their Agile transformation was complete, but my gut told me there were some serious problems. In my conversations with middle managers — mostly from marketing, operations, and product — I quickly found the culprit.

“What we really wanted to do is launch a much smaller MVP, so that we would have some extra time to work on a bad user experience that was embarrassing us,” said one marketing manager. Many in the group nodded in agreement.

“So why didn’t you?” I asked.

“Well, our Director made promises to a partner that everything would be done by a ridiculous date,” the manager said.

I asked, “So everyone at this table disagreed with the strategy, the tactics, the promises, the deadlines, and the leadership?” Everyone nodded, then shrugged their shoulders. An operations manager added, “This is how it always is. We don’t challenge this particular Director — it’s not worth the fight.”

This was a team of hard-working middle managers who drove home every night embarrassed by their work, embarrassed by their leadership, and embarrassed for their customers. The only person who was not embarrassed was the department’s Director, who had to be seen as the smartest person in the room and the spotlight of success.

Delegating authority is hard work. Emotionally coping with the consequences of giving authority to others will be painful. Coaching your team, rather than commanding your team, is a full-time job that is rich with dropped balls and mistakes. Here is the catch: Your team dropping balls and making mistakes is infinitely better than you being in command. If you are in command, the organization only matures as fast as you do, only innovates as fast as you do, and ultimately will fall apart when you fail to capitalize on the talents of your people. Don’t command; lead. When they fall, fall with them. When they succeed, give them the spotlight. This is how a company becomes truly Agile.
 

1. Executives don’t have a leadership philosophy.

You’d be surprised at how many Fortune 1000 senior executives become flustered when asked about their leadership philosophy. After most of my dinner dates with leaders, we end up discussing this gap over drinks.

A leadership philosophy is a set of statements that you believe so strongly that you are willing to be fired defending them. These easy-to-remember statements guide your moment-to-moment decisions and priorities. Here are a few of mine:

  • Treat people as masters of their trade — a marketer can be as much a master as Michelangelo and a developer can be as much a master as Einstein.

  • My sole purpose is to support my people on their journeys to mastery.

  • I am compassionate when people fail so that they know how to adapt.

Agile executives need a leadership philosophy because Agile is, itself, a leadership philosophy. If you do not blend Agile into your core beliefs, you will never realize the business value of agility. Here are a list of leadership beliefs that are common in successful Agile executives:

  • No rock star executives allowed. Deep, distributed authority is how organizations mature.

  • No walls, no gates; everyone collaborating with everyone (especially customers!) is how we succeed.

  • Planning is fine, but what really matters is the confident flexibility of my teams.

  • Focus! I am a warrior fighting against sloppy prioritization and multitasking at all levels of the organization — starting with me.

  • No one works alone. We are a team of teams in every facet of the business.
     

Your homework assignment

Reorganize your leadership team today. Seriously. Start working as a cross-functional team of executives with shared goals. For a few hours every week, coach how to delegate final authority in a substantial way. Read the Wikipedia article on Agile. After that, read Peopleware. Call my cell to ramble about this topic — I’ll answer.

And most important of all, get every spotlight in your company focused on the people who make it all work. Because at the end of the day, executives should be the spotlight operators. That is truly Agile.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.

About the Author

Tony Rost, Vice President of Engineering

Tony believes that customers' technology problems can be solved with deep respect, sound data, strong process, and adventurous teams. He uses data-driven methods to improve all stages of the development lifecycle – from design, to beta, to final deployment. With numerous ties to the open-source community, Tony also works to solve client problems faster and more effectively with well-tested open-source solutions.

Several dozen products have shipped under his guidance over the past 14 years: collaborative internal sites at Nike, social networking integrations with Adidas, server-monitoring websites at Hewlett Packard, open source contributions to Drupal, entertainment sites such as The Emmys, community sites such as FearNET, and HTML5 apps for tablets and Smart TVs.