We Learn From Our Successes More Than Our Failures
I remember when my oldest daughter learned to walk. It was a fascinating process. There she stood, holding onto a chair to keep herself from falling. Tentatively, she would let go of the chair and stand on her own for just a moment. Before she fell, she grabbed onto the chair to steady herself. Sometimes, she wasn’t fast enough and fell. That didn’t stop her, though, as she’d get back up and try again.
Eventually, as she tried it again and again, she learned to balance. Walking wasn’t far behind as she took a step, fell, got back up, and tried again. We tend to see this scenario as a prime example of learning from our failures, how we should keep trying after we fail.
What I misunderstood about her experience is that she wasn’t learning from her failures — she was learning from her successes. Certainly, the importance of trying again after failure is critical, but what ultimately drove my daughter to learn to walk was that she succeeded in the small things until she succeeded in the bigger things. That is, when she let go, she was balancing for just a moment…a success. She kept practicing success until she could do it naturally. From there, she took a step…another success. Falling was an obstacle, but only that. Each successful step gave her hope that she could take another one.
The University of Chicago Booth School of Business did a study on learning. From this study, they concluded that we learn more from our successes than from our failures. This isn’t to imply that we shouldn’t learn from failures, but the most important thing that we should learn from failures is that we should try again, keep going, and look for approaches that we think will succeed.
The Importance of Vision
What drove my daughter to learn to walk before she turned a year old? I’m not a psychologist nor a doctor, but my bet is on the fact that she saw others walking. She had a desire to do what she saw. She had a vision of what it would be like if she were able to walk, as well.
When we look at process improvement activities, it’s common to look at metrics, pain points, failures, and inefficiencies. Those are great tools to use, but they tend to be focused primarily on our process activities.
What would happen if we, as engineers, envisioned our daily lives in a particular way. What would an ideal day be to a software developer? Wouldn’t we want to build software that gets used by people? Wouldn’t we want our customers to love our software? Wouldn’t we want to build it in a painless way, with lots of successes along the way?
When we think about success, it’s critical to take the time to understand what success looks and feels like. This isn’t just to improve the processes we follow. If the architecture and design of our software limits our ability to achieve that success, then shouldn’t we want to change it? Sometimes, the best way to fix a process is by fixing the underlying architecture, design, or even code.
I remember starting a new job and meeting my teams for the first time. I asked them where their pain points were. The answer? We don’t have any pain points…we’re good. Over the course of a few weeks, it became obvious that there were plenty of pain points. They just didn’t know any better. They had no vision of what success looked like.
Working Towards Success
We all fail. And though we should certainly learn from our failures when we can, our focus should always be on the vision of success. At worst, failures are an obstacle in which we get up and try again. But what if you focus too much on fixing the failure and not on what success looks like? You end up fixing the failure and missing the ultimate success. Politicians do this all of the time. Something bad happens, a knee-jerk reaction occurs and a new law is proposed so that the bad thing won’t happen again. Before you know it, we have laws that don’t drive us to success; in fact, some of them drive us in the opposite direction.
I’ve seen engineers do this, as well. A failure occurs (maybe an outage), so a solution is determined outside of the context of what success looks like and that fix gets carried forward as a new process weight for years to come. For example, a library you depend on has a bug, so you create a workaround. Eventually, the library gets fixed, but the workaround still exists and lives on for years. Future engineers wonder why the workaround even exists.
Another prime example that many organizations, engineers and management struggle with: continuous delivery. Deployments are fraught with risk and cause outages so processes are added to prevent failures and reduce risks. However, those processes may also prevent an organization from fully embracing a continuous deployment or delivery environment, pushing them further away from actually having a successful environment where engineers can deliver their software often (and, I might add, with fewer failures). This is all in the name of learning from failures.
Are We There, Yet?
It’s critical that successes initially be recognized. Celebration also helps, but successes should be at the forefront until they become natural — a part of the culture.
I once worked with a team in an Agile environment in which they didn’t complete many of their stories and had to carry them to the next iteration to finish. As I worked with them to adjust the culture and expectations, they eventually delivered all of their stories they had committed to at the beginning of the iteration. In their retrospective, I asked them how it felt.
Their response was telling. “We’ve never done that before. That felt great!”
They went on to regularly deliver everything they committed to within their iterations. It changed the culture of the team and helped them improve their morale.
When we learn from our successes, we grow our confidence. Confidence drives our ability to learn. This cycle drives successful products, careers, and people.
Examples
Let’s look at some examples of process changes that can drive successes:
- When estimating work, try to estimate smaller things, rather than larger things. Engineers tend to be able to estimate smaller work better than larger — and usually more vague — work.
- Deliver smaller changes more frequently. This reduces the failure risk and the frequency builds confidence. If you’re not able to deliver frequently, change the architecture/design/tooling so that you can. Delivering frequently is more important than the technology you use.
- Automate your testing and ensure that all of your tests pass all of the time. The combination of understanding your test coverage and the successful execution of your automated tests builds confidence in your delivery (as well as many other aspects of your development).
- In your retrospectives, discuss your failures with an eye toward the “engineer’s vision” of what they want their life to be. In addition, review what you’re doing right, rather than what went well — this is to recognize successful outcomes.
Conclusion
Software development is fundamentally a learning activity. It’s also a successful activity. This may be surprising, especially given the studies that show so much failure in the industry, but if everything failed, we wouldn’t be doing it anymore. That means that there are many successful software projects…learn from them.
