Challenge: Describe your challenge, including all relevant information.

I work in a software firm that develops and hosts applications for many large banks and businesses. Occasionally, these applications have outages (due to bugs in the code, resource contention, network issues, or larger AWS outages).

Whenever a major outage occurs, multiple teams get involved and the process can get disorganized very quickly. Our support team gets involved to solve the issue, the engineering team gets involved to dive into the code base, our cloud team gets involved to check on AWS and any network issues. All of these teams are communicating via email, chat, on support cases, and JIRA tickets. Issues can also span multiple time zones with different people from different teams working on the same issue.

As a result of the disorganization, it takes longer to resolve an issue. Management has no visibility so they keep interrupting work to ask for updates. Sometimes, certain important questions are not asked (since everyone assumes someone else already asked it).

Selection: In your own words, briefly describe the tool you selected (e.g., what it is and why you selected it for your challenge -- including any appropriate video lecture references).

For this issue, we selected Learning Launch since we already determined What Is, What If, and want to move on to the What Wows. As Andreas Schmitz discussed in Week 4 “Learning Launch Tool”, we wanted to test out a hypothesis and learn from a small application of a possible solution.

Application: Describe how you applied the tool you selected to your challenge (e.g., what you did and how the tool was applied effectively or ineffectively).

We knew that a lot of the problems stemmed from decentralization. All the information was scattered, and the different stakeholders all had varying levels of access to the information. We wanted to try centralizing the information into one google doc that we called an “Incident Management” document.

In order to keep the launch small (and fail faster if needed). We started out with a very loose template. We then tried out the document in only a few incidents. After each incident, we would hold a postmortem to look at the results of the learning launch.

The Incident Management document was a big success. One of the areas that we didn’t anticipate was the fact that the new process made working on multiple incidents at the same time much more manageable. Recently, we had a series of outages on multiple customer applications at the same time, and not only did we resolve each of those issues quicker, it also helped juggle resources

between multiple issues (as the same experts were often needed at multiple places at the same time).

Insight: Describe the insight you gained from applying the tool you selected to your challenge (e.g., how an insight affected your thinking about the challenge and about design thinking more broadly).

After applying this tool, I realized that solving large issues doesn't always require strong buy-in from leadership. As we implemented the learning launch in just a few situations in the beginning, we didn’t get much pushback. Later, as we applied it in more and more scenarios, we were able to demonstrate value to leadership before asking for their blessing to make it a standard practice.

Design thinking is really helpful in keeping everyone focused on specific solutions to problems, instead of getting bogged down by concerns about a new way of approaching things. If we had tried to do a hard launch from the beginning, we would have encountered a lot of resistance, and the idea may never have been implemented.

Approach: Describe what you might do differently next time -- applying the same tool you selected or a different one -- and the reason(s) why.

This was a very successful implementation of a learning launch, as well as design thinking in general. However, one thing that I would change if I had the opportunity to redo the way we approached this problem is how many stakeholders we involved in the beginning of the process. While we had strong buy-in from leadership, we encountered resistance from certain stakeholders who were not involved in the learning launch when we later started using the Incident Management document as a standard practice.

