Agile has many answers to the challenges of contemporary software development. But it also challenges us with a fundamental paradox: learning is essential to success but failure is essential to learning.
Rapid iteration. Continuous integration. Minimum viable product. Fail fast. We're all comfortable with the catch phrases of contemporary development. But are we comfortable with ourselves?
Nobody likes to fail. Failing is not only embarrassing but costly—to our products, our teams, to our organizations, and especially to ourselves as we move through our careers.
Success feels much better—certainty is comfortable; uncertainty is unsafe.
The challenge, then, is to make our organizations fail-safe, to create an environment where it is safe to take the risks learning requires, risks that will often lead to failure but from which will come the extraordinary improvements that are the keys to our success.
How we do this, I think, involves three foundational ideas: (1) Fail-safe leadership; (2) Feedback-friendliness; and (3) Knowledge of self and others.
Fail-Safe Leadership
In a talk I gave recently on pushing through the low points of challenging projects, I discovered something that surprised me: no one in my audience of 20 or so felt supported by their leadership to take risks and deal with failure head-on.
The talk was based on a recent project that had just completed, one that struggled through several low points but was eventually delivered successfully to the client. As a product owner on the project, I had many tense discussions with the project’s stakeholders about feature prioritization within the scope of time and budget. Many of these were “no-win” situations for me: failure of some kind was inevitable because we were often behind relative to initial requirements and new requirements seemed to be popping up at the same time.
I would have preferred to have avoided these situations entirely or at least to put them off as long as possible. But I didn’t because I had the assurance of both my manager and my CTO that any failure I might experience would just be one more bridge we would all cross together if and when we came to it.
Even though the project wasn’t going well at the time, I felt safe to enter into important stakeholder discussions more often and with stronger positions that provided greater clarity. Because my stakeholders and I ended up talking more regularly, we began talking about less each time. This meant that there was less on the line and less to be afraid of.
Over time, three positive things happened:
- I took more risks to move my part of the project in a more sensible direction;
- More frequent discussions with a clearer agenda from me meant that our interactions were more focused and more efficient; and
- With less on the line at each juncture, what felt like contract negotiation at the beginning moved gradually toward the kind of stakeholder collaboration we all value more.
Legendary IBM founder, Tom Watson, is reputed to have encouraged his engineers to “Make more mistakes faster!” Whether that’s apocryphal, or whether he really walked his talk on this, is something I don’t know. But expressions of this kind from organizational leaders—and actions that back it up—form the foundation of fail-safe organizations.
From surveying my audience during the presentation I gave, it seemed that I was the only person in the room who had experienced anything like fail-safe leadership recently. One participant said that whenever projects reached their nadir, he began looking for another job. This is a perfect, and probably all too frequent, example of why fail-safe leadership is so critical. At the precise time when an organization would need its most experienced people to pull a failing project through to success, many of them may already have one foot out the door.
Feedback-Friendliness
Are we and our teams “feedback-friendly”? How well do we handle feedback? To what extent do we invite it? And when it comes knocking at the door do we greet it warmly? Or have we already pulled the window blinds and turned out the lights so it appears that no one is home?
Feedback is essential to learning. But many of us feel paralyzed by it. Private mechanical feedback, the kind we face when a chunk of code doesn’t work, is not the challenge here. Most people handle anonymous messages from inanimate objects pretty well. But what about public human feedback, the kind that comes up all the time during discussions of important ideas?
To make the world safe for feedback, an explicit shared understanding of the nature of feedback is helpful. Here are four things about feedback that improve learning when they are understood by all parties:
- Feedback is more about the person giving it than it is about the person receiving it. In a retrospective, for example, my team members might say, “We blew our sprint because we didn’t have clear requirements.” As a product owner, I might suspect that’s a piece of feedback for me even if my teammates are so polite as to not mention my name. But while it is directed at me, is it really just about me? Or is it about them, too? Maybe my requirements were terrific but my teammates did a poor job of estimating. Maybe there are a dozen other contributing factors. Who knows? But most important, who cares? This is more about detecting feedback than it is about deflecting feedback; it is about acknowledging that feedback is more like playing catch than it is like playing dodgeball. Whether or not I catch the ball or get smacked by it has more to do with how it’s thrown and who is doing the throwing. With this attitude, I’m less likely to wallow in my own perceived incompetence and more likely to realize that I’ve just learned something about my team that I can use to make things better, especially if I have the courage to take a further risk and ask for more specific feedback about my perceived role in the team’s failure.
- Acting on feedback is optional. One of the reasons many of us fear negative feedback is that we feel we will be trapped by it. As soon as someone finds something they don’t like about us or about our work, we think we’ll have to change immediately. This isn’t true. We all have the option to act on feedback or not. Furthermore, we have the option of taking time to consider if or how we will react to it. We own the consequences of our action or inaction, of course. But don’t we already own the results that led to the feedback in the first place? The point here is to be reflective instead of reactive. One characteristic of fail-safe organizations is that when bad things happen, people within them tend to reflect—appropriately, not excessively—before reacting. Much the same can be said of people who are particularly good at handling crises or even just minor setbacks. We all fear loss of control. Negative feedback doesn’t take any control away from us. It actually gives us more control because it helps us form a clearer assessment of our situation.
- The best response to feedback is “Thank you”. Often, when we receive negative feedback, especially in front of our peers, we feel the need either to apologize, to take immediate action to correct something, or to challenge its veracity. In the heat of the moment, neither of these strategies is an optimal response. The optimal response to feedback, whether positive or negative, is simply to say, “Thank you.” There may indeed be something that needs to be corrected right away but a knee-jerk reaction to fix things is likely to invite more feedback if the reaction fails to address the issue. Apology is also a reflexive action many of us feel the need to take when we receive negative feedback. But apology complicates matters. What does “I’m sorry” mean? Does it mean that one is overcome by sorrow? Does it mean that a situation will be corrected or kept from recurring? Does an apology even indicate to the person giving the feedback that the feedback is understood? No. How about: “Thanks for the feedback. It gives me a better understanding of what you need.” Wouldn’t something like that work better?
- All feedback is good feedback. It’s natural to view feedback in binary terms: to accept it when it is positive and to reject it when it is negative. But all feedback is good. Feedback is just information. And while it’s true that some types of information are more helpful than others, all feedback has some value to it even if that value is as simple as reducing our uncertainty about who people are, what people think, and how people feel.
Ultimately, we want as much feedback as we can get because feedback speeds up learning. We want quantitative and qualitative feedback; machine feedback and human feedback, group feedback and individual feedback—any and every kind of feedback. Feedback helps us orient ourselves in the world; it tells us where we are. Another characteristic of fail-safe organizations is that knowing where we are, even if it isn’t where we want to be, is always a safe place from which to begin moving in a better direction.
Knowledge of Self and Others
There is nothing less safe than the unknown. Period. End of company.
Uncertainty is uncomfortable at best and paralyzing at worst. So one vital step toward a fail-safe organization is to reduce uncertainty.
It is often difficult to reduce levels of uncertainty about our business or our industry sector. Market forces are often out of our control; long-term macroscopic change is beyond our near-term microscopic perspective.
But fail-safe organizations can do much to reduce the uncertainty their people have about themselves and others. Or, to be more precise, people within fail-safe organizations can do much to reduce their uncertainty. Creating a fail-safe organization is a shared responsibility.
Am I afraid of an upcoming presentation or a new responsibility? What do I know about myself and these issues? How do I feel about participating in important events? How do I typically react to change? The more I know about myself, the less uncertain I am about the future. This not only reduces my anxiety about the future, it frees me to be more effective in the present—which is probably the key to being effective in the future such that I don’t need to worry about it at all.
Part of working in a fail-safe organization is acknowledging my safety to the full extent that it exists. This is an internal process, something to be performed by me, for me, and on me only.
Socrates told us that “An unexamined life is not worth living.” While this can be interpreted in many ways, I think the way that serves me best to is to view it as an invitation to better understand myself in relation to my circumstances. Even in times of crisis, curiosity is a much healthier attitude to bring to work than fear.
Now that I’m taking care of myself, what about everybody else? Jean-Paul Sartre, warm and cuddly philosopher-intellectual that he was, wrote in his famous play, “No Exit”, that “Hell is other people.” What do I do about that?
Do I think my manager is disappointed with me? Do I think I’m going to get demoted? Maybe even fired? Why wait through the nail-biting weeks and months until my next review? Why not just talk to her now?
Better yet, why don’t I talk to my manager regularly in friendly no-stakes conversations? Why don’t I just get to know her as well and as appropriately as I can? At the same time, I offer her opportunities to know me better as well.
So much of what feels unsafe to us in the workplace is simply the uncertainty we have about ourselves and others. How do we deal with this? By getting to know people better and by letting ourselves be known.
Another characteristic of fail-safe organizations is empathy. When I ask a group of engineers to risk failure in pursuit of learning and competitive advantage, it is better for them and for me if I have some understanding of how they feel when I ask them to do it and how they feel as time—and failures—go by.
Getting to know people better does not require team lunches, parties, potlucks, or the occasional random surprise afternoon off to see the new Star Trek movie. These well-intentioned “team builders” may be fun but they don’t do a lot to build teams. Mostly what builds teams is trust among the people in them. Trust is something we build by getting to know people day in and day out in the context of our work together—and by letting people get to know us.
What works better than the annual Oktoberfest Bowling for Bratwurst Party? Ask people questions about themselves. Then sit back and listen. Make an effort to connect. The more connected people are, the less isolated they feel—and isolation is one of the root causes of the fear that reduces our willingness to take risks. The more connected people are, the more they function like a team instead of just a group of people who meet together often and share a funny name.
Are We Ever Truly Safe?
Even in a fail-safe organization, none of us is ever truly safe. This is not an existential crisis but a call to action. If we know that rapid learning is the key to our success, and if we also know that rapid failing is a prerequisite for rapid learning, then we have to dedicate ourselves even more vigilantly to raising the levels of safety in the work environment.
Light-weight rapid development methodologies, and the reality of an often chaotic and unpredictable global economy, require us to live in a world of increased uncertainty. But we don’t need to work in one.
In the last 20 years, we have seen a profound shift in all industry sectors, especially in tech, that is characterized by a bias toward action. This is not to say that we don’t plan. It is merely to suggest that the balance of planning to action has shifted.
If we truly favor “responding to change over following a plan”, we serve ourselves and our organizations better when we acknowledge that planning less and acting more increases our risk of failure but that this is a good and necessary thing. If learning is the key to competitive advantage, then learning to fail is the first thing to learn.
About the Author
Steve Peha is a learning strategist with 25 years of experience in software development and instructional science. Recently, he served as a Product Owner on the Gates Foundation's Shared Learning Infrastructure, an enterprise Agile implementation of a reference platform for Student Longitudinal Data Systems. He is also the co-creator, with Amr Elssamadisy, of "The Culture Engine", a method of workplace culture change designed to enhance organizational performance and personal satisfaction, recently unveiled in a presentation at Agile 2013.