What Are Left-Hanging Releases and Why Should You Embrace Them?

You have probably had the experience of working tirelessly on a challenging, high-profile, business-critical project, for a significant period of time, chasing the satisfaction of completing the project successfully, only to have it be suddenly finished, completed with very little fanfare, or the gratifying catharsis that you were anticipating. You know, that feeling when a massive database migration, that you have been working on for months, happens seamlessly and no one in the rest of the company takes any notice, or when you improve the performance and scalability of a business-critical software service, reducing costs and preparing for growth, and customers remain blissfully unaware, delighted by the same great experience that they have always known. I call these releases: Left-Hanging Releases.

Why a Left-Hanging Release? Tom Brady is an American football quarterback. He has had more success than any other professional player in football history, appearing in the championship game—the Super Bowl—eight times, at the time of this writing—all with the same team—winning five of them. When you have this much success, it means that you have put in the hard work, relentlessly, behind the scenes, to be successful, and it also means that you have delivered in the moment, time and time again, when the game is on the line. When this happens with such consistency, it becomes expected. So when you make a big play or score a touchdown, there is no reason to celebrate exuberantly. It is normal; it is expected; it is what you do.

When a team makes a habit of reliably delivering software with significant business value with very little fanfare, I cannot help but think of the following Tom Brady meme, where, after trying to celebrate a big play, he is ignored and left hanging when trying to high-five his teammates:

This is the first time, and most likely the last time, that you will see a meme on this blog, but I think it sums up perfectly how these significant software releases often feel. After months of work and an uneventful release, the team is ecstatic and eager to celebrate the milestone. However, because the release went so smoothly—without regressions, downtime, disruptions, or fanfare—the rest of your colleagues just shrug, wondering what all the fuss was about. Often the last step in a major software release is not even particularly exciting—like flipping the switch on a safe, blue-green deployment, or slowly diverting traffic from an old system to a new one. Although the team is excited, the actual event can lack the anticipated satisfaction.

What makes this Tom Brady meme even funnier, and more lasting, is that Tom has been left hanging on more than one occasion:

I have worked exclusively on infrastructure software and services my entire career, so I have rarely been involved in a flashy, public-facing release that results in immediate excitement or customer feedback. With infrastructure software or services, it usually takes some time to plan, develop, roll-out, and adopt. I can understand how the experience may be different for someone who works on a consumer-facing product that makes a big splash—like a new product launched in a pricey commercial during one of Tom Brady's Super Bowl games—that millions of people adopt in a short period of time.

Left-Hanging Releases don't just happen by accident. They are a product of a dedicated team; careful preparation; systemic, long-term thinking; and attention to good engineering practices, like design review, testing, instrumentation, monitoring, and fail-safe recovery mechanisms. In many ways, because these teams are able to introduce changes and evolve the system relatively seamlessly, they fail to highlight how challenging the work actually is. It can be easy for management to overlook this and fail to recognize the full value the team is providing to the business.

Finding and fixing the most difficult software bugs can prove a similar experience to a Left-Hanging Release. The most challenging bugs are usually related to concurrency, edge cases in business logic, time, or the complex interactions of various components and systems. Finding a reliable reproduction of the bug can often be an elusive first step, taking a significant amount of time and perseverance. After finding the defect, often the solution is relatively easy—even some of the most insidious bugs are resolved by changing one line of code, or one configuration parameter. The problem and the solution are obvious, once they reveal themselves. It isn't exactly a satisfying resolution when you are left feeling that other people are thinking, "Well, that seems obvious. What took you so long?" It may be obvious in hindsight, but explaining to someone else your long, varied path of insightful thinking and experimentation is difficult, after the fact. It can be especially hard for someone unfamiliar with the system, or lacking your expertise, to even appreciate.

This is one of the reasons that I dislike the typical Sprint Review meetings, popular in so many software development organizations. These dog-and-pony-shows tend to focus only on recent results and the work cannot be presented with sufficient depth to recognize the thinking and effort behind the results, to be a satisfying or rewarding venue for the engineering team. It might be important for the organization to have these meetings to understand the progress made and the milestones achieved, but do not think for a second that these meetings are a forum to sufficiently recognize the efforts of the development team. This recognition needs to come in a more private setting and it needs to recognize the thinking behind the work, not just the end result.

Additionally, Sprint Reviews do not provide the closure that is often touted. This can only come from within the team itself—from the people who shared in the journey and understand the full effort and skill that was involved. This is where the real satisfaction comes from. You look at your teammates and you just know that you did a good job.

When you work on infrastructural software or software services, the fact that no one notices or seems to care about many of your critical releases is a very good thing—if things did not go smoothly, I can guarantee you that people would take notice. There is no escaping the fact that the final step in a major release, or that one-line bug fix after a long hunt, may not provide the climax and denouement that you were anticipating or longing for. But ultimately, it is not about the final step—it is about the journey that you took to get there. So, while you are in the middle of this journey, take the time to enjoy it with your teammates, since it really is the best part.

The next time that your team has a Left-Hanging Release, embrace it. It means that you are doing the hard work behind the scenes to be successful and deliver value, without drama or fanfare, over and over again. In the end, a few of your teammates that have been on the journey with you will be able to share in the quiet satisfaction of the moment. Think: this is normal; this is expected; this is what we do.