Stark & Wayne
  • by Brian Seguin

Nine months before the start of the pandemic I was hospitalized for rhabdomyolysis, a serious medical issue caused by muscle tissue breakdown that impacts kidney function. Since my hospitalization, I have been trying to find ways to recover but recovery may take years due to the extent of muscle and organ damage. Without knowing the root cause of my rhabdomyolysis, I sheltered in place with my family when the pandemic started. Staying at home meant that my recovery process was left up to me and I uncovered a beautiful analogy between solving my own pain and helping organizations solve their own.

I came to discover that there were pain points in my muscles that I injured over 10 years ago. It was only after the last two months I realized I had been working my pain points all wrong. I was focused on the most painful trouble spots and never worked on the small connecting trouble spots. I also realized that this is exactly what happens to organizations. If you want to resolve the big pain points for good, you need to solve the small ones first.

As an organization goes through periods of stress, growth, or hardship many small pain points are created in the organization. These small pain points are often masked by much larger and seemingly more important ones. Perhaps the larger problem here is that people tend to spend their time concentrating on solving the biggest issue first. Think of how many times your manager focused on fixing the “loudest” problem only to find out later that the problem was made into the “loudest” problem by multiple smaller problems contributing to it.

So, how do you figure out what is connected?

First realize that asking will not work most of the time. If you were to ask me where my muscle pain was from I would without a doubt point to the most painful area, not knowing that there were four other small areas making it worse. The only way I could find out is by pressing on the trouble spot and methodically working to see which ones are connected to the pain. Once the first spot is found, remember to keep looking because there are going to be more.

How do you inspire your team to look past the big pain points?

Set small achievable goals that reward quick wins and small improvements. Having numerous more frequent achievements will seem tangible and also help to improve job satisfaction. Also, let them know that the focus is not the biggest trouble spot because fixing the smaller trouble spots will make the bigger ones easier to fix.

What are some ways to avoid problem spots in the future?

The Cloud Native movement as a whole is designed to continuously identify and work to fix problems for all organizations. It is important to note that a Cloud Native transformation requires all areas of the organization to change, not just the technical teams. This is especially true for Accounting and Finance departments re-thinking how they do financial projections and tie business value to cloud costs, but perhaps that is a separate blog. So, let us touch on a few specific concepts.

Agile & Scrum -  While Agile & Scrum are two different methods, teams can interweave practices of each with current organization’s operations. Adopting these concepts, even in part, helps to create an iterative process that helps to identify and treat pain points as they happen. Concepts of Agile & Scrum can be incorporated into all types of teams regardless of what technologies are being used. It is important to note that practicing the textbook applications of Agile and Scrum is beneficial for learning purposes, however in practice it is typical for only some concepts to be adopted.

Continuous Integration / Continuous Deployment (CICD) - CICD together is a Cloud Native concept that can be incorporated into organizations with Cloud Native architectures. The two concepts together create a framework that finds and helps prevent pain points.

Microservice Architecture - Managing applications broken up into loosely coupled services or microservice frameworks helps make pain points smaller and easier to identify and fix. Getting monolithic applications refactored into microservice architecture will take effort and it may not be a good fit for your application or your team’s skill set There is also a vast ecosystem of Cloud Native tooling and content that enables microservice architecture it can be intimidating on first investigation.

Important Note: Adopting these and other Cloud Native practices do not fix pain points, cultural issues, or personnel issues. These practices give organizations tools that help resolve pain points more easily. Always remember forcing change without input often reduces job satisfaction and therefore productivity. High job satisfaction will increase productivity.

Find more great articles with similar tags Cloud Native cloudnative-transformation author-bseguin