alt_text

"african lion" by deborahmancino is licensed with CC BY 2.0.

Ignoring one critical aspect of leadership in an agile organization will cripple the learning capacity of your teams.

I call it the Courage Budget.

Courage is one of the core values of eXtreme programming.

It’s a crucial resource for technical teams to do the hard work of sustaining the quality standards and continuous improvement required to excel.

In this post, I’ll share ways to evaluate, resuscitate, and grow your teams’ courage budget.

Far-Sighted Leaders Are Naturally Blind to the Details of Daily Work

One of your central responsibilities as a leader of agile teams is to remove impediments and enable excellence. You rely on your teams, the people closest to the work, to give you insights on where impediments lie - at your altitude in the organization, it’s impossible for you to see them yourself. What is lacking or needed regards to tools, resources, environment? Without a doubt, teams know in excruciating detail what is holding them back.

But how do you get this information? You rely on the teams to be your scouts and help you see the issues that are buried in the systems of your organization…but these same scouts may or may not feel they can be candid in their feedback.

Courage is a Finite Resource

It’s easy then to just say, “have some courage!” to your people and expect them to tell you when they need help.

Early in my career, I gave a manager feedback on their feature request, something they were very passionate about and confident in the need for. My team and I had tried giving feedback before and the results weren’t great. The manager explained to me why what we said didn’t really apply, why the problems we saw may crop up for other people but not for this product.

As I mulled over providing more information to this manager, I saw in my mind’s eye the large monthly payment on the car I had just purchased. I thought about how much savings I had in the bank. I thought about how long it had been since I’d interviewed for a job. I thought about the state of the marketplace for job searching and my options.

I thought about all of this in about 15 seconds. Then for the last time, I sucked up the last of my courage budget and offered my manager more information on the issues I was seeing with the new feature. My team agreed. The manager patiently explained why this new info also didn’t really apply, told stories from their long experience in the industry until we were all weary of the yarn-spinning, and as my heart sank I realized that this was the last time I was going to be able to do this. My courage budget had fallen to zero.

That manager learned nothing more from me about improving our work. Fortunately, I went on to another position soon after and managed to regain my courage - but that’s a story for another time.

Swooping and “Explaining Why”

Swooping - when a leader stops by briefly for a team update without any built-up context - almost never works. It just gives you a shallow snapshot. For addressing systemic issues and ongoing patterns of impediments you need your teams to tell you what’s going on and what is needed. You need a “pull-system” where the teams find you when they need help, rather than you “pushing” help upon them at intervals.

Leaders that “swoop” tend to listen to the problem and then respond with quick fixes - armed with a shallow understanding of the issues, they can easily pluck solutions gained from their hard-won experience.

After you depart, team members may shake their heads at how little you understood the issues. Your experience was valid and hard-won, your insights may indeed be useful - but for a different problem that the team wasn’t currently experiencing. It’s difficult to understand the dynamics of an issue with a brief drive-by. The team then is forced to face giving up and assuming this is an impediment that is out of their control and simply part of the work landscape.

Swooping is only half of it; another deadly habit of many managers is what I call “explaining why” (“explaining why” is just one pitfall in the skill of receiving feedback - read here for a larger discussion on this crucial skill.). Most managers tend to “explain why” this or that impediment is simply part of life at the company. They respond to the team’s requests by “explaining why” it doesn’t apply right now, or why the request can’t be satisfied.

Every time you swoop or “explain why”, you’ve wasted the dearly-won courage the team has just spent on providing insights and feedback. It has essentially been washed down the drain.

Teams with an initial supply of courage will continue to speak up in the face of this kind of leadership deficit. Every time they speak up, they spend from their courage budget, until their courage budget slowly winds down to zero.

If you’re lucky your team starts with a healthy courage budget. That’s quite unlikely however. Most new team members will be inherited from other organizations which long ago frittered away any courage that particular engineer may have had embarking on the beginning of their careers. Poverty-stricken teams populated with these engineers will greet opportunities for team improvement or organizational learning with jaded skepticism. They have long ago learned to save their precious courage for personal priorities - for learning or resources they privately know they need and will fight to make time to take care of themselves. They’ve suffered through what happens when they foolishly spend courage where it doesn’t get reinvested.

I want to stress that this is actually wise on their part.

When teams don’t have enough personal courage, or not enough faith that it will be well-invested, to pool together into a team budget, you find poorly maintained buggy software and faltering organizations.

As we know, audacious goals require healthy budgets. As a leader, your own courage - to approach your own managers with the team’s requests, and to ask leaders of other departments for resources on their behalf - is included in every team’s budget too.

The courage budget is not about fixing your people; it’s about how skilled leadership can resuscitate the courage budget of a bankrupt team.

The Bad News On Financing Courage

When the courage budget of a team or an engineering department is zero, you’ll find the teams much more amenable to your direction. Pretty much all your ideas are good - the team takes this as a premise, at least in terms of their workflow. There is no courage budget left for providing feedback, giving bad news early (for example, that a certain feature could be done in a more efficient or effective way) before “real” money is invested in unworkable ideas.

And thus the organization speeds towards whatever future is likely when the captain of the ship is blind.

The Good News On Financing Courage

Any time you respond positively to a request to get some needed equipment, or remove an impediment, or fund a needed technical training - any time you show that their courage was well spent, that courage gets directly reinvested back into the budget.

The more often you do this, the bigger the budget gets. You create a positive feedback loop that begins to lift your people and org through the stages of an evolving learning organization and into a high-performing organization. Your teams are deep in collaborative flow states. Life is good.

Become Rich In Courage

Demonstrate through action that you value every small piece of improvement feedback you get from your teams. Even when you personally don’t understand the need. Especially when you don’t.

Cease swooping. Build trust through demonstrating that you will act on any insights and opportunities the team brings to you themselves. If you want to participate in solving a problem, sit with the team over a period of time and experience it yourself, till the team is satisfied, long enough to leave “swooping” in the rear-view mirror.

This doesn’t mean unthinkingly doing what the team asks. As we all know, you need to fully understand what value is requested in order to deliver it. Simply stay in the conversation until you do.

And if at all possible, avoid “explaining why”.